Bug 353891 - CUPS ignores abort-job error policy
CUPS ignores abort-job error policy
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-26 07:06 EDT by James
Modified: 2009-10-29 07:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-29 12:46:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 2577 None None None Never

  None (edit)
Description James 2007-10-26 07:06:46 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):
cups-1.2.12-5.fc7

How reproducible:
Always.

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
reached).
3. Send a job to that printer.
  
Actual results:
Printer stopped in CUPS.

Expected results:
Job dropped.
Comment 1 Tim Waugh 2007-10-26 07:38:05 EDT
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?
Comment 2 James 2007-10-29 04:12:37 EDT
[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 -
        /usr/lib/cups/backend/lpd failed
ml1210-538              james           700416   Mon 29 Oct 2007 07:51:44 GMT
Comment 3 Tim Waugh 2007-10-29 11:38:05 EDT
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
        /usr/lib/cups/backend/lpd failed

Please attach your /etc/cups/printers.conf, or at least the part of it relevant
to ml1210.  Thanks.
Comment 4 James 2007-10-29 12:15:51 EDT
This is from /etc/cups/printers.conf, with the printer ml1210 in the stopped
state having failed a job.

<DefaultPrinter ml1210>
Info Samsung ML-1210
Location Samsung ML-1210
DeviceURI lpd://print.ettle.lan/ml1210
State Stopped
StateMessage /usr/lib/cups/backend/lpd failed
StateTime 1193644312
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy abort-job
</Printer>

Now the dummy printer foo is configured as:

<Printer foo>
Info 
Location 
DeviceURI lpd://localhost/foo?contimeout=35
State Idle
StateTime 1193673946
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy abort-job
</Printer>

Now lpstat -t gives:

printer foo is idle.  enabled since Mon 29 Oct 2007 16:07:52 GMT
        /usr/lib/cups/backend/lpd failed

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 -
        /usr/lib/cups/backend/lpd failed
Comment 5 Tim Waugh 2007-10-29 12:46:29 EDT
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.
Comment 6 Juha Tuomala 2009-10-29 03:35:58 EDT
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.
Comment 7 Tim Waugh 2009-10-29 06:01:06 EDT
Please check the resolution definition for UPSTREAM:
  https://bugzilla.redhat.com/page.cgi?id=fields.html#status

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.)
Comment 8 Juha Tuomala 2009-10-29 07:16:43 EDT
(In reply to comment #7)
> Please check the resolution definition for UPSTREAM:
>   https://bugzilla.redhat.com/page.cgi?id=fields.html#status
> 
> 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.
Comment 9 James 2009-10-29 07:32:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.