[cups.general] Jbase and cups and a stuck queue,hopefully someone recognizes this problem.

[Kurt Pfeifle]

Mark Krenz wrote:
> Kurt Pfeifle wrote:

[...]
>> Can't you build/install the newest version of CUPS 1.1.x (1.1.23)?
>>   
> I probably could with some work, but its not quite that simple. 

[...]
That's why I added my next paragraph...  ;-)

>> (You don't need to overwrite your current installation; you can put
>> it into a private directory, tweak the PATHs in cupsd.conf and start
>> it up alternatively to your current installation for testing...)
>>
>> ---
>>
>> So you don't know why your Java DB does not transmit jobs to CUPS?
>>   
> This is a common misconception.  Its not actually based on java at all,
> it just has j in the name.  Actually, it predates Java. 

Ah, sorry.

> Also, the jbase
> service and cups are on the same machine.

Yes, I understood that much about your setup. I didn't imply that both
are on the same machine when asking "your [...] DB does not transmit
jobs to CUPS?"...

>  It submits a job to cups by running lpr and piping the data to it.  The
> lpr process sits there forever (we've seen times as high as 2-3 hours). 

If so, your lpr may be waiting for the piped-in data. Can you rule out
that the db process supposed to pipe data to lpr does fail to do so?

> So it doesn't really timeout.

I assume the lpr process is indeed CUPS's own lpr client command (which
talks IPP to the CUPS server).

You can simulate an open, no data sending pipe to lpr by doing

   cat - | lpr

It will wait forever (or until the next reboot), not just "as high as 2-3
hours".

[...]

>> Are the printqueues the same set (or partially the same) on both CUPS
>> servers?
>>   
> No as mentioned above.  Also, the printers/drivers/protocols are
> different.  Several printers are the same.  But we've seen this happen
> with printers that are IPP, JetDirect, Raw print driver, Text only,
> etc.   And there is no consistency in what physical type of printer it is.

This indicates more that your lpr process never gets any data to pass
on to the cupsd, than it indicates anything to be wrong with CUPS....

My suggestion to you is to change the "piping" thingie. Instead, let
the DB write its job to a temporary file; and let then lpr print that
file (and delete it when done; see the "-r" parameter for lpr in the
man page).

This way you can better discover if the DB fails to write its jobfiles
sometimes.


> To answer a few questions about cups internals that support at jBase has
> been asking, does the Timeout option in cups.conf affect both the time
> lpr would wait to inject a job into the queue as well as the time it
> would wait for cups to send the job to the printer?

This has nothing to do with it. Your lpr does not have data to inject
into the queue. It was told to wait for data to arrive at its stdin,
and that's what it does. Forever, until an indication of "End of data"
arrives.

The cupsd.conf timeout is for HTTP and IPP connections from and to
the CUPS server.

Your lpr process does not even open such a connection yet. It is still
waiting for its own data... (You saw it in your access_log too: CUPS
does not see a connection coming in from your hanging lpr...)

> Another thing I want to be clear on, does lpr talk to the printer at
> all?  

No.

"lpr" and "lp" talk to "cupsd". cupsd queues the job ones it is arrived,
and runs it through the filters. The last filter is a special one, and
also called a "backend". The CUPS backends hosted on the CUPS server
where the cupsd runs talk to the printers. (And they are separate pro-
cesses). Standard backends to send jobs to printers which are shipping
with CUPS live in /usr/lib/cups/backend/ and are called "parallel",
"serial", "ipp", "http", "socket", "scsi", "usb" and "lpd"

> The way I understand cups is that lpr would give the job
> completely to cups and then cups would initiate the connection with the
> printer and that would show up in the process table as an ipp://.... or
> socket://.... process.

Basically correct (but they'll not show with their '://' parts).

> Also, how does lpr communicate with cups?  By directly putting the job
> in the queue, by talking to port 631 on localhost or via a unix socket?

* Talking IPP to port :631 on remote host's IP address if you have a
  client.conf pointing to a remote "ServerName"

* Talking IPP to port :631 on localhost if you have an empty
  client.conf (or one pointing to "ServerName localhost"

* Talking to the local cupsd via a unix socket *only* if you have
    (a) a CUPS version of at least 1.2.0
    (b) an unix socket configured as "Listen /path/to/socket" in your
        cupsd.conf

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany