https://bugzilla.novell.com/show_bug.cgi?id=337665#c8
Johannes Meixner changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Info Provider|com.opensuse@bucksch.org |
Resolution| |INVALID
--- Comment #8 from Johannes Meixner 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.