After updating ports to revision r527186, cups-pdf stopped working on my system. Enabling debugging output from cups, I see: D [29/Feb/2020:17:14:18 -0700] [Job 1613] PID 66844 (/usr/local/libexec/cups/backend/cups-pdf) crashed on signal 11. in the error_log. This happens when trying any printing to the cups-pdf device, be it a test page through the cups web interface or just trying to send any file to the virtual printer. Reverting to revision r506647 (svn update -r506647 in the /usr/ports/print/cups-pdf directory and reinstalling the port) and restarting the cupsd service restores print to pdf capability. I can "print" anything to PDF so long as I don't update to revision r527186. For the moment, that's an acceptable solution. It would still be nice to get past it. I am unable to get any core file or anything from the cups-pdf run, and don't know how to invoke it in any meaningful way to make it do something other than print its help (which does NOT segfault). Other than the notification that the backend crashed in the printer status page of the cups web interface, and the single line reporting it died with signal 11 in the error_log, there is no information I can find to diagnose what's wrong here. My uname: FreeBSD xxxx.xxx 11.3-STABLE FreeBSD 11.3-STABLE #1 r354399: Wed Nov 6 11:58:48 MST 2019 xxxx@xxxx.xxx:/usr/obj/usr/src/sys/GENERIC amd64 I have built cups-pdf with the HOME_SUBDIR variable set to "PrintToPDF," so printing to PDF deposits the PDF in a subdirectory of the user's home directory called "PrintToPDF". The relevant chunk of /usr/local/etc/cups/printers.conf: <Printer Virtual_PDF_Printer> UUID urn:uuid:ef6198c4-1832-36b4-6420-be36d560509a Info Virtual PDF Printer Location The Virtual World MakeModel Generic CUPS-PDF Printer DeviceURI cups-pdf:/ State Idle StateTime 1583022141 ConfigTime 1457822941 Type 8450124 Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer </Printer> The PPD file I have installed in /usr/local/etc/cups/ppd for this printer has no diffs to the one that is installed by the port (/usr/local/share/cups/mode/CUPS-PDF.ppd) except that the on installed by the port has "A4" paper size and mine has "Letter" on exactly four lines. I can do other experimenting and reporting of information as needed.
Possibly related. I am unable to obtain output from cups-pdf through the mate desktop. The pdf file is created but it is left in `/var/spool/cups/` rather than `/var/spool/cups-pdf/username/` and has a name in form `d01676-001`. If I open the cups webpage then cups-pdf shows this: ` cups-pdf-1672 Unknown Withheld 168k 17 pending since Fri May 15 11:03:09 2020 "Backend failed" cups-pdf-1676 Unknown Withheld 58k Unknown pending since Wed May 27 10:58:52 2020 ` This behaviour began after January 20, 2020.
And cups-pdf was installed through pkg.
This is what is in /var/cache/pkg relating to cups-pdf: find /var/cache/pkg -type f -name \*cups\* -exec ls -D '%F' -l {} \; | sort -k6 | grep cups-pdf -rw-r--r-- 1 root wheel 23376 2018-10-25 /var/cache/pkg/cups-pdf-2.6.1_4-4e9e1e3d16.txz -rw-r--r-- 1 root wheel 23836 2019-03-30 /var/cache/pkg/cups-pdf-2.6.1_4-23dc9778df.txz -rw-r--r-- 1 root wheel 26360 2020-03-17 /var/cache/pkg/cups-pdf-3.0.1-40d4d99245.txz -rw-r--r-- 1 root wheel 26376 2020-05-24 /var/cache/pkg/cups-pdf-3.0.1-152f428636.txz The update to cups-pdf-3.0.1 on 2020-03-17 seems to be when the problem started.
And, finally, when printing from mate to the cups-pdf printer the progress window reports that the backend had a segmentation fault but I cannot find this recorded in the logs.
about cups-pdf version 3.0.0 cups-pdf crashes at code group=getgrnam(Conf_Grp); grpstat=setgid(group->gr_gid); while setting new gid for own process. Conf_Grp is NULL. this is because conf file assumed /etc/cups/cups-pdf.conf and cannot be opened. And at this stage nothing can be logged (previous function read_config_file(filename); tries to do log_even, but log file still not open...) And this is because of mistake in Makefile: in pdf-conf.h now contains /* location of the configuration file */ #define CP_CONFIG_PATH "/usr/local/etc/cups" but current Makefile tries to correct this: post-configure: @${REINPLACE_CMD} ${_SUBST_CMD} ${WRKSRC}/extra/cups-pdf.conf @${REINPLACE_CMD} -e \ 's,CPCONFIG "/etc/cups/cups-pdf.conf",CPCONFIG "${ETCDIR}/cups-pdf.conf",' \ ${WRKSRC}/src/cups-pdf.h So solution: 1) Makefile should be corrected like this: --- Makefile.orig 2020-06-07 15:42:18.182963000 +0300 +++ Makefile 2020-06-07 16:50:19.899876000 +0300 @@ -78,7 +78,7 @@ post-configure: @${REINPLACE_CMD} ${_SUBST_CMD} ${WRKSRC}/extra/cups-pdf.conf @${REINPLACE_CMD} -e \ - 's,CPCONFIG "/etc/cups/cups-pdf.conf",CPCONFIG "${ETCDIR}/cups-pdf.conf",' \ + 's,\#define CP_CONFIG_PATH "/etc/cups",\#define CP_CONFIG_PATH "${ETCDIR}",' \ ${WRKSRC}/src/cups-pdf.h do-build: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~` 2) if your ever edit cups-pdf.conf and set Grp to nonexistent group, e.g. lp, cups-pdf will crash silently. So I propose add some code to tell about it to stderr: --- src/cups-pdf.c.orig 2017-02-24 18:32:46.767977798 +0200 +++ src/cups-pdf.c 2020-06-07 16:18:14.701263000 +0300 @@ -374,7 +374,13 @@ (void) umask(0077); group=getgrnam(Conf_Grp); + if (group != NULL) grpstat=setgid(group->gr_gid); + else { + fprintf(stderr,"Get group data (getgrnam) failed! group name was %s\n",Conf_Grp); + fprintf(stderr,"GID of process not changed!\n"); + return 1; + } if (strlen(Conf_Log)) { if (stat(Conf_Log, &fstatus) || !S_ISDIR(fstatus.st_mode)) { ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ put this in file like patch-group_cups-pdf.c and put it inf folder files/ (create int port's folder).
(In reply to taras.filatov from comment #5) Sorry, mistake -- it's about cups-pdf-3.0.1...
Has this already been fixed by Bug 246955?
This does appear to have been fixed quite some time ago in git commit 709dd0f0 to the ports repo which applied a patch that basically did what was suggested in comment 5, but did not reference this issue in bugzilla.
And I should note that I've been using cups-pdf after the patch since around June of 2020, I should have closed the issue myself.