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