GNOME Bugzilla – Bug 591846
"Too many failed attempts" makes printing impossible
Last modified: 2012-01-06 16:07:10 UTC
Please describe the problem: Different anecdotal accounts can be found all over the internet. I can't figure out what causes it to start, but after printing a few times from a Gnome app, it starts to fail with a "Too many failed attempts" error dialog. Printing from a non-Gnome application works fine. This is quite serious, because it renders printing from Gnome apps completely impossible. I can't figure out how to clear the error, I've already tried restarting CUPS and restarting the application and even re-connecting the printer. No luck. Steps to reproduce: 1. Try to print 2. Try to print 3. Try to print Actual results: "Too many failed attempts" error dialog appears after awhile. Expected results: Does this happen every time? Once the error starts to appear, it's almost impossible to get rid of. Other information:
Other info: I use Ubuntu 9.04 at the moment, but I've read the same complaint from Mandriva and openSUSE users.
I am using ubuntu 9.04 and this is a big problem for my install (150+ machines). I think this is connected to http://bugzilla.gnome.org/show_bug.cgi?id=384940 At least I have everything updated, and still when the printer has AuthRequired username,password nothing happens. I need to print to a windows shared printer using username and password, and when AuthRequired is none, I get the authentication dialog, and am able to print. But since cups (i think) changes the AuthRequired setting to username,password (which is correct in this case), I can not print again, unless I change the setting back to none and restart cups. Hope this helps and is related to this bug.
Hmm, I apologise for possibly chosing the wrong bug, I mean I simply cannot decide whether this is the same. At least it is _not_ authentication problem as linked bugs suggest. Occasionally I get "Too many failed attempts", which CUPS registers only: cupsdReadClient: 16 IPP Read Error! (or 11 instead of 16, possibly just the printer or socket number, I haven't checked) Someone made a funny comment in https://bugs.launchpad.net/ubuntu/+source/cups/+bug/359975 about related to losing focus, so I tried. Indeed, what I observed, is that if it doesn't have the focus, and the document is huge (like a large PDF drawing printed by evince) it almost always fail. If I give it focus, it fails similarly. However if I bomb the poor bastard with X events, like constantly moving the mouse in the focused window it seem never to fail. Educated guess: Feels like some timing problem around the cups library?
And others confirmed that moving the mouse while focusing evince works 100% of the time. Don't laugh.
I can confirm peter gervai's fix. What a crazy bug! Never seen anything like it. Test Process: 1. Find a big, complex PDF file. I went to http://news.google.com and printed off the whole thing to a 5 page PDF file, about 1.5 MB in size. 2. Open the PDF with Evince, click print, and then let your mouse rest in the taskbar or window manager bar. 3. Enjoy the "Too many failed attempts" message after a few seconds. 4. Wash, rinse, repeat. It will fail. 5. Now try again, click print on the same document in Evince, but this time start peddling. In an effort to eliminate the worldwide obesity problem, it is necessary to work hard for your PDF document! Start moving your mouse in circles around the screen of Evince while it spools the document. It will succeed. 6. Enjoy your printer.
I would like to propose a quick and dirty fix for this until the real problem can be solved. I am no developer, but it appears to be as simple as finding the function that is the equivalent of "bool CheckForTooManyFailedAttempts()" and hack it to always return false. Whatever code is checking for some sort of failed attempts is bogus and does no good. Even if there was some sort of legitimate failed attempts condition, the user doesn't need a stupid dialog box to tell him that his document failed to print. Just blindly try to print no matter what. Can this be done? Additionally, can we please mark this bug as confirmed? Thanks!
Some suggested GUI bugs (gtk?), could some knowledgeable person have a quick look and reassign to the proper component, if required? This doesn't seem to be worked on, right?
This is fixed by commit 3b336186ee4d55799f4290c672d6bccd787c70fa
(In reply to comment #8) > This is fixed by commit 3b336186ee4d55799f4290c672d6bccd787c70fa Closing as per last comment.