Cups daemon dies on some time of inactivity

Juergen Schroeder js at turn.to
Wed Sep 1 23:42:56 PDT 2004


Michael Sweet <mike at easysw.com> wrote:
: Juergen Schroeder wrote:

: Hmm, can you recompile with debug enabled (--enable-debug when you
: run the configure script)?  There are two main places where this could
: crash, and it looks like it might be the printer URI or name is not set
: prior to calling SetPrinterAttrs()?

Will do this, but this maybe took time.

: There is currently no way to set this behavior short of hardwiring the
: printer connections (either via lpadmin or client.conf)

Yes, I fall back to this.

: > BTW the main BUG could be solved independently from this error analysis:
: > 
: > "lpr -r -Ppqueue file"
: > 
: > should remove the file only if the printing had been successfully!

: That wouldn't be consistent with the Berkeley implementation (imagine
: an application using the same print file name calling lpr multiple
: times and having the file mysteriously disappear in the middle of
: writing the print file...)

I  can't  follow  you at this point. If the cupsd runs only the first of
multiple calls of lpr -r will print and remove the file. The others will
catch nothing or your "mysteriously disappearing". If the cupsd is dead,
it ist the same situation: The  first  lpr  -r  removes  the  file  (but
without printing) and the other get also nothing.

A workaround for me would be to wrap lpr with the script:

#!/bin/sh
x=`/usr/local/bin/lpstat 2>/dev/null`
if [ $? = 0 ]
   then lpr.org $*
fi

But I think this should be the standard behavior of lpr.

Juergen 




More information about the cups mailing list