On Wed, 27 May 2009, Thomas Koppe wrote:

> hi,
>
> we use 2 cups servers with SL53 and cups-1.3.7 (default rpm)
> an our clients use SL53 too with the same cups-1.3.7 release.
>
> the server name is primas1
>
> the config on all clients config is: running a local cupsd and
>
> device for printerX: http://primas1:631/printers/printerX?waitjob=no
>
> the server config for the same printer is:
>
> device for printerX: socket://printerX
> (there runs a cupsd too)
>
> if the queue on server is disabled (cupsdisable printerX)
> then it's impossible to send jobs to this server and
> the first lp command on client disables the printer
> queue on client too - also if spooling on server is enabled.
>
> as long we used cups up to version 1.2.4-11.18.el5 the error doesn't appear. 
> the bug is seemed to fixed in version 1.3.10.

I've occasionally seen this when printing from MacOSX boxes to our SL cups 
servers but had assumed it was a Mac bug 'cos we hadn't seen it on the SL 
machines (though we rarely disable printing for a queue without also 
disabling spooling anyway)...

A quick search shows http://cups.org/articles.php?L575 - the announcement 
of 1.3.9 includes a fix listed as:

   The IPP backend incorrectly stopped the local queue if the remote server
   reported the "paused" state.

which is the closest I can find.  Sadly that doesn't list an obvious STR 
so obtaining a patch which could be easily applied to earlier versions 
might not be trivial, and pursuading TUV to update to 1.3.9 or 1.3.10 
may take a lot of doing - they only just updated to 1.3.7 from 1.2.x :-)

I see that Apple recently updated the cups in OSX 10.5 to 1.3.10 so for a 
while at least they are actually up to date!

I'm seriously thinking of updating my cups servers to 1.3.10 mostly to get 
the new pdftops (back-ported from cups-1.4 where pdftops is just a wrapper 
around one of a variety of pdf handlers...)

  -- Jon

> best regards thomas
>
> On Wed, 27 May 2009, Troy Dawson wrote:
>
>>  Thomas Koppe wrote:
>> >  Hi there,
>> > 
>> >  we send all print-jobs to cups (IPP) servers (scientific linux 5.3, 
>> >  cups-1.3.7). If one queue on server is disabled for printing but enabled 
>> >  for
>> >  spooling then the following happens: if the first job from client will 
>> >  be send to server the local queue will also be disabled and the job 
>> >  remain in
>> >  the local cups queue. Jobs would only be sent if the server queue is 
>> >  enabled.
>> >  The local queue is then explicit to enable by root.
>> > 
>> >  Is this a known bug ? What can I do in Scientific Linux ?
>> > 
>> >  Best regards Thomas
>>
>>  Hi Thomas,
>>  I just want you to know that both of your posts to this list arrived.  I
>>  was a bit surprised that nobody responded the first time.
>>  I am not a cups expert, but we'll see what we can find.
>>
>>  What does your configuration of the printer look like when it is disabled
>>  but enabled for spooling?  Can you send that part of the configuration
>>  file? Or is this all being handled via some interface like cups web
>>  interface.
>>
>>  Also, what OS is the client running?  That might have something to do with
>>  it as well.
>>
>>  Troy
>> 
>
>

-- 
/--------------------------------------------------------------------\
| "Computers are different from telephones.  Computers do not ring." |
|       -- A. Tanenbaum, "Computer Networks", p. 32                  |
---------------------------------------------------------------------|
| Jon Peatfield, _Computer_ Officer, DAMTP,  University of Cambridge |
| Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/ |
\--------------------------------------------------------------------/