Bugzilla – Bug 131097
cups should enable printer when it is turned on
Last modified: 2006-05-10 11:38:24 UTC
I have a USB laserjet printer. The printer was initially turned off. I tried to print and cups disabled the printer (it's possible that the printer was already turned on during the uptime though, I don't quite remember). Anyways on the current print attempt it was off. Being disabled while turned off was ok, but after I turned it on the printer staid in disabled state and I had to manually enable it to print again. For a normal end user that would have been a showstopper, even for me it cost some time for investigation.
If only one USB printer is used, see http://www.cups.org/str.php?L1267 how you can avoid at least one situation which disables the queue (i.e. use the generic DeviceURI "usb:/dev/usb/lp0"). You can switch YaST to use generic DeviceURIs for USB printers. Or via command line use "lpadmin -p QUEUE -v usb:/dev/usb/lp0" to change the DeviceURI to the generic style. Again: This works o.k. only if you have only one USB printer. See for example the mail http://www.easysw.com/cups/newsgroups.php?s5622+gcups.general+v5627 and the next two mails for an explanation why the queue must be disabled by default in case of a data transmission error. In the next CUPS version the USB backend will do endless retires in any case and additionally the next CUPS version adds an error policy which allows to configure how CUPS handles these errors (something like abort retry ignore) => will be FIXED.
It was not a real transmission error, the device was simply not there (turned off) Endless retries etc. are wrong too. disabling is ok when the device is not there. But what it should do is to just watch for the hotplug event when it sees the USB device first and then enable the printer if disabled. Basically I think you need to add a little hook to the USB hotplug script that handles this case.
Kay might have some input on this.
Regarding comment #2: I understand your request. It comes very often on the CUPS mailing list. The request looks easy but if it was so easy, it would have been already implemented. Regarding "watch for the hotplug event": I think it is up to the backend to do this. As far as I understand the CUPS design it is not the cupsd which should care about the plain data transmission to the recipient because this is delegated to the various backends, see http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html "The Backends" Therefore it is o.k. when the backend keeps running and polls each 30 seconds for the printer - this should not cause a too high system load. From my point of view it may be nicer than polling when the backend falls asleep and is waked up by a hotplug event - but does this work in any case - even without special hotplug/udev/HAL deamons running? In any case: We won't do such changes for 10.0 => Enhancement request for 10.1 and reassigned to CUPS maintainer.
hotplug/udev/hal is running on SUSE and that is what matters. I wouldn't change anything with cups itself, but just add a script on printer hotplug that looks for the associated queues and when they are disabled automatically enables them.
Ahh! Thanks for clarification. Regarding "automatically enable": What if the admin had disabled the queue intentionally? It should stay disabled even if a normal user unplugs and re-plugs the USB cable. I think the CUPS error policy (see comment #1) is the better way to handle it.
I think it's reasonable to let cable hotplug/printer reset overwrite queue disable. If someone has access to the hardware like this they're basically like the admin. In theory you could implement two different disabled states to distingush it, but that would be probably overkill. Polling is definitely not a good idea. I don't want to wait 30seconds and it's just dumb in general.
RH plugs into the HAL callout mechanism to notify cups about printer changes: http://cvs.fedora.redhat.com/viewcvs/devel/hal-cups-utils/
Thanks. To disable the printer, as soon as an error occurs, is done with intention. We had a long description regarding this in the administration handbook. But first was this chapter reduced to some basic hints, now this book no longer shipped. Thats were we must start to point at, if we blaim and cry. :-( Next thing is, that printing isn't included in our free "installation support" for customers... Anyway: I accept your point of view and your bugreport is valid. But our explanation, why we won't change the behavior isn't false neither. So we don't change the behavior here and keep being in sync with the CUPS project itself. This contains the advantage that our users can ask at public mailing lists, why this-and-that is not working in CUPS, and they can expect to get a response from there. Thanks for understanding.
This problem should be fixed in CUPS 1.2 which is now released. http://www.cups.org/str.php?L1267 Will there be an update for 10.1 or at least for SLES10?
No. No updates for our old products. cups-1.2.0 is not stable, at least not for our needs. E.g. Browsing is no longer working after a "reload" of cupsd is done. It is not possible to use an old 1.1.x configuration with cups-1.2.x, they are incompatible. Other fundamental changes took also place ==> a smooth upgrade is neither possible.