delay on printing dialog in evince

Bug #475845 reported by David Tombs on 2009-11-05
This bug affects 37 people
Affects Status Importance Assigned to Milestone
gtk+2.0 (Ubuntu)
Ubuntu Desktop Bugs
Nominated for Lucid by btmorex

Bug Description

Binary package hint: evince

When I open the printing dialog in Evince, there is a ~10s delay after the dialog opens while it says "Getting printer information..." during which the whole Evince UI is unresponsive.

Steps to reproduce:
1) Open a PDF in Evince.
2) File -> Print...
3) 10% of the time, print dialog opens and is responsive as expected. 90% of the time...
4) Print dialog freezes for ~10s during while it says "Getting printer information..." in the status column. (Sometimes it freezes a bit earlier, after the dialog appears but before it paints its controls.)
5) After delay, printing works as expected.

I have one Canon MP160 printer.

Please let me know if I can provide any more information.

ProblemType: Bug
Architecture: amd64
Date: Thu Nov 5 15:58:46 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/evince
NonfreeKernelModules: nvidia
Package: evince 2.28.1-0ubuntu1
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: evince
Uname: Linux 2.6.31-14-generic x86_64

David Tombs (dgtombs) wrote :
David Tombs (dgtombs) wrote :

Actually, I just realized I can reproduce in Firefox, but it doesn't seem to occur as often. Don't know what package this should be assigned to now.

smaj (stefanmajewski) wrote :

I see the same with the print dialog mainly in firefox and evince. It is somewhat annoying. I noticed that while the print dialog hangs for a while, some of the tabs are not yet present in the print dialog. I see "General", "Page Setup" and "Options" right from the beginning when the dialog shows up. Tabs like "Job", "Image Quality" or "Advanced" are shown only after the dialog becomes responsive again.

I see it on x86-32 intel
could be a cups issue?

Linda (linda-broeen) wrote :

Count for me as well. Print dialogues for ff and evince look similar. In contrast the oo print dialogue is different and doesn't show this kind of delay.

Pedro Villavicencio (pedro) wrote :

Could be that the delay is happening on cups, could you please read : and attach that information to the report, after reproduced the issue? Thanks in advance!.

