Printing frustrations
I updated my workstation to a newer Solaris build last week, and over the weekend realised I need to print a few documents. My print server is running inside my non-global zone, and until this new build was working very nicely with an Epson Stylus Photo TX810FW. You might recall my post about trying to get a Canon Pixma working…. fortunately for me those days are well and truly over.
I noticed that svc:/application/cups/scheduler:default
was in maintenance mode, the logfile claimed that the service was restarting too frequently. This was surprising because as far as I could tell all the scripts the service methods required were working correctly. I was also rather perturbed to see lots of cores from /usr/bin/gs
, all with stacks like this:
feffcac8 gs`cmd_put_list_op+0x7c(8938a9c, 938d488, 10, c4b38e4f) feffcb68 gs`cmd_write_unknown+0x1c4(8938a9c, 938d2e4, 3fff, ffffffff) feffcc18 gs`clist_stroke_path+0x4d2(8938a9c, 88fa30c, 890b034, feffcc48, 8c3a35c, 8c3a1fc) feffcc58 gs`gx_stroke_fill+0x70(890b034, 88fa30c, 8938a9c, 0) feffcd18 gs`do_stroke+0x128(88fa30c, 83c5224, 0, c1ee) feffcd38 gs`gs_stroke+0x77(88fa30c, 1ee, feffcda0, 8164be4) feffd8e8 interp+0x1304(88e1c7c, feffd928, feffda58, 814aaf7) feffd968 gs_call_interp+0xbb(88e1c7c, feffd9e8, 1, feffda54, feffda58, feffd990) feffd9b8 gs_interpret+0x3d(88e1c7c, feffd9e8, 1, feffda54, feffda58, 85bf244) feffd9f8 gs_main_run_string_end+0x30(88e1c28, 1, feffda54, feffda58, feffda54, feffda58) feffda28 gs_main_run_string+0x2c(88e1c28, 85bf244, 1, feffda54, feffda58, 88e1c28) feffda68 run_string+0x25(88e1c28, 85bf244, 2, 0) feffe118 swproc+0xe87(88e1c28, feffec78, feffe150, 0) feffea58 gs_main_init_with_args+0x28c(88e1c28, d, feffeac0, 80e6e8f) feffea88 main+0x53(d, feffeac0, feffeaf8, feffea7c) feffeab4 _start+0x7d(d, feffebf8, feffec04, feffec0c, feffec1c, feffec26)
The command line args recorded in the core appeared to be standard, too. More frustration!
Since this is CUPS, I enabled debugging in /etc/cups/cups.conf
and proceeded to wade through many megabytes of logfiles. As a sanity check I also ran cupsd from the command line, with “-f” so it didn’t daemonize itself.
While letting the error_log percolate a while, I went searching for some elements of the stack trace in google, and quickly came across Launchpad bug 859630.
The response to the bug submitter in that report is woeful. Not only is there apparently no attempt to figure out what the problem is on the user’s system, there is no attempt to help the user fix the problem on their system and there is no interest shown in any recommendation apart from “upgrade to the latest release.”
Now that I’ve solved my problem, I can see that there’s a subtle hint in that bug report which might help others:
If you see the stack trace above, install Evince’s ``/usr/bin/pdftops``.
I was able to confirm this through checking the cups source for relevant text after seeing these messages in the error_log:
D [17/Sep/2012:12:37:43 -1000] [Job 4] Started filter pdftops (PID 17158) E [17/Sep/2012:12:37:43 -1000] [Job 4] Unable to execute pdftops program: No such file or directory D [17/Sep/2012:12:37:43 -1000] [Job 4] Set job-printer-state-message to "Unable to execute pdftops program: No such file or directory", current level=ERROR
Of course, I do have /usr/lib/cups/filter/pdftops
(and I did try symlinking it to /usr/bin/pdftops – no joy) – it was the evince version which was truly required.