Re: [cups.bugs] Re: Re: [HIGH] STR #1311: if the /var/spool/cupsfilesystem is full, no error is returned to requests coming in vialpr -- thus, print requests are lost [Auf Viren geprüft]

Michael Sweet mike at easysw.com
Tue Oct 11 05:11:49 PDT 2005


Peter.Prasnik at edeka.de wrote:
> ...
> why receive them in the first place (sucessfully, as cups pretends) if
> /var/spool/cups is full? (By the way, what space are they received into --
> if there is no space left on the spooling filesystem?)

cups-lpd receives files into TMPDIR, which is typically /var/tmp or
/tmp.  Even if you set TMPDIR to /var/spool/cups/tmp (or your spool
directory), cups-lpd still will be unable to detect if there will not
be enough space since the print file is actually spooled twice - first
for the LPD request, and second for the IPP request.

> Could you not perhaps abort the reception of the job files( thus render it
> unsucessful and signal an error to the sending lpr)  if the spooling
> filesystem does not have the space to process them?

And how can we know that?  cups-lpd does not (and will not!) read
cupsd.conf, since it is not a subprocess of cupsd and we do not know
*which* cupsd.conf to read.

Even if we did know which directory was used for spool data, any
check we perform will not be able to guarantee that the space will
be available when the job is queued with cupsd (other jobs may come
in at the same time, other temporary files in the same filesystem
may use up the space, etc.)

> The case I describe IS an error, if cups-lpd doesn't handle it, who (what
> program) is supposed to do it?

cups-lpd can't handle it, because the LPD protocol isn't designed
to handle it.  cupsd detects and reports the problem back to cups-lpd,
but at that point the LPD client has already closed its connection,
assuming that everything will print just fine, so there is no way to
tell the client that the job failed to print...

> On our cups servers, we use backends that create pdf files for archival out
> of incoming print requests. These files contain critical data and may not
> be lost . In the case described, no pdfs are created . Cups returns no
> error, pretending everything worked fine. In this environment, the error I
> describe is a real problem. Was it wrong to expect of a print server  that
> if I send a print request to it, that request will only be accepted without
> error if there is no error?

My advice would be use to CUPS on the Solaris system as well.  If
you want reliable printing, you can't depend on LPD.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com




More information about the cups mailing list