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

[Helge Blischke]

Mark Krenz wrote:
> 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
> 

Keep in mind that CUPS's lpr command needs to collect the STDIN data to print
into a temporary file (the IPP protocol, which is how to talk with cupsd,
requires an ordinary file to be transmitted to the CUPS server). Thus it
is necessary to clise the STDIN input at the "end of job" condition.

 From what you told us, it seems that your process that pipes to the lpr
command assumes that the printer magically begins to print if the supply
of new data gets stalled for a minimum amount of time.

Perhaps you need to wrap that process and implement a timeout routine
that causes the lpr command to normally exit in order to submit the
data to CUPS.

Helge


-- 
Helge Blischke
Softwareentwicklung

H.Blischke at acm.org