https://bugzilla.novell.com/show_bug.cgi?id=337794#c1 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |com.opensuse@bucksch.org --- Comment #1 from Johannes Meixner 2007-10-30 06:56:03 MST --- *** Bug 337665 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=337665 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c3 --- Comment #3 from Ben Bucksch 2007-10-30 07:26:56 MST --- Please see dup bug 337665 for extremely common situations (e.g. user hits "print" button, but forgot to power on printer, notices and powers on, but nothing works), where an admin is required to recover, including root password, admin console, and most of all knowing that CUPS disabled the printer in the first place (took me hours (!) to figure out, because I didn't expect something like that). Common and trivial user errors like these must not require an admin to recover. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c5 --- Comment #5 from Klaus Singvogel 2007-11-05 02:59:39 MST --- I already thought about doing this differentiation a long time ago too (and several times). I came to the conclusion that we shouldn't do this differentiation for the default configuration here. It's not just the additional maintenace time which will hit us on every update. It's even the fact that we cannot decide if a desktop product will later still used as a desktop product or not. It is known that people use SUSEs non-server products as a server, and that we have customers who use SLES on their desktop. There are many many reasons why this is done (ie. slow migration to a server, which was originally intended as a desktop machine, having a reduction in SLES price by buying multiple licenses, etc). Even more, aborting a job (= loss of data) in case of an error and by default is always an idea we should not even think of; neither for a pure desktop product. We don't know this in advance, if the print-out of the assistant is the only copy and which value it has. We have to deliver a product, which is rock solid (always!), and a loss of data is not the way how we achieve this goal. The only solution I came up with, after I re-thinking on this issue again and again: we have to give the user the choice whether he wants to abort jobs on a reboot or not; and we have to have to communicate the consequences (the loss) of this step. And the customer needs to configure this actively. A place to do so, could be a selection in YaST, as we're targeting users, which might not be familiar with an editor nor with configuration files. :-) But if we offer this choice (= gets implemented by Yast), and now read my warning for the developer, we have to support for all next SuSE Linux versions, means forever. If users accidently print jobs and want to remove them, then we should speak about implementation a GUI solution too: which can remove jobs from a server very easily. This might "fix" this issue too, and might address the real cause of the problem here. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c7 --- Comment #7 from Ben Bucksch 2007-11-05 09:56:11 MST --- Note that I am not arguing for a particular policy. Anything that makes printing work automatically when the physical problem is fixed (e.g. printer powered on, paper added etc.) is fine with me. Avoiding double prints (user hits print 3 times before he realizes that the printer is powered off) would be good, but not so critical. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c9 --- Comment #9 from Ben Bucksch 2007-11-05 10:22:20 MST --- The printer handling the fact that it's powered off? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c11 --- Comment #11 from Ben Bucksch 2007-11-05 10:55:46 MST --- I mean really power off, not standby, and that's how it *should* be. Printer price is beside the point.

BTW: don't forget "abort-job" would never remove the 10 (respective 3) other jobs from the queue.

I talking about the case: User hits print, nothing happens. Clicks print again. Checks paper, clicks print again. Realizes that he forgot to power on the printer, and turns it on. Clicks Print again. Here, the first job would probably be already aborted.

I recently print web formulars

If you're wise, you don't close the webpage until you hold the print in your hand. But I see your point. I don't argue for abort-job or any specific policy, see comment 7.

it is critical to get a printout

