https://bugzilla.novell.com/show_bug.cgi?id=481794 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=481794#c1 Johannes Meixner <jsmeix@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Johannes Meixner <jsmeix@novell.com> 2009-03-04 03:03:41 MST --- Disrupting an active print job this way can cause arbitrary results depending on the particular CUPS backend (usb, parallel, socket, lpd, ipp, ...) and the particular state when the suspend hits the backend and the filters. A disrupted print job can usually not be resumed at all because it is usually not possible to re-set the printer in the exact state when the disrupt happened. In this particular case a resume does not make sense because this would mean to block the printer until the computer is resumed (i.e. one client system which is suspended would block the whole printer until the particular client-system is resumed). The default ErrorPolicy in cupsd.conf is "stop-printer" which results that the queue is disabled, see http://localhost:631/help/ref-cupsd-conf.html You should try out if another ErrorPolicy works better. For your particular case I would try "abort-job". I don't think that disrupting an active print job this way is supported at all by the current CUPS version so that I close the report as invalid for the current CUPS version. I assume that currently all you can do is to wait until the print job is sent to a remote queue or until locally active print jobs are finished. I will ask on cups@easysw.com how suspend and resume is suppoded to work with CUPS. -- 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.