https://bugzilla.novell.com/show_bug.cgi?id=337665#c8 Johannes Meixner <jsmeix@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|com.opensuse@bucksch.org | Resolution| |INVALID --- Comment #8 from Johannes Meixner <jsmeix@novell.com> 2007-10-30 04:53:12 MST --- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.