[cups.bugs] [LOW] STR #4240: cups print queue name changes between reboots

[Bozonius]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

I am running a cups server on Scientific Linux (SL) 6.3 with version 1.4.6
(which is admittedly very downrev).  There is a laptop on the wireless
network that uses this host to spool and print jobs.  After months of
maintenance-free operation, suddenly this stopped working about 2 or 3
days ago.

I had not manually modified any configuration on either the laptop or the
server since about 3 months ago, and we had not experienced any issues
since the previous problem using cups.  Each time, it seems, it is a
different cause.  This time was certainly different.

After running wireshark on both the host and the laptop (using the Windows
Vista version of wireshark), I confirmed that the CUPS protocol was being
properly broadcast from the cups server host and CUPS requests were being
properly issued from the laptop each time we attemped to send a print job.

The print queue had been configured as HPC4400, and had not been modified
in any way for months.  This is true on the server and the laptop.  I
checked the print config on the laptop in the control panel and sure
enough it was still called HPC4400.  But I could see that the queue was
now named something else on the server!   How could this have changed if I
did not change it?  Also, why would such an obvious "default name" choice
be given to the queue since I had not installed or reinstalled cups since
August?

About the same time that the print stopped working from the laptop, I had
been trying to sort out a problem with my USB web cam on the cups server. 
Whenever I tried plugging in the webcam, all the other USB devices would
freeze up and stop working.  In fact, the first time I tried it last week,
plugging in the web cam on the running SL system caused a panic and a
kernel dump.  I ran this hardware test several times, trying different
hardware combinations (different USB devices attached at SL boot),
rebooting as soon as I could see whether the system would boot or not.

Examining the cups log, I noticed that the server was still correctly
responding to requests for printers, and returning the HPC4400 entry (the
only one, btw).  Then, about 2 minutes later, it was failing.  Further
down the log, I see it began to list a printer called
"Photosmart-C4400-series" instead of "HPC4400."  It has remained that way
ever since.

I removed and recreated the printer on the laptop and all is well now,
except that it points to a print queue named "Photosmart-C4400-series" not
"HPC4400."  It does all work.

It is abundantly obvious, at least to me, that I personally did not
manually or intentionally change the name of the print queue on the CUPS
server on SL.  So, somehow, the CUPS server software created a kind of
default queue, and it appears to have named that queue based on hints from
the printer it detected.

For my use, this is not really a big problem.  I had chosen "HPC4400"
because it was short and made it easier to type in when I had had other
print/networking issues in the past and had to repeatedly, sometimes,
re-create the print device on the Vista machine.  I'd prefer the shorter
name, and I do know how to go about making the changes if need be.

But I think for a larger number of printers with a larger user base in a
more complex printing environment, this would probably not suffice,
assuming I have indeed found a legit bug.

Admittedly, my selections for priority and scope may not be the most
accurate, but I was not sure how to classify them properly, given the
strange nature of this issue.

Link: https://www.cups.org/str.php?L4240
Version: 1.4.6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error_log
Type: application/octet-stream
Size: 219 bytes
Desc: not available
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20121205/b63e19dc/attachment.obj>