[cups.general] queues going down

Minatra, Pat H. pminatra at hsutx.edu
Mon May 8 06:44:26 PDT 2006


This would be for an lpd device :

device for ACCT2W: lpd://10.1.1.48/print

I have the remote 'print' daemon where it does not spool on the lpd
device; therefore, it pushes the job straight through to the 'printer'.


What I believe I am seeing is the job is being aborted when it runs out
of paper or needs attention to the output bin, brings the queue down and
the print job remains on the server side.

Thank you for your help and have a GREAT day!

-------------------------
"Life is but a twinkle in the eye of eternity"
"The shortest distance between a problem and a solution is the distance
between your knees and the floor"
"sorrow looks back - worry looks around - faith looks up"
Regards,
Pat H. Minatra - N5GJR
(325) 670-5804 voice
(325) 670-1570 fax
Hardin*Simmons University  
www.hsutx.edu
PO BOX 16040
Abilene, TX  79698

-----Original Message-----
From: cups-bounces at easysw.com [mailto:cups-bounces at easysw.com] On Behalf
Of Michael Sweet
Sent: Monday, May 08, 2006 8:36 AM
To: cups at easysw.com
Subject: Re: [cups.general] queues going down

Minatra, Pat H. wrote:
> I have a couple of customers that continually indicate that their
queues
> are going down at the most inappropriate time.  It seems that it is
> happening when the printer runs out of paper or the out bin is full
and
> requires operator intervention to remove it.
> 
> My question is, how long a time frame is given BEFORE the queue gets a
> signal to go down while waiting on human intervention.  I realize that
> this is by design so as to prevent loss of data in the output reports.

That really depends on the backend.

For socket:// and lpd:// devices, in most cases the connection will
either be refused or the job will be aborted while we send it.  For
a connection-refused situation, we retry indefinitely unless the job
was queued on a class (in which case the backend aborts and cupsd
tries the job on the next printer in the class...)  For errors that
occur while we send the job, we abort and stop the queue (this
behavior is configurable in CUPS 1.2...)

For ipp:// devices, we can retry indefinitely unless we get some
sort of fatal error (like "printer doesn't exist").

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com
_______________________________________________
cups mailing list
cups at easysw.com
http://lists.easysw.com/mailman/listinfo/cups





More information about the cups mailing list