[gutsy] getting "Error Printing: Too many failed attempts" error when printing through GtkPrintOperation

Bug #145278 reported by Herbert V. Riedel on 2007-09-26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released
gtk+2.0 (Ubuntu)
Ubuntu Desktop Bugs
Nominated for Gutsy by Herbert V. Riedel
Nominated for Intrepid by Alex
Nominated for Jaunty by Alex

Bug Description

Binary package hint: cupsys

At some point of last weeks gutsy updates, printing got broken;

printing at the commandline via lp or with xpp works; when trying to print from gnome/gtk apps which use GtkPrint I get the the error dialog window "Error Printing: Too many failed attempts";

/var/log/cups/access_log just gives
 localhost - - [26/Sep/2007:18:18:44 +0200] "GET /ppd/fs1010direct.ppd HTTP/1.1" 200 10982 - -
 localhost - - [26/Sep/2007:18:18:48 +0200] "POST /printers/fs1010direct HTTP/1.1" 400 0 unknown-0000 -
 localhost - - [26/Sep/2007:18:19:03 +0200] "POST /printers/FS-1010 HTTP/1.1" 400 0 unknown-0000 -

/var/log/cups/error_log says:
E [26/Sep/2007:18:18:48 +0200] cupsdReadClient: 7 IPP Read Error!
E [26/Sep/2007:18:19:03 +0200] cupsdReadClient: 7 IPP Read Error!

I tried strace(2)ing gtk-demo's Printing example, and saw amongst others, that cupsys returned a "Bad Request"-line...:

socket(PF_FILE, SOCK_STREAM, 0) = 7
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = -1 EOPNOTSUPP (Operation not supported)
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
connect(7, {sa_family=AF_FILE, path="/var/run/cups/cups.sock"}, 26) = 0


send(7, "POST /printers/FS-1010 HTTP/1.1\r\nContent-Length: 0\r\nContent-Type: application/ipp\r\nHost: localhost\r\nUser-Agent: CUPS/1.3.2\r\n\r\n", 126, 0) = 126


send(7, "\1\1\0\2\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5en-gbB\0\24requesting-user-name\0\3hvrE\0\vprinter-uri\0\'ipp://cervus.intra:631/printers/FS-1010B\0\10job-name\0\17gtk-demo job #1\2B\0\10PageSize\0\2A4!\0\fjob-priority\0\4\0\0\0002B\0\nResolution\0\006800dpiB\0\njob-sheets\0\4noneB\0\0\0\4noneB\0\fJCLEconomode\0\3OffB\0\tMediaType\0\6PrnDefB\0\tSmoothing\0\6MediumB\0\tInputSlot\0\10Internal!\0\tnumber-up\0\4\0\0\0\1\3", 372, 0) = 372
poll([{fd=7, events=POLLIN, revents=POLLIN|POLLERR|POLLHUP}], 1, 0) = 1
poll([{fd=7, events=POLLIN, revents=POLLIN|POLLERR|POLLHUP}], 1, 10000) = 1
recv(7, "HTTP/1.1 400 Bad Request\r\nDate: Wed, 26 Sep 2007 16:00:55 GMT\r\nServer: CUPS/1.2\r\nContent-Language: en_US\r\nUpgrade: TLS/1.0,HTTP/1.1\r\nConnection: close\r\nContent-Type: text/html; charset=utf-8\r\nContent-Length: 344\r\n\r\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\">\n<HTML>\n<HEAD>\n\t<META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset=utf-8\">\n\t<TITLE>400 Bad Request</TITLE>\n\t<LINK REL=\"STYLESHEET\" TYPE=\"text/css\" HREF=\"/cups.css\">\n</HEAD>\n<BODY>\n<H1>400 Bad Request</H1>\n<P></P>\n</BODY>\n</HTML>\n", 2048, 0) = 559

Herbert V. Riedel (hvr) wrote :

some additional logs, after setting LogLevel debug2:

