[LOW] STR #4240: cups print queue name changes between reboots
Bozonius <[email protected]> Tue, 4 Dec 2012 23:40:05 -0800 (PST)
| Newsgroups | gmane.comp.printing.cups.bugs |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ cups-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/cups-bugs
error_log
(application/octet-stream, 219 B) - not displayed