Changed in evince (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
status: New → Incomplete

Architecture: amd64
DistroRelease: Ubuntu 9.10
Lpstat: device for mp160: usb://Canon/MP160
NonfreeKernelModules: nvidia
Package: cups 1.4.1-5ubuntu2.1
PackageArchitecture: amd64
Papersize: letter
PpdFiles: mp160: Canon PIXMA MP160 - CUPS+Gutenprint v5.2.4
ProcCmdLine: root=UUID=cb832714-a26f-4f20-a85f-de2b92164bcb ro splash
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
Uname: Linux 2.6.31-16-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare 02/18/2008
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FGa M57SLI-S4
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFGa:bd02/18/2008:svn:pn:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM57SLI-S4:rvrx.x:cvn:ct3:cvr:

Changed in evince (Ubuntu):
status: Incomplete → New
tags: added: apport-collected
David Tombs (dgtombs) wrote :

OK, apport-collected as requested. Here's the snippet from CupsErrorLog.txt for when the error occurs:

D [14/Dec/2009:00:35:07 -0500] cupsdAcceptClient: 12 from localhost (Domain)
D [14/Dec/2009:00:35:07 -0500] cupsdReadClient: 14 WAITING Closing on EOF
D [14/Dec/2009:00:35:07 -0500] cupsdCloseClient: 14
D [14/Dec/2009:00:35:07 -0500] cupsdAcceptClient: 14 from localhost (Domain)
D [14/Dec/2009:00:35:07 -0500] cupsdReadClient: 12 GET /printers/mp160.ppd HTTP/1.1
D [14/Dec/2009:00:35:07 -0500] cupsdSetBusyState: Active clients
D [14/Dec/2009:00:35:07 -0500] cupsdAuthorize: No authentication data provided.
D [14/Dec/2009:00:35:07 -0500] cupsdAcceptClient: 16 from localhost (Domain)
D [14/Dec/2009:00:35:07 -0500] cupsdReadClient: 14 WAITING Closing on EOF
D [14/Dec/2009:00:35:07 -0500] cupsdCloseClient: 14
D [14/Dec/2009:00:35:07 -0500] cupsdReadClient: 16 POST / HTTP/1.1
D [14/Dec/2009:00:35:07 -0500] cupsdAuthorize: No authentication data provided.
E [14/Dec/2009:00:35:17 -0500] cupsdReadClient: 16 IPP Read Error!
D [14/Dec/2009:00:35:17 -0500] cupsdCloseClient: 16
D [14/Dec/2009:00:35:17 -0500] cupsdSetBusyState: Not busy
D [14/Dec/2009:00:35:18 -0500] cupsdReadClient: 12 WAITING Closing on EOF
D [14/Dec/2009:00:35:18 -0500] cupsdCloseClient: 12
D [14/Dec/2009:00:35:18 -0500] cupsdAcceptClient: 12 from localhost (Domain)
D [14/Dec/2009:00:35:18 -0500] cupsdAcceptClient: 14 from localhost (Domain)
D [14/Dec/2009:00:35:18 -0500] cupsdReadClient: 12 WAITING Closing on EOF
D [14/Dec/2009:00:35:18 -0500] cupsdCloseClient: 12

As you can see, exactly a 10s delay. Some kind of timeout problem.

Changed in evince (Ubuntu):
importance: Undecided → Low
Tony Whelan (tony-whelan) wrote :

Since upgrading to Karmic I get this same problem using Firefox, Evince, gEdit, glabels, gimp
Using 9.10 64bit version on AMD machine and printing to a Lexmark E260d laser via a DLINK print server.
All worked fine before the upgrade to Karmic I think, though can't be sure that's when it started.

So it seems not to be an evince issue, more like something in CUPS?

After some time spent on testing it seems the problem is related to CUPS / printer driver or GTK print dialogue.

The problem appears if the _default_ printer is using some of HP drivers. I succeed to "almost" solve the problem by changing the driver for my HPLJ 3800DN printer from "HP Color LaserJet 3800 Postscript (recommended)" to "HP Color LaserJet 3800 Foomatic/Postscript". I write almost, because instead of reproducing the problem in 90% I get it in 10% of cases.

Examples of drives which in most of cases don't work:
HP Color LaserJet 3800 Postscript (recommended)
HP LaserJet 4250 Postscript (recommended)
HP LaserJet 4050 Series Postscript (recommended)

and the drives which in most of cases works as supposed:
HP Color LaserJet 3800 Foomatic/Postscript
Ricoh Aficio MP 5000 - CUPS+Gutenprint v5.2.4
HP LaserJet 1160 hpijs, 3.9.8

The other observations:
- when the print dialogue freezes, only the tabs "General", "Page setup", "Text Editor" are displayed; the other tabs are shown when the window gets unlocked,
- for network printers: during the freeze, when the message "Getting printer information..." is displayed, there's no network activity, so it is not about checking the status of the printer. Checked with wireshark on all interfaces (including lo),
- the problem is independent of device URI; I tested: socket://10.x.x.x:9100, lpd://10.x.x.x/PASSTHRU, hp:/net/HP_Color_LaserJet_3800?ip=10.x.x.x and serial:/dev/ttyS0?baud=115200,
- log messages in /var/log/cups on timeout:
  - access_log: "POST / HTTP/1.1" 400 0 unknown-0000 -
  - error_log: cupsdReadClient: 15 IPP Read Error!

Tested on 64-bit architecture.

IKnowNothing (mikeythek) wrote :

Same problem here, Karmic, HP LaserJet 9000N

Linda (linda-broeen) wrote :

Hmmm, we use a Konica Minolta Bizhub

David Tombs (dgtombs) wrote :

Notice that I have a Canon PIXMA MP160, not an HP printer.

Also, I find that the dialog will freeze at different states of completion, not just with the specific tabs that Wojtek mentioned above. For example, sometimes none of the dialog painted, it was just a gray rectangle.

erim (posterim) wrote :

Same problem. Karmic, HP Laserjet 4350 over network connection

szyndelp (paddy) wrote :

Same problem with eye of gnome and firefox

Thanks to Marek Kasik from Red Hat, this bug has been confirmed and may be later fixed in GTK+ (printer dialog).

For now you may disable cups to listen on "/var/run/cups/cups.sock" by commenting the line including it in cupsd.conf and leave only "Listen localhost:631" line.

affects: evince (Ubuntu) → gtk+2.0 (Ubuntu)
Changed in gtk+2.0 (Ubuntu):
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

do you have any reference to the redhat bug?

Not yet, I'm waiting for further analyse by Marek.

Well, not exactly. Our bug has been probably caused by this patch.

Marek Kasik proposed another solution, which is: "to revert commit named 'Speed up printer listing in the
print dialog' in gtk (SHA1 ID: dd52987d1fe3c3481fffc5b776fcac6b02114b01). Those timeouts are too short
for the socket probably. This workaround helps if it is not related to the socket (e.g. remote print server)."

He will have a look at this code perhaps this week, but it doesn't mean that we'll get the updates very soon. The solution provided by Marek above ( works fine for me.

pklaus (pklaus) wrote :

Wojtek Kazimierczak's workaround [1] is working great! Thx for the tip!


Tony Whelan (tony-whelan) wrote :

Thank you. The workaround provided above ( works fine for me also.

rennradler (bernhard67) wrote :

I have this problem here with a Kyocera FS-C5100DN which is connected to my LAN. It is still there in 10.04 Beta1.

BTW - the bug only shows up on my 64bit installation. The 32bit installation of my other machine works.

I had the same issue with a network-attached HP 3052 MFP. Disabling the Listen on the cups.sock worked for me.

Uhm, when I do the workaround I loose all printers? If I go to Administration > Printers I can see them all but when I try to print from something I have no printers.

I changed this in cupsd.conf:

#Listen /var/run/cups/cups.sock


Listen localhost:631

Nothing in error_log and cupsd starts but no printers. How do I change the system from trying to use the socket to instead use localhost:631?

FM (frederic-meynadier) wrote :

To ThomasNovin : same here, I lost all my printers when commenting out the "Listen /var/run/cups/cups.sock" line (leaving the "Listen localhost:631" line uncommented). All my printers are network ones, and among them 2 HPs. It seems that the proposed workaround is incomplete in our case.

@FM: I tried the workaround on two other computers. Worked on both of them.

On the computer that it didn't work I had one big difference, IPv6 was disabled, both with sysctl settings and also in /etc/hosts. After re-enabling it works again. ( wrote :

this seams to works fine:

sudo sed -i 's|Listen /var/run/cups/cups.sock|#Listen /var/run/cups/cups.sock|g' /etc/cups/cupsd.conf

Victor Jimenez (betabandido) wrote :


I also lose all the printers when I try the workaround given in comment #29.

I do not have any experience with IPv6, but I checked the output from sysctl -A and looked into /etc/hosts. It seems as if IPv6 is not disabled in my system, as there are these 3 lines:

net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

and /etc/hosts contains references to IPv6:

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

However, I am not sure if that means that IPv6 is enabled.

If IPv6 is enabled, then there is indeed something else preventing workaround #29 to work properly.


Jon Black (juan-black) wrote :

I also get this problem with a HP PSC 750 printer. The fix in comment 29 doesn't work either.

For me the following worked: echo "ServerName" > /etc/cups/client.conf

Martin Holmes (mholmes) wrote :

I'm still seeing this problem in Lucid 64-bit with a networked HP Color LaserJet CP3525. All activity seems to have stopped on this bug -- why is that, when it's not fixed, and it has a marked impact on basic user experience?


EricPedersen (pedersen-e) wrote :

I lost all my printers trying the fix in comment 29. Comment 44 didn't have any effect.

Though I only restarted cups with: "sudo /etc/init.d/cups restart"

rduke15 (rduke15) wrote :

I also lost all printers in Firefox after applying the fix in comment #29. Did several things, and the printers re-appeared:

- commented-out the ipv6 lines in /etc/hosts
- added the printer IP and name to /etc/hosts
- restarted Firefox

Possibly, all that was needed after restarting cups was to also restart Firefox (from which I had printed and experienced the delay right before looking for a fix).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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