cups-pdf not creating any output if changing output directory

Bug #879172 reported by Thomas Schweikle
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
cups-pdf (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Leaving all default settings cups-pdf works as expected. Changing output directory to "${HOME}/Dokumente/PDF" breaks cups-pdf. Changing it back to defaults makes it work again.

Setting LogLevel to 7 (debug) shows, the commandline for ghostscript is perfect, but after the file is created it is unlinked. Thus the user will never have access to the file as long as he/she isn't fast enough to access it between creation, before unlink:

Fri Oct 21 02:11:21 2011 [DEBUG] switching to new gid (lpadmin)
Fri Oct 21 02:11:21 2011 [DEBUG] initialization finished (v2.5.1)
Fri Oct 21 02:11:21 2011 [DEBUG] user identified (tps)
Fri Oct 21 02:11:21 2011 [DEBUG] output directory name generated (/home/tps/Dokumente/PDF)
Fri Oct 21 02:11:21 2011 [DEBUG] user information prepared
Fri Oct 21 02:11:21 2011 [DEBUG] spoolfile name created (/var/spool/cups-pdf/SPOOL/cups2pdf-8968)
Fri Oct 21 02:11:21 2011 [DEBUG] source stream ready
Fri Oct 21 02:11:21 2011 [DEBUG] destination stream ready (/var/spool/cups-pdf/SPOOL/cups2pdf-8968)
Fri Oct 21 02:11:21 2011 [DEBUG] owner set for spoolfile (/var/spool/cups-pdf/SPOOL/cups2pdf-8968)
Fri Oct 21 02:11:21 2011 [DEBUG] found beginning of postscript code (%!PS-Adobe-3.0)
Fri Oct 21 02:11:21 2011 [DEBUG] now extracting postscript code
Fri Oct 21 02:11:21 2011 [DEBUG] found title in ps code ((AW: "Grosser Methodikkurs" IBZ/ZTI, Zug))
Fri Oct 21 02:11:21 2011 [DEBUG] found end of postscript code (%%EOF)
Fri Oct 21 02:11:21 2011 [DEBUG] all data written to spoolfile (/var/spool/cups-pdf/SPOOL/cups2pdf-8968)
Fri Oct 21 02:11:21 2011 [DEBUG] trying to use PS title ((AW: "Grosser Methodikkurs" IBZ/ZTI, Zug))
Fri Oct 21 02:11:21 2011 [DEBUG] removing trailing newlines from title ((AW: "Grosser Methodikkurs" IBZ/ZTI, Zug))
Fri Oct 21 02:11:21 2011 [DEBUG] removing enclosing parentheses () from full title ((AW: "Grosser Methodikkurs" IBZ/ZTI, Zug))
Fri Oct 21 02:11:21 2011 [DEBUG] removing slashes from full title (AW: "Grosser Methodikkurs" IBZ/ZTI, Zug)
Fri Oct 21 02:11:21 2011 [DEBUG] removing special characters from title (ZTI, Zug)
Fri Oct 21 02:11:21 2011 [DEBUG] title successfully retrieved (job_7-ZTI__Zug)
Fri Oct 21 02:11:21 2011 [DEBUG] input data read from stdin
Fri Oct 21 02:11:21 2011 [DEBUG] output filename created (/home/tps/Dokumente/PDF/job_7-ZTI__Zug.pdf)
Fri Oct 21 02:11:21 2011 [DEBUG] ghostscript commandline built (/usr/bin/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="/home/tps/Dokumente/PDF/job_7-ZTI__Zug.pdf" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-8968)
Fri Oct 21 02:11:21 2011 [DEBUG] output file unlinked (/home/tps/Dokumente/PDF/job_7-ZTI__Zug.pdf)
Fri Oct 21 02:11:21 2011 [DEBUG] TMPDIR set for GhostScript (/var/tmp)
Fri Oct 21 02:11:21 2011 [DEBUG] waiting for child to exit
Fri Oct 21 02:11:21 2011 [DEBUG] entering child process
Fri Oct 21 02:11:21 2011 [DEBUG] GID set for current user
Fri Oct 21 02:11:21 2011 [DEBUG] supplementary groups set for current user
Fri Oct 21 02:11:21 2011 [DEBUG] UID set for current user (tps)
Fri Oct 21 02:11:21 2011 [DEBUG] ghostscript has finished (256)
Fri Oct 21 02:11:21 2011 [ERROR] failed to set file mode for PDF file (non fatal) (/home/tps/Dokumente/PDF/job_7-ZTI__Zug.pdf)
Fri Oct 21 02:11:21 2011 [DEBUG] ERRNO: 2
Fri Oct 21 02:11:21 2011 [DEBUG] no postprocessing
Fri Oct 21 02:11:21 2011 [DEBUG] spoolfile unlinked (/var/spool/cups-pdf/SPOOL/cups2pdf-8968)
Fri Oct 21 02:11:21 2011 [DEBUG] all memory has been freed
Fri Oct 21 02:11:21 2011 [STATUS] PDF creation successfully finished (tps)

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cups-pdf 2.5.1-7
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
CupsErrorLog:
 W [20/Oct/2011:09:05:01 +0200] failed to AddProfile: org.freedesktop.ColorManager.Failed:profile object path '/org/freedesktop/ColorManager/profiles/PDF_RGB__' has already been added
 W [20/Oct/2011:11:15:15 +0200] failed to CreateProfile: org.freedesktop.DBus.Error.NoReply:Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
 W [20/Oct/2011:18:52:54 +0200] failed to CreateProfile: org.freedesktop.DBus.Error.NoReply:Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Date: Fri Oct 21 02:15:17 2011
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
Lpstat: device for PDF: cups-pdf:/
Papersize: a4
PpdFiles: PDF: Generic CUPS-PDF Printer
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: cups-pdf
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.cups.cups.pdf.conf: 2011-10-21T02:05:37.689622

Related branches

Revision history for this message
Thomas Schweikle (tps) wrote :
Revision history for this message
Martin-Éric Racine (q-funk) wrote :

That is actually caused by the AppArmor profile that ships with CUPS. It prevents changing the output directory without also altering the AppArmor profile, in addition to cups-pdf.conf options. This is already explained in /usr/share/doc/cups-pdf/README.Debian

Revision history for this message
Martin-Éric Racine (q-funk) wrote :

In addition to the existing explanations, CUPS-PDF 2.6.1-3 further precises which AppArmor file should be altered.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cups-pdf - 2.6.1-3

---------------
cups-pdf (2.6.1-3) unstable; urgency=low

  * Updated [README.Debian] with current AppArmor information. (LP: #879172).
  * Deleted obsolete [debian/NEWS].
  * Removed unused /usr/share/cdbs/1/rules/utils.mk include. Upstream doesn't
    ship a Makefile so common-binary-post-install-arch::list-missing wouldn't
    be able to know if we unintentionally missed anything.

cups-pdf (2.6.1-2) unstable; urgency=low

  * Renamed old maintainer scripts for debhelper consistency:
    + source_cups-pdf.py to cups-pdf.py
    + presubj to cups-pdf.bug-presubj
    + ppd-updater to cups-pdf.ppd-updater
  * Stripped the unnecessary shellbang from ppd-updater as well.
 -- Ubuntu Archive Auto-Sync <email address hidden> Tue, 01 Nov 2011 10:32:33 +0000

Changed in cups-pdf (Ubuntu):
status: New → Fix Released
Revision history for this message
Josef Wolf (jw-raven) wrote :

Unfortunately, I still see this bug in 2.6.1-6.

I experience the same problem, although I have not changed the output directory (so it's still at its default ~/PDF) and the proposed lines in /etc/apparmor.d/usr.sbin.cupsd are set as suggested above.

I don't see how the bug could have been fixed if the core of the problem has not been addressed at all. The debug logs above show clearly that the output file is deleted immediately after creation. My debug logs are exactly the same. So what has apparmor to do with that? Apparmor would _prevent_ the creation of the file. But what's the point of _deleting_ the file after creation? Is there any point in using cups-pdf if you would not want to _keep_ the generated file?

Revision history for this message
Josef Wolf (jw-raven) wrote :

I have now tried to set the output directory to /var/tmp/PDF and set this directory to mode 1777

The result is the same: the file is created, then deleted, and at the end comes the error message that the file mode could not be set. Not a big surprise, since changing the mode of a deleted file is likely to report an error.

Revision history for this message
Chelmite (steve-kelem) wrote :

I have the same problem, but I moved the apparmor file, usr.sbin.cupsd, to /etc/apparmor.d/disable and restarted apparmor: "service apparmor restart".

Revision history for this message
Chelmite (steve-kelem) wrote :

I failed to mention in #7, above, that this did not solve my problem.

Revision history for this message
Chelmite (steve-kelem) wrote :

I tried commenting out the output specification in /etc/cups/cups-pdf.conf:

### Default: /var/spool/cups-pdf/${USER}

# Out ${HOME}/PDF

The log file now shows:
Mon Feb 6 17:13:12 2017 [DEBUG] output filename created (/var/spool/cups-pdf/skelem/Purchase_History.pdf)
Mon Feb 6 17:13:12 2017 [DEBUG] ghostscript commandline built (/usr/bin/ps2pdf -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="/var/spool/cups-pdf/skelem/Purchase_History.pdf" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-5563)
Mon Feb 6 17:13:12 2017 [DEBUG] output file unlinked (/var/spool/cups-pdf/skelem/Purchase_History.pdf)
<snip>
Mon Feb 6 17:13:12 2017 [DEBUG] spoolfile unlinked (/var/spool/cups-pdf/SPOOL/cups2pdf-5563)

cups-pdf 2.6.1-21

Revision history for this message
Chelmite (steve-kelem) wrote :

Attached is my /etc/cups/cups-pdf.conf

Revision history for this message
Chelmite (steve-kelem) wrote :

This is my /etc/apparmor.d/usr.sbin.cupsd file.

It already contained the lines:
  @{HOME}/PDF/ rw,
  @{HOME}/PDF/* rw,

I'm dead in the water trying to get firefox to print to a PDF file in Ubuntu 16.10, x86-64.

I even tried adding the line to /etc/apparmor.d/usr.sbin.cupsd:
capability mknod,

as suggested by: https://ubuntuforums.org/showthread.php?t=1654320

but any pdf file written to ~/PDF gets unlinked immediately.

Revision history for this message
Vadim Zeitlin (vz-ubuntu) wrote :

Just in case it can help somebody: I think the message about unlinking the output file is misleading and it never gets created in the first place due to EACCES for a file in /var/tmp shown by strac'ing cups. At least this was the case for me, and I think is also the case in the similar Debian bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931363).

The solution is to either chmod /var/tmp to 777 or create some other directory (I used /var/tmp/cups-pdf) and give everybody the right to write in it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.