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

Mark Krenz mark.krenz at cookmedical.com
Wed Jul 11 12:02:43 PDT 2007


Kurt Pfeifle wrote:
> *IF* it is a problem with CUPS: 1.1.17 is a nearly 5 year old release.
> I don't think you can reasonably expect to find anyone who still has
> that old a system to try and reproduce some scenarios for you, or even
> fix bugs.
>
> 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.  I 
actually just installed this machine last month and the reason why we 
had to go with RHEL 3 is because the jBase 3.x series doesn't work on 
RHEL 4 and probably not on 5 either.  Actually, the last supported 
version of Linux for jBase 3 was RedHat 9.  I know I know.  But I'm not 
the one in control of what they use here.

> (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.  Also, the jbase 
service and cups are on the same machine.

  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).  So it doesn't really timeout.

> Have you checked access_log for any connection attempts from the
> Java DB host?
>   
Yes, the jobs don't end up in the access_log.  I've tried restarting the 
jBase system (just the daemons) and that makes the lpr processes die 
out, but they don't actually get sent through cups.
> Have you enabled "LogLevel debug" and monitored what goes into the
> error_log?
>   
Yes, nothing helpful.  There are some problems connecting to some 
printers, but that is normal as some of the printers will have problems.
> Is the cupsd.conf exactly the same for your problematic CUPS install as
> is for the one that shows no glitches?
>   

Yes, except that I have different sets of printers.  About 30% of the 
printers are shared by each system.

Also, right now the log level on the problem system is at warn and on 
the system that works its at info.  The md5sums of the client.conf and 
classes.conf files are the same on both machines, so there is no 
difference there.

> 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.


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?

Another thing I want to be clear on, does lpr talk to the printer at 
all?  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.

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?

Thanks for your help.

Mark





More information about the cups mailing list