Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
On Mon 22 Aug 2016 at 19:36:32 +0100, Brian Potkin wrote:
> On Fri 19 Aug 2016 at 12:42:51 +0100, Patrick Welche wrote:
> >
> > <Printer ufs2>
> > DeviceURI implicitclass:ufs2
>
> You have duplicate queues being broadcast on the network; is this your
> intention? cups-browsed combines them into one Implicit Class queue.
That could be misleading. The duplicate queues are duplicate in the
sense they have identical names. At least two queues called ufs2 should
be on the network for cups-browsed to use the implicitclass URI. ufs2
and UFS2 are duplicates because queue names are case-insensitive when it
comes to printing.
> Servers A and B were set up with identical print queues. A largish file
> was sent five times in rapid succession from the client. I expected the
> printing to be distributed between A and B because of load balancing.
> It wasn't; everything went to A.
>
> I then disabled the queue on A, expecting B to be used. Then came
>
> No suitable destination host found by cups-browsed.
>
> in 'lpstat -t'.
>
> Maybe I am doing some wrong but it does look like a bug in cups-browsed.
Let's go with "Maybe I am doing some wrong". It took me some time to
realise having cups-browsed running on A and B wasn't exactly conducive
to having two broadcast queues. Then I (perhaps rashly) purged and
reinstalled all cups related packages. Since then I have been unable to
reproduce the previous behaviour; load balancing works as described when
A and B are doing Bonjour broadcasting. (I realise this is not your
situation but did not want my initial remarks to muddy the waters).
Cheers,
Brian.
Reply to: