Bug 1171418 - Bad default error policy causes printing issues
Summary: Bad default error policy causes printing issues
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-printer
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-06 18:23 UTC by Valent Turkovic
Modified: 2018-10-23 15:04 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 12:29:17 UTC
Type: Bug


Attachments (Terms of Use)

Description Valent Turkovic 2014-12-06 18:23:25 UTC
Description of problem:
Default error policy for printers in Fedora is "Stop printer" which is a really bad default. I have run across this issue LOTS of times with regular Linux users who don't get why has their printer stopped working, there is no UI queue to warn users, there is no easy way to "Start printer" with one click, yust a big mess.

Even worse, previous versions of Gnome control panel had option to change default error policy, now that is removed and you can get to it only by installing system-config-printers tool, something regular users have no idea about even exists, and it is not installed by default.

There are too many examples which are simple user errors but result in priner going offline (stopped) and this is really bad, because after that they can't print any more.

For example: used trying to print while he/she is not at home so his printer is not available, user tyring to print but not connecting usb cable from the printer, user printing to wifi printer but haven't turned it on, user printing to wifi printer but connected to different wifi network...

Any of these actions disables printing (Stops printer) and users can't print even when they resolve issue that was stopping them from accessing the printer. 

Now Fedora is what is stopping them from printing.

Who is responsible for user experience of Fedora desktop? To whom should I point this issue to?

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Tim Waugh 2014-12-08 15:09:45 UTC
(In reply to Valent Turkovic from comment #0)
> Description of problem:
> Default error policy for printers in Fedora is "Stop printer" which is a
> really bad default. I have run across this issue LOTS of times with regular
> Linux users who don't get why has their printer stopped working, there is no
> UI queue to warn users, there is no easy way to "Start printer" with one
> click, yust a big mess.

So, this default comes from upstream CUPS (we don't change it in Fedora), and whether or not it's a good default depends on exactly what it means.

The "error" policy defines the behaviour when a job fails. A job will generally not just fail randomly, or without there being some action that needs to be taken.

If a job fails, there is generally something up with that queue. Either the configuration is wrong, or the hardware needs some attention, or something of that nature. In that case, retrying the job will just waste power as it will most likely fail again.

Here is how to re-enable a stopped printer in GNOME:
Settings -> Printers -> select the printer, click "On"

Let's examine some of the cases you cited:

(In reply to Valent Turkovic from comment #0)
> user tyring to print but not connecting usb cable from the
> printer,

The safeguard against this situation is provided by system-config-printer-udev: when the device is disconnected, the queue is disabled. When it is reconnected, it is re-enabled. Is that not working for you?

> user printing to wifi printer but haven't turned it on, user
> printing to wifi printer but connected to different wifi network...

The network backends sit retrying until they can connect to the device. Is that failing in some way?

> used trying to print while he/she is not at home so his printer
> is not available,

This one could be any of the above cases.

> Any of these actions disables printing (Stops printer) and users can't print
> even when they resolve issue that was stopping them from accessing the
> printer. 

The procedure for re-enabling a queue isn't hard, but perhaps the notifications could provide a short-cut. Marek?

Comment 3 Marek Kašík 2014-12-08 15:53:28 UTC
(In reply to Tim Waugh from comment #2)
> (In reply to Valent Turkovic from comment #0)
> > Any of these actions disables printing (Stops printer) and users can't print
> > even when they resolve issue that was stopping them from accessing the
> > printer. 
> 
> The procedure for re-enabling a queue isn't hard, but perhaps the
> notifications could provide a short-cut. Marek?

I'll look whether I can add some action to the notification about stopped job so that user can open the Printers panel of gnome-control-center directly.

Comment 4 Marek Kašík 2014-12-09 17:05:38 UTC
I've proposed a patch which adds the action "Print Settings" to the notification about stopped job. It is here https://bugzilla.gnome.org/show_bug.cgi?id=741301. It will need to go through review process yet.

Comment 5 Valent Turkovic 2014-12-15 08:57:55 UTC
I have seen different use cases I mentioned with different people, and can't easily reproduce them, but one I have at home I can reproduce.

I'm just not seeing any issue with printer, just that "randomly" my wifi printer stops working. I then go to printer settings, switch it from off to on and everything works. I have no issues that I can detect (there is paper in the tray, inks are not empty...) but still printer just goes off and that is it.

Once I enable it back on and repeat print job with same setting it prints ok.

I have seen this on few different workstations with different printers.

I understand your position and if there is some issue with printer then repeating this task is meaningless. But IRL printers work strangely.

If would be nice to give regular uses power to enable printer once it goes offline. I have admin level account and still need to "unlock" printer panel in order to turn it on or off :(

Comment 6 Valent Turkovic 2015-08-31 16:47:19 UTC
Hi dear Fedora developers, I'm again being really frustrated by this default policy on Fedora 22. Still nothing changed.

I swear Windows 95 had better printing usability than latest Fedora. Will this agony ever end? :)

Comment 7 Chris Murphy 2015-08-31 18:06:25 UTC
Just as point of comparison, on OS X there is no lock for Printers & Scanners systems preferences panel. So regular users can add, delete, modify a printer whether local or network. And OS X of course uses CUPS also. If a job fails, I think it depends on the failure whether that job is put on hold and the queue remains working for other jobs, or if the whole queue is put on hold - possibly if the printer has reported to the backend that there's a problem that requires physical interaction with the printer (reset or media issue).

Anyway, there really isn't enough information to do an autopsy on this particular example. So I'm unconvinced the CUPS upstream default to stop the printer queue is incorrect. But making it easier (as in possible) for non-admins to add/delete/modify (including disable and enable print queues, and start and stop jobs) seems self-evident.

Comment 8 Tim Waugh 2015-09-01 11:36:04 UTC
(In reply to Chris Murphy from comment #7)
> Just as point of comparison, on OS X there is no lock for Printers &
> Scanners systems preferences panel. So regular users can add, delete, modify
> a printer whether local or network.

https://fedoraproject.org/wiki/Printing/ConfigurationTool#polkit_configuration

For cups-pk-helper configuration changes see bug #596711 for history and rationale.

> And OS X of course uses CUPS also. If a
> job fails, I think it depends on the failure whether that job is put on hold
> and the queue remains working for other jobs, or if the whole queue is put
> on hold - possibly if the printer has reported to the backend that there's a
> problem that requires physical interaction with the printer (reset or media
> issue).

That's right, and I'd like to make a clarification: the default policy being talked about is the default *upstream* policy. We don't change it in Fedora.

Comment 9 Fedora Admin XMLRPC Client 2016-06-24 10:41:19 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Fedora End Of Life 2016-07-19 12:29:17 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.