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.

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
>