Bug 353891

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 -
        /usr/lib/cups/backend/lpd failed
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
        /usr/lib/cups/backend/lpd failed

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.

<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

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:
  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.)

(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.

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.