Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Claiming Job Completed when GhostScript Runs out of Memory, Causing Print Failed #4824
Steps to reproduce:
It printed nothing, nor the printer received any print command. However, in /var/log/cups/access_log:
In addition, in /var/log/cups/error_log:
It wasted me a few hours to figure out what's wrong. :(
True. But the exit code of Ghostscript is 1 instead of 0. I think, if possible, CUPS should report the message as an "error" message instead of "debug" message. That would make debugging this issue much easier.
Or is Ghostscript called by GutenPrint, causing the exit code of Ghostscript not accessible by CUPS?
The wrapper script may be consuming the Ghostscript exit status - please report that upstream to the Ghostscript folks.
Similarly, it is up to Ghostscript to tell CUPS its message is an error (via an ERROR: prefix), otherwise CUPS will assume it is a debug message (which has been the documented interface with CUPS since 1998...)
I think such issues should not be reported to Ghostscript
I suggest to report such issues to the matching upstream
The caller of Ghostscript could be something like foomatic-rip
If your PPD file /etc/cups/ppd/<queue_name>.ppd contains
cupsFilter ... foomatic-rip
the Ghostscript caller is foomatic-rip which is nowadays
The cups-filters software is from OpenPrinting.org, see
Otherwise inspect you /var/log/cups/error_log
For example if you /var/log/cups/error_log contains
Started filter /usr/lib/cups/filter/gstoraster ... Ghostscript command line: /usr/bin/gs ... -sDEVICE=cups ...
then /usr/lib/cups/filter/gstoraster is the caller of Ghostscript
This is the matching report at Ghostscript
I've found the following in the log:
Does that mean that /usr/lib/cups/filter/gstoraster is the caller?
EDIT: There is no
Yes, /usr/lib/cups/filter/gstoraster is the caller.
See "Bug reports" at