Red Hat Bugzilla – Bug 353891
CUPS ignores abort-job error policy
Last modified: 2009-10-29 07:32:42 EDT
Description of problem:
Sending a job to a [LPD] printer configured with error policy abort-job when the
printer is unavailable results in the printer being stopped (and having to be
manually restarted) rather than simply dropping the job and carrying on.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure printer to abort-job on error.
2. Make sure printer is unavailable (e.g., move network so LPD server cannot be
3. Send a job to that printer.
Printer stopped in CUPS.
The lpd backend loops forever until it can connect to the printer. Does 'lpstat
-t' actually say that the printer is stopped, or do you mean that the job is
still active in the queue?
[james@harmony ~]$ lpstat -t [Output edited]
scheduler is running
system default destination: ml1210
device for ml1210: lpd://print.ettle.lan/ml1210
ml1210 accepting requests since Mon 29 Oct 2007 07:51:52 GMT
printer ml1210 disabled since Mon 29 Oct 2007 07:51:52 GMT -
ml1210-538 james 700416 Mon 29 Oct 2007 07:51:44 GMT
I'm having trouble getting this to happen here. Here are the steps I took:
1. Start system-config-printer
2. Add a new LPD printer, 'localhost' with queue 'foo' (cups-lpd is not running)
3. In 'Policies', set the Error Policy to 'abort-job'
4. In 'Settings', add "?contimeout=35" to the end of the Device URI, so that the
job fails after 35 seconds instead of a week
5. Print a test page
6. Wait for 1 minute
7. lpstat -t
printer test is idle. enabled since Mon 29 Oct 2007 15:30:51 GMT
Please attach your /etc/cups/printers.conf, or at least the part of it relevant
to ml1210. Thanks.
This is from /etc/cups/printers.conf, with the printer ml1210 in the stopped
state having failed a job.
Info Samsung ML-1210
Location Samsung ML-1210
StateMessage /usr/lib/cups/backend/lpd failed
JobSheets none none
Now the dummy printer foo is configured as:
JobSheets none none
Now lpstat -t gives:
printer foo is idle. enabled since Mon 29 Oct 2007 16:07:52 GMT
The problem can be provoked by providing a host name that does not resolve:
1. Change foo's URI to lpd://thishostdoesnotexist/foo?contimeout=35
2. Try printing a test page.
lpstat -t now gives:
printer foo disabled since Mon 29 Oct 2007 16:13:46 GMT -
Ah, now I see the problem here too. I think it's because the backend exits with
a special exit code to tell cupsd to stop the printer, rather than that the job
failed. I've filed a bug report upstream.
This still happens in 1.4.1-4. Why this bug is CLOSED? UPSTREAM report does not change the fact that this bug still exists in Fedora and this bug entry should remain NEW or ASSIGNED as long it disappears.
Upstream description http://cups.org/str.php?L2577 :
> when the hostname cannot be resolved.
In my case this happens when the printer is switched off and cannot be reached over network (internal HP-jetdirect interface).
Re-open this bug please. People don't find it otherwise.
Please check the resolution definition for UPSTREAM:
This is a valid state for Fedora bugs.
This particular bug concerns the (intentional, as it turns out) behaviour when the hostname cannot be resolved.
Please open a separate bug report if you are seeing incorrect behaviour when the hostname *can* be resolved but the printer cannot be reached.
(Although, from inspection of the source code, the lpd backend only ever exits with the CUPS_BACKEND_STOP exit code when the hostname cannot be resolved.)
(In reply to comment #7)
> Please check the resolution definition for UPSTREAM:
> This is a valid state for Fedora bugs.
Yes it is. But fact is, that this flaw still exists in product.
Flagging it CLOSED is wrong, the UPSTREAM should be status, not a CLOSED's resolution.
Bug database should be part of/extension of documentation, not just valid on certain point of time and then rely on external sites without easily linked references (CLOSED gets buried away).
That is, however problem of policy, not cups so perhaps i raise that up in -devel list some day when i've enough energy to face all the flamware coming from it.
I think the rationale given in the CUPS Bugzilla is understandable. It becomes a problem from a user perspective on a portable machine when you accidentally print to a queue that's not available (typically by moving network), and then move to where it is available and have to manually restart the printer. You might wish to suggest that CUPS should adjust the queues e.g. when network status changes (NM/DBUS hook?); in particular, it could stop all queues with a network backend when there's no connection.