Yes. And this bug means that the user cannot print *at all* anymore, until the admin comes and fixes it. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c13 --- Comment #13 from Klaus Singvogel 2007-11-05 12:10:58 MST --- Regarding comment#11, comment#10, comment#9, etc., topic "Power-Off": I saw it once a few years ago and was astonished: my printer was switched off (LEDs were off, and really not in stand-by), but as soon as I transmitted the printjob the LEDs flashed on, the printer did the printhead cleaning procedure and then started printing. Yes, this surprised me too. Yes, I really switched the printer via the power button off (IRC it was the day before). Regarding comment#11, topic "web formulars": it happens every then and while that a web browser crashes. If we apply Murphy here, then it happens exactly in those situations when you print a web formular the second time, and only if in the first try the job was aborted because of paper jam. This can be explained easily, by the fact that the "repair" time took several minutes. Then data on the remote server got fetched again (because of timeout variables in the browser) and as the data usually no longer exists... Crash. Regarding comment#11, topic "admin needed": Yes, understood. But we never know which job is intended to be printed several times (even if the printer is currently not working) and which is accidently printed several times. To reduce this to a common phrase: "again, we lack of a working crystal ball here". :-) But maybe the "beh" backend is the thing which enables the printer after some time for you automatically? Still: we should not lose data, i.e. delete the print jobs. Regarding comment #12, topic "PreserveJobFiles": Yes, I know about it. Thanks. :-) But some print jobs can be very large and enabling PreserveJobFiles can consume a lot of disk space. Remember, the default value of MaxJobs variable is 500. In worst case scenarios this can be a *lot* of disk space. Users, who cannot change configuration files, are usually unable to purge (delete) succeeded jobs too. I doubt that enabling this variable is a good idea, nor helps those users. Nice idea, but is it really practicable? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c15 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spielmit@online.de --- Comment #15 from Johannes Meixner 2007-11-06 03:15:18 MST --- *** Bug 338605 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=338605 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c17 --- Comment #17 from Johannes Meixner 2007-11-06 09:08:39 MST --- Regarding comment #10 "BTW": I think "abort-job" does remove all pending jobs in the queue (i.e. it results maximum loss of data) because: Assume there are 10 jobs in the queue. Job 1 and 2 print fine. At job 3 an error condition happens which lets the backend fail so that job 3 becomes removed. Then job 4 starts but if the error condition still exists, the backend fails again so that job 4 becomes removed. And so on until all jobs are removed. This scenario makes a default ErrorPolicy "abort-job" impossible. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c19 --- Comment #19 from Silviu Marin-Caea 2007-11-27 03:38:00 MST --- It's incredible the ammount of discussion about a no brainer decision. While this academical debate proceeds, gross unusability ensues. The scenario is simple and ordinary: USB printer is turned off. CUPS puts it in stopped state and leaves it like that _forever_, no retry after it's turned on. End of story for mom, pop, Random Joe and aunt Tillie. This means plain and simple: LINUX PRINTING DOESN'T WORK FOR THEM. Do you expect these users to know about "cupsenable" and "http://localhost:631", "lppasswd"? Frankly, I haven't looked too deep into the ErrorPolicy stuff right now, but what's wrong with "retry-job"? In any case the actual default of "stop-printer" right now is obscenely WORNG. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c21 Kurt Pfeifle changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pfeifle@kde.org --- Comment #21 from Kurt Pfeifle 2007-11-27 11:41:40 MST --- In cupsd.conf: ErrorPolicy retry-job JobRetryInterval 600 JobRetryLimit 144 will retry each job every 10 minutes (600 seconds), 144 times (24 hours) before giving up. It's left to our master complainer Silviu to compute a value that makes jobs expire after 7 days instead of 24 hours. (I disagree that "ErrorPolicy retry-job" combined with expiration is "perfect" for a server. Do what you want with *your* environment, but don't tell me what's perfect for *mine*. Even what *I* pick for *mine* isn't perfect; it's always a compromise between various conflicting (!) goals...) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c23 --- Comment #23 from Silviu Marin-Caea 2007-11-28 03:33:58 MST --- Thank you. If this improves the state of affairs for a lot of people it's a complaint well spent, and I'll make one for the same benefit every single time even at the expense of my own karma. :-) The way I see it, the _Default_ has to be good enough for as many people as possible. That means it's not going to be good enough for a few, but they can change it because *they* know what's best for *them* (and *noone* wants to tell them what's perfect for them). This particular default is far from being good enough for a lot of people, it's absolutely to the contrary. Is there any opposition to this idea? I'm willing to argue it into the ground for the sake of moms, pops, Random Joes and aunt Tillies everywhere running SUSE, with their printer stuck on "stopped". So, are these good people going to get a nice cup of bugfix for that? -- 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.

From the CUPS's point of view it is a "third-party" tool. It was introduced by our "Desktop" team/department to make

https://bugzilla.novell.com/show_bug.cgi?id=337794#c25 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |silviu_marin-caea@otpbank.ro --- Comment #25 from Johannes Meixner 2007-11-29 01:15:53 MST --- I assume we see multiple different reasons here why a queue becomes disabled/stopped. In particular what is described in comment #24 (becomes disabled even if there is no active printing job) indicates that in this case it is not the CUPS backend which gives up with exit code 1 (CUPS_BACKEND_FAILED), because when there is no active printing job there is no backend running. In this case it seems another obscure magic tool disables it and then "cups-autoconfig" is suspicious because this tool is known to cause bad consequences, see bug #334166. Since openSUSE 10.3 we have the new RPM "cups-autoconfig" which contains a utility for auto-configuring USB printers which is triggered by udev/HAL device events. Note that this tool neither comes from the CUPS authors nor is the RPM a sub-package of the cups RPM. printing more convenient in particular for "Desktop" users. By default it disables/enables print queues when udev/HAL events appear that a USB printer is disconnected/connected. Its /etc/cups-autoconfig.conf contains by default: -------------------------------------------------------------- [CUPS] ConfigureNewPrinters=yes DisablePrintersOnRemoval=yes DefaultCUPSPolicy=relaxed Debug=yes -------------------------------------------------------------- It is triggered via /usr/share/hal/fdi/policy/10osvendor/10-cups-autoconfig.fdi which runs /usr/lib/cups-autoconfig/cups-autoconfig which does the actual stuff, see /usr/lib/cups-autoconfig/cups-autoconfig --help (you must run even '--help' as root, otherwise you get errors) Debugging output is in /var/log/cups-autoconfig.log Perhaps in the particular case which is described in comment #24 cups-autoconfig disables the queeu but fails to re-enable it if the printer was re-connected? If you don't like what cups-autoconfig does (i.e. if you prefer that you control the print queues and not whatever automatism), uninstall the cups-autoconfig package and reboot (or restart HAL) to make HAL aware of its changed config files, see https://bugzilla.novell.com/show_bug.cgi?id=218393#c28 For some background information, see http://code.google.com/p/cups-autoconfig/ Silviu Marin-Caea, please report, if it helpy in your particular case when cups-autoconfig is disabled or removed (to be on the safe side do a reboot after you disabled or removed cups-autoconfig). -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794#c27 --- Comment #27 from Silviu Marin-Caea 2007-11-29 02:34:20 MST --- Ah, I see now, my original bug #344220 is, in fact, a duplicate of bug #334166 that Johannes mentioned in comment #25, not a duplicate of this bug with ErrorPolicy. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=337794#c28 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #28 from Johannes Meixner 2008-08-15 00:25:42 MDT --- There is no single best default which makes all happy. For next openSUSE version there is a new yast2-printer module which lets you set the ErrorPolicy which fits best for your particular case. See http://mzugec.blogspot.com/2008/08/new-yast2-printer-configuration-module.ht... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=337794 User com.opensuse@bucksch.org added comment https://bugzilla.novell.com/show_bug.cgi?id=337794#c30 Ben Bucksch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #30 from Ben Bucksch 2008-08-15 04:48:18 MDT --- REOPEN, because the original, severe problem still exists. -- 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.