Bugzilla – Bug 337665
Temporary printer problem disables printer, needs admin to fix
Last modified: 2009-02-09 00:33:09 UTC
Reproduction: (typical day-to-day end-user scenario) 1. Put only 2 sheets of paper in your printer, or no paper at all 2. Print a document with 3 pages 3. When printer complains, refill paper 4. Press print again and again and again Actual result: When the printer is out of paper, CUPS automatically disables the printer. You can only reactivate it by going to the CUPS admin console, entering the admin (typically root) password, and enable the printer. Expected result: - When the printer has paper again, the printing of the current job resumes and new jobs are carries out as well. - Or, worse, but far better than now: Only cancel current job, but keep printer active. Importance: This is an extremely common end user scenario. Clueless newbies being out of paper happens all the time. I just had to remote assist my father because of that, and felt embarrassed for Linux. Of course he felt no need to tell me that he once was out of paper, because that's a completely normal and unproblematic situation for him - put paper in and all is well. And he's right: It's a complete non-issue on all other systems I used in the last decade. The first time that happened, it took me *hours* to figure out what happened. I did not imagine that such a simple, temporary problem would permanently disable a printer. You need an admin to recover from "out of paper". It may make sense for a big facility where the printer has its own admin (and that admin can reconfigure CUPS all he wants), but makes no sense at all in the normal desktop situation where you have an average users who doesn't know what "print jobs" are, much less the admin interfaces or root password. The average users are the majority and rely on the default settings, so the default needs to change.
(IOW: Default error policy should be "abort-job", not "stop-printer")
Out of paper works well for my printers - exactly as you expect it to work: Printing stops until one inserts paper, then printing continues. Therefore what happens for you is not the normal case. The crucial questions to find out why it goes wrong for you are: Which printer model? How is it conected? Which CUPS backend do you use? Please attach all in /etc/cups/ and /var/log/cups/error_log to this bug, e.g. as root do tar -czvf /tmp/cups.tgz /etc/cups/* /var/log/cups/error_log and then attach /tmp/cups.tgz to this bug. See http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "The Backends" Usually the backend waits of there is only out of paper. In your case the out of paper situation leads to the unexpected consequence that for the backend it looks like a severe error (i.e. somehow your printer seems to signal the backend that there is a severe error) and then it would be correct to disable further printing until the admin has fixed the severe error.
>Printing stops until one inserts paper, then printing continues. Are you sure *your* setting is not already stop-printer? If it is set to stop-printer, this is equivalent to calling /usr/bin/disable on the queue when such an error occurs. >Which printer model? How is it conected? Which CUPS backend do you use? As for my part: HP LaserJet 1010, HP LJ 1022, HP DJ 930, HP LJ 2200, LAN, socket://
Regarding comment #3: See your /var/log/cups/error_log why the socket backend assumes there is a fatal error. It is your printer which indicates such a problem - more percisely the network interface of your printer. See http://en.opensuse.org/SDB:CUPS_in_a_Nutshell in the "Configuration of the CUPS network servers" section what to do "If problems are encountered".
I'm using Samsung ML-2010, connected via USB. I saw some strange "usb:/Samsung/ML 2010" URIs, so probably "usb (new)" backend. I use SuSE 10.1, and I don't remember changing settings. The bug is filed against 10.3 due to Jan reporting the same problem there (just that 10.2+ allowes you to change the behaviour, but 10.1 doesn't, to my knowledge).
Created attachment 181170 [details] error_log, cupsd.conf, printers.conf Johannes, please *never* ask users to upload their whole /etc/cups/, zipped or not, because it contains passwd.md5! Here is my error_log (usernames altered), cupsd.conf and printers.conf. the other files didn't have anything interesting, most (e.g. classes.conf) were even empty.
Does it happens only with your Samsung ML-2010 but not with your HP PSC 1400?
In your error_log there is ------------------------------------------------------------------------- I [28/Oct/2007:12:57:22 +0100] Started backend /usr/lib/cups/backend/usb (PID 6632) for job 235. E [28/Oct/2007:12:57:22 +0100] PID 6632 stopped with status 1! E [28/Oct/2007:12:57:22 +0100] [Job 235] Unable to open USB device "usb://Samsung/ML-2010": No such device ----------------------------------------------------------------------- I.e. in case of "paper out" your printer seems to disappear completely from the USB and this is a fatal error for the backend. Therefore for me it doesn't look like a bug in the printing system but more like a bug in the printer. By the way: Automated "Resume" (e.g. when in your casee it might re-appear at the USB after the "paper out") is often asked for on the CUPS mailing list but the answer is always the same: If communication with the device fails, the backend disables further printing. See our online documentation (package suselinux-manual_en) /usr/share/doc/manual/suselinux-manual_en/manual/sec.drucken.prob.html "Disabled Queues" or our support database http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "The Backends" In this state there is no generic way to correctly autodetect when it is really save to send data to the device without risk to loose print jobs. Therefore CUPS waits for an approval from the admin. For CUPS 1.1 and later: If you know that it doesn't matter when you loose print jobs, we provide a backend wrapper "beh" (package cups-backends) which you can use to do infinite retries or to let jobs silently be dropped when they cannot be sent to the device. For business printing this is not a possible solution but for a personal workstation it may be o.k. because the user can more easily re-submit a lost print job (nevertheless it may be annoying e.g. when the printout of a certain web-page gets lost and the page must be loaded again in the browser). See the /usr/lib[64]/cups/backend/beh perl script how to set it up. Only since CUPS 1.2: If you know that it doesn't matter when you loose print jobs, set a different printer-error-policy for the print queue, see http://www.cups.org/documentation.php/man-printers.conf.html and see "man lpadmin", e.g. do lpadmin -p <queue-name> -o printer-error-policy=abort-job
We barely use the HP, so I don't know whether it happens there. I bought the Samsung ML-2010 specifically for Linux. It's one of the few desktop printers which are officially supported. Don't tell me that it's "not good" either. <quote src="http://en.opensuse.org/SDB:CUPS_in_a_Nutshell#The_Backends"> If the data transmission to the recipient fails (usually after several attempts by the backend), the backend will report an error to the print system (more precisely, to cupsd). The backend decides if and how many attempts make sense before it reports that the data transmission has failed. As further attempts would be futile, cupsd disables printing on the affected queue. After eliminating the cause of the problem, the system administrator must reenable printing with /usr/bin/enable (for CUPS 1.1 - i.e. up to Suse Linux 10.1) or with cupsenable (since CUPS 1.2 - i.e. since openSUSE 10.2)." </quote> The last 2 sentences *are* the bug. If "out of paper" is an error, that would result in the printer being disabled, i.e. the bug. Even when the USB cable was accidentally ripped out (somebody tripped over the cable, or rearranged the printer/computer etc.) and it is plugged back in by the user, he expects it to work again, not to need a root password and re-"enable" a printer in some admin console. In other words, removing the USB cable and adding paper is a normal operation done by normal users and must not need root password, admin consoles or any special action at all. > Automated "Resume" (e.g. when in your casee it might re-appear > at the USB after the "paper out") is often asked for on the CUPS > mailing list but the answer is always the same: In that case, the answer is always wrong. The fact that it's often asked should show you that there's something wrong with the software, not the users. As the original description states: Please change the default policy. Average users will just hit the print button again (as you can see from my error log, which accumulated 10 print jobs, because my father kept hitting "print" when nothing happened, which is a normal reaction). Default settings should be for average desktop users, not big sites with remote printers. Big sites can easily change settings, normal users can not, they don't even know the setting.
Oh, there's an even simpler situation: User forgets to power on the printer before he clicks "Print". This would also result in the above situation.
If there was only the "desktop" the right default ErrorPolicy would be relatively easy to find. But we must also have the server systems in mind. Currently we are in compliance with the CUPS upstream defaults and those cannot be too wrong when one has all situations in mind. ErrorPolicy "abort-job" might be annoying even on the desktop, see comment #8 so that ErrorPolicy "retry-job" might be best but this is also annoying if the error happens while a 100 pages job is printed up to page 90 and then because of "retry-job" it is printed again from the beginning. I filed bug #337794 to find a solution. *** This bug has been marked as a duplicate of bug 337794 ***
I don't see what it gains to file a new bug, because all arguments are here, but OK. > But we must also have the server systems in mind. Yes. See above: "Default settings should be for average desktop users ... big sites with remote printers can easily change settings" Dedicated print servers are far more rare than desktop systems, and the former have dedicated admins who can change settings.
Ben Bucksch said: "I bought the Samsung ML-2010 specifically for Linux. It's one of the few desktop printers which are officially supported." What do you mean by "officially" supported? If you mean "supported by the printer vendor", let me tell you that HP provides FOSS drivers (HPLIP), developed in-house, for *all* of their current desktop model portfolio (and most of their past as well). That's not "few"; that alone covers roughly half the market already.
(In reply to comment #10 from Ben Bucksch) > Oh, there's an even simpler situation: User forgets to power on the printer > before he clicks "Print". This would also result in the above situation. Dunno about Gnome's behaviour... but in KDE, if you hit "Print", you get the "kprinter" dialog. That dialog shows a red-ish icon indicating for each queue if is disabled. (I know, that doesn't count for printing from OOo, Firefox or Thunderbird. But it is an indication of the fact that not *all* printing related things are to be solved on the CUPS level only. *Some* of the problems are rooted in the fact that the overall integration of the CUPS desktop/end-user applications aren't well integrating with each other nor with CUPS. CUPS *knows* about disabled queues, and it *tells* you if you ask it. The thing is that the GUI apps need to ask it and tell the result to the user, somehow. It can't be all solved by CUPS on its own....)
You SuSE guys have the tendency of blaming the user, and being stubborn. This bug, more precisely your incredible reaction to such a basic and serious every day user problem, is a major reason why I consider switching to another distro. I know it doesn't mean much to you. But that in itself is a problem, because soon, there won't be many users left.