d [01/Oct/2007:21:46:12 +0200] cupsdDoSelect: epoll() returned 1...
d [01/Oct/2007:21:46:12 +0200] cupsdDoSelect: Read on fd 9...
d [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9, used=0, file=-1 state=0
D [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9 POST /printers/FS-1010 HTTP/1.1
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: uri = "/printers/FS-1010"...
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location CUPS_INTERNAL_BROWSE_ACL Limit 0
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location /admin/conf Limit 7f
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location /admin Limit 7f
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location / Limit 7f
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: best = /
d [01/Oct/2007:21:46:12 +0200] cupsdAuthorize: con->uri="/printers/FS-1010", con->best=0x10084388(/)
d [01/Oct/2007:21:46:12 +0200] cupsdAuthorize: Authorization=""
D [01/Oct/2007:21:46:12 +0200] cupsdAuthorize: No authentication data provided.
d [01/Oct/2007:21:46:12 +0200] cupsdIsAuthorized: con->uri="/printers/FS-1010", con->best=0x10084388(/)
d [01/Oct/2007:21:46:12 +0200] cupsdIsAuthorized: level=AUTH_ANON, type=AUTH_NONE, satisfy=AUTH_SATISFY_ALL, num_names=0
d [01/Oct/2007:21:46:12 +0200] cupsdIsAuthorized: auth=AUTH_ALLOW...
d [01/Oct/2007:21:46:12 +0200] POST /printers/FS-1010
d [01/Oct/2007:21:46:12 +0200] CONTENT_TYPE = application/ipp
d [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9 con->data_encoding=HTTP_ENCODE_LENGTH, con->data_remaining=0, con->file=-1
E [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9 IPP Read Error!
D [01/Oct/2007:21:46:12 +0200] cupsdSendError: 9 code=400 (Bad Request)
D [01/Oct/2007:21:46:12 +0200] cupsdCloseClient: 9
d [01/Oct/2007:21:46:12 +0200] cupsdRemoveSelect: fd=9
d [01/Oct/2007:21:46:12 +0200] cupsdCheckJobs: 0 active jobs, sleeping=0, reload=0
d [01/Oct/2007:21:46:12 +0200] cupsdDoSelect: polling 4 fds for 1 seconds...

Herbert V. Riedel (hvr) wrote :

while looking closer at the logging output I just noticed that for some reason the request sent by the gtk apps has a "Content-Length: 0" header, which doesn't seem to be sensible...

MIke Pestorich (mmpestorich) wrote :

I am currently running the PPC port of Gutsy and am experiencing the same problem - "Error Printing: Too many failed attempts." My error and other logs show almost exactly what those in the previous post show.

I started experiencing this problem after upgrading from Feisty to Gutsy. Noticed it first when trying to print from Evince, and then later realized I could print from other programs e.g. Firefox, OpenOffice, etc presumably because they are using a different backend for passing print jobs to cups. I have tried reinstalling everything from cups to evince with no success. I have reinstalled printers. I have verified nothing is out of the ordinary in any the cups configuration files.

I have Gutsy installed on two other x86 machines and am *not* having these problems as printing seems to work as expected on these other systems.

Till Kamppeter (till-kamppeter) wrote :

To the maintainer of Evince: Please assign this bug report to the library which provides printing functionality to Evince.

Changed in cupsys:
importance: Undecided → Medium
Matteo Settenvini (tchernobog) wrote :

I'm seeing this together with bug 66379: "Error in POST Success", and only on PPC.

hendrikwout (hendrikwout) wrote :

I'm haveing the same problem: "too many failed attempts".

Herbert V. Riedel (hvr) wrote :

well, this is a bug that seems to affect every application that uses the libgtk provided printing API... so it's not a evince bug...

Colin Leroy-Mira (colin-colino) wrote :

I have the same, trying to implement printing of PopplerPages (from libpoppler) using GtkPrintOperation on Gutsy.
Seems random.

Sebastien Bacher (seb128) wrote :

Thank you for your bug. Do you get the same issue from eog for example? Does printing to a pdf works correctly?

Changed in evince:
assignee: nobody → desktop-bugs
status: New → Incomplete
Herbert V. Riedel (hvr) wrote :

to sum it up:

printing to file (either pdf or ps) works, since it doesn't get sent via IPP

I haven't found yet(? -- see below for gedit)an application, which uses the gtk printing API and does not fail to print via cups;
applications which I have tried so far:


except for gedit, which seems to be able to print; but I'm not sure which printing API it uses, since the printing dialogs looks/feels different from the applications listed above; maybe it uses the gnome printing API?

I think this bug should be on gtk+ (GtkPrintOperation) rather than evince, or maybe libpoppler...

hendrikwout (hendrikwout) wrote :

I can confirm this: eog also doesn't print. Gedit does.

Sebastien Bacher (seb128) wrote :

reassigning to gtk+2.0

Sebastien Bacher (seb128) wrote :
Changed in gtk+2.0:
status: Incomplete → Triaged
Changed in gtk:
status: Unknown → New
Herbert V. Riedel (hvr) wrote :

well, the bug became too annoying to me, and I finally got around to hunt it down to a simple integer-64/32bit-truncation bug...

sprintf was using "%lu" (on powerpc sizeof(long)==4) on a 64bit integer, which on little endian has the simple semantic of taking the lower 32bit word, but on big-endian powerpc it takes the upper 32bits of the 64bit datum, which is going to result in a 0 length for the usual print requests...

...can we get this fix in gutsy plz? :)

Herbert: for me it happens on x86...

Herbert V. Riedel (hvr) wrote :

colin: then maybe you're experiencing a different bug leading to the error message? have you tried enabling debugging log output in cups?

Sebastien Bacher (seb128) wrote :

Herbert, thanks for your work on that. Are all the people getting this issue using powerpc?

hendrikwout (hendrikwout) wrote :

I have powerpc and this bug is happens to me also.

David Erosa (erosa) wrote :

Just tried to print today and found the same bug, also on powerpc (iBook G4).

Philippe Leroux (phler2) wrote :

same here, after upgrade do gusty on ibookg4

a hint for people trying to print pdf via evince
use cups directly, until bug is solved
in a commandline
lp filename.pdf
 works fine

John Billings (jnbillings) wrote :

Same error on powerpc (Powerbook G4) when I try to print from evince. However, I can print by using lpr directly.

Dragan Stojkovic (zmajch) wrote :

Same error on my PowerMac (PPC G4 Dual).
Weird...: when i try to print a PDF from the commandline, the printer prints ... but unfortunately the font shows just lines "||II|||| |II||III" and no letters.
But I guess this is an other problem ;-)

joenix (woutersj) wrote :

I had the same problem on PowerPC and can confirm that Herbert V. Riedel's patch fixes it.

Thanks Herbert!

joenix (woutersj) wrote :

Since the gtk recompile can take quite a while, I put the libgtk package with Herbert's patch online:

Use at your own risk! :)

Sebastien Bacher (seb128) wrote :

The bug should be fixed in the hardy version now

Changed in gtk+2.0:
status: Triaged → Fix Released
Changed in gtk:
status: New → Fix Released

Could this fix be released for Gutsy please?

Flabdablet (flabdablet) wrote :

My filthy workaround for this issue:

cd /tmp
wget http://archive.ubuntu.com/ubuntu/pool/main/g/gtk+2.0/libgtk2.0-0_2.10.11-0ubuntu3_powerpc.deb
dpkg -x libgtk2.0-0_2.10.11-0ubuntu3_powerpc.deb foo
cd /usr/lib/gtk-2.0/2.10.0/printbackends
sudo mv libprintbackend-cups.so libprintbackend-cups.so.broken
sudo cp /tmp/foo/usr/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.so .

This replaces the faulty library with the version from Feisty, which apparently doesn't suffer from this bug, while leaving the package manager none the wiser. Hopefully the next upgrade will fix this rather than breaking it again.

Sebastien Bacher (seb128) wrote :

did you try on hardy if that's working correctly?

another_sam (anothersam) wrote :

also happens for me in intrepid. with evince 2.24.

ubuntu 8.10 x86
dell inspiron 9400
hp deskjet f4180

For this case, I printed a PDF once successfully (technically speaking) but I realized print margins were wrong. Then I changed them from Printer Properties > Job Options. Then I tried to print the PDF again and the message appeared: "Too many failed attempts".

Erich Pawlik (erichpawlik) wrote :

The fix doesn't work in an up to date Intrepid installation.

Ubuntu 8.10 x86, current as of November 26
Dell Vostro 1510
remote printers on a Samba server (Laserjet 4L, Magicolor 2400W)

Didn't print with Evolution 2.24.1 (message: Too many failed attempts) and Evince 2.24.1 (message: cannot prompt for authorization).

Printing to PDF is possible, also printing from Open Office.


Erich Pawlik

850001 (jacekfoo) wrote :

The same with me - I cant print from any gnome app (gedit, evolution, evince) but can print from KDE apps (Okular).

Printers are on samba servers.

Messages I get are either "Too many failed attempts" or " cannot prompt for authorization".

Alex (zk118243) wrote :

I can confirm this as well in a up to date Intrepid install. Printing works from Open Office but not gedit.

samuel, Erich Pawlik, 850001, AlexBuck,
The bug described above only affected ppc architecture and has been fixed and is closed.
If you are on x86 you are experiencing a different problem!
Please open a new bug report and provide the information described here: https://wiki.ubuntu.com/DebuggingPrintingProblems, including your cups error_log and the output of the printingbug info script.

Arie Skliarouk (skliarie) wrote :

samuel, Erich Pawlik, 850001, AlexBuck,
I have submitted a bug report on the new issue here:

Feel free to contribute to it.

Changed in gtk:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.