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: jp...@damtp.cam.ac.uk Web: http://www.damtp.cam.ac.uk/ |
\--------------------------------------------------------------------/
