print dialog hangs when connected to wireless network

Bug #223776 reported by dakshay@gmail.com
This bug report is a duplicate of:  Bug #156647: Evince hangs on showing print dialog. Edit Remove
16
Affects Status Importance Assigned to Milestone
Gnome Print
Incomplete
Undecided
Unassigned
gnome-print (Ubuntu)
Incomplete
Undecided
Unassigned
network-manager (Ubuntu)
Invalid
Undecided
Unassigned
ubuntu-meta (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: ubuntu-desktop

Print dialog hangs for a very long time before showing the available printers. This happens every time I am connected to a wireless network. This problem does *not* happen when I am connected to a wired network.

I have two remote CUPS printers and one samba printer configured. Enabling or disabling the printers does not change the behavior of the print dialog or solve the problem.

This applies to any application e.g. firefox, evince, gedit etc.

Revision history for this message
fragro (frank-grossmann) wrote :

Same here!

This Bug is maybe a duplicate of this or vice versa:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/156647

Revision history for this message
dakshay@gmail.com (dakshay-deactivatedaccount) wrote : Re: [Bug 223776] Re: print dialog hangs when connected to wireless network
  • unnamed Edit (1.2 KiB, text/html; charset=ISO-8859-1)

Is anybody ever going to look at the bug? I think Ubuntu is slowly loosing
its edge and moving towards a bloated buggy system, where most user visible
bugs are low priority. Can't believe I am on an LTS.

On Wed, May 14, 2008 at 6:32 AM, fragro <email address hidden> wrote:

> Same here!
>
> This Bug is maybe a duplicate of this or vice versa:
> https://bugs.launchpad.net/ubuntu/+source/evince/+bug/156647
>
> --
> print dialog hangs when connected to wireless network
> https://bugs.launchpad.net/bugs/223776
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
_____________________________________
Akshay Dua
Student, Department of Computer Science
Portland State University

Revision history for this message
fragro (frank-grossmann) wrote :

Yes Gtk print dialog is essential for working with gnome... all prints (firefox, evince, gnome) are hanging up. I have several important things to print! This is really a "no-go"!!!

Revision history for this message
fragro (frank-grossmann) wrote :

After downgrading to Gutsy and reupdating to Hardy this Bug no longer happens for me! (config files in home are in a seperated partition and was not deleted)

Revision history for this message
Darryl Rees (dardie) wrote :

Same problem here, caused by having a remote (ipp) printer defined, and the name of the host on which the queue is defined is unresolvable. It is not the default queue -- in this case one printer defined on a server at home, the hostname of which is normally discovered by zeroconf. If that server is down or I am at another location, the print dialog takes approx. 1 minute to appear.

I think the name resolution call happens in gtk_printer_request_details (from a quick poke around with gdb). Needs to be made an asynchronous operation which doesn't hold up opening the print dialog.

Workaround. Check what servers your remote printers are on, and make sure the host's name (as shown in the print setup dailog) is define in /etc/hosts. If the same problem I am describing, your print dialog should become responsive again as soon as you make the change.

Revision history for this message
bj mccormick (bjmccormick) wrote :

I'm also started having the printer dialog hang. It sounds like what is going on in this bug report although I'm not sure it has to do with the wireless. I can only use a wireless connection though, so I can't really test. The only thing I could think of that I changed was changing my wireless driver from ndiswrapper to madwifi.

Revision history for this message
Anton Mellit (mellit) wrote :

I had similar symptoms - the print dialog hanged in every gtk program. Then I noticed I could not ping localhost! So in fact by some reason when my laptop woke up from sleep the 'lo' interface was not active. Issuing a command 'ifconfig lo up' fixed it immediately.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

This is an issue of automatic network configuration, not of the printing dialog.

Changed in gnome-print:
status: New → Invalid
status: New → Invalid
Changed in ubuntu-meta:
status: New → Invalid
Revision history for this message
bj mccormick (bjmccormick) wrote :

@ Anton, that fixed my problem! You rock.

Revision history for this message
Darryl Rees (dardie) wrote :

@Till
As mentioned the gnome printing dialog also hangs if the name of one of the printer's hosts is unresolvable. In any case it shouldn't hang even if localhost doesn't come up for some reason - in that case it should present some sane warning message to help users locate the problem at the very least, rather than presenting a blank window for > 1 minute.

By all means if a printer is uncontactable for whatever reason (including faulty name resolution), the printer should show in the dialog as uncontactable; but it shouldn't make the dialog unusable.

Steps to reproduce:
1) Define a hostname statically in /etc/hosts
2) Define a printer on that hostname
3) Remove the hostname from /etc/hosts

On my system the empty print dialog window appears (contents undrawn) for approx 70 seconds, before being drawn. During this time the code does several calls to
SYS_write(20, "RESOLVE-HOSTNAME-IPV4 the.unresolvable.hostname"..., 33) = 33
SYS_read(20,
occur and timeout after 5-10 secs.
Once the print dialog has appeared, selecting an unresolvable printer will cause the dialog to hang up again for another 70 seconds.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

You are right, re-opening Gnome-Print tasks.

Changed in gnome-print:
status: Invalid → New
status: Invalid → New
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Darryl Rees, can you do the following test:

1) Define a hostname statically in /etc/hosts
2) Define a printer on that hostname
3) Remove the hostname from /etc/hosts

4) Run "cupsctl LogLevel=debug"
5) Run "lpstat -p", "lpstat -v", "lpoptions -p <printer> -l", ...

If one of the CUPS commands hangs (needs very long time to answer), attach the /var/log/cups/error_log to this bug report.

This is to check whether the problem comes from CUPS or from GNOME/GTK.

Changed in gnome-print:
status: New → Incomplete
status: New → Incomplete
Revision history for this message
Darryl Rees (dardie) wrote :
Download full text (9.6 KiB)

Thanks Till for your prompt response! I'm sorry I don't know appropriate ettiquette for inline/attachments here - I have inlined a heap of output: (1) debug output from cups as requested (2) debug output from cups during the print-dialog hang (3) gdb stacktrace of gedit during a print-dialog hang. Hope its ok.

lpstat -p", "lpstat -v" are always fast.

lpoptions -p <printer-unresolved-hostname> -l
Takes about 5 seconds on an IPP printer (with unresolved hostname).
However it returns instantaneously on an SMB printer (with unresolved hostname).

IPP Printer:
$ time lpoptions -p Laserjet-1300 -l
lpoptions: Unable to get PPD file for LaserJet-1300: Not Found
real 0m5.024s
user 0m0.012s
sys 0m0.000s

And accompanying cups/error_log:
D [16/Sep/2008:14:33:22 +0700] cupsdAcceptClient: 8 from localhost (Domain)
D [16/Sep/2008:14:33:22 +0700] cupsdReadClient: 8 POST / HTTP/1.1
D [16/Sep/2008:14:33:22 +0700] cupsdAuthorize: No authentication data provided.
D [16/Sep/2008:14:33:22 +0700] CUPS-Get-Printers
D [16/Sep/2008:14:33:22 +0700] cupsdProcessIPPRequest: 8 status_code=0 (successful-ok)
D [16/Sep/2008:14:33:22 +0700] cupsdReadClient: 8 POST / HTTP/1.1
D [16/Sep/2008:14:33:22 +0700] cupsdAuthorize: No authentication data provided.
D [16/Sep/2008:14:33:22 +0700] CUPS-Get-Classes
D [16/Sep/2008:14:33:22 +0700] cupsdProcessIPPRequest: 8 status_code=0 (successful-ok)
D [16/Sep/2008:14:33:22 +0700] cupsdReadClient: 8 POST / HTTP/1.1
D [16/Sep/2008:14:33:22 +0700] cupsdAuthorize: No authentication data provided.
D [16/Sep/2008:14:33:22 +0700] CUPS-Get-Default
D [16/Sep/2008:14:33:22 +0700] cupsdProcessIPPRequest: 8 status_code=0 (successful-ok)
D [16/Sep/2008:14:33:22 +0700] cupsdCloseClient: 8
D [16/Sep/2008:14:33:22 +0700] cupsdAcceptClient: 8 from localhost (Domain)
D [16/Sep/2008:14:33:22 +0700] cupsdReadClient: 8 POST / HTTP/1.1
D [16/Sep/2008:14:33:22 +0700] cupsdAuthorize: No authentication data provided.
D [16/Sep/2008:14:33:22 +0700] Get-Printer-Attributes ipp://localhost/printers/LaserJet-1300
D [16/Sep/2008:14:33:22 +0700] cupsdProcessIPPRequest: 8 status_code=0 (successful-ok)
D [16/Sep/2008:14:33:27 +0700] cupsdAcceptClient: 10 from localhost:631 (IPv4)
D [16/Sep/2008:14:33:27 +0700] cupsdReadClient: 10 GET /printers/LaserJet-1300.ppd HTTP/1.1
D [16/Sep/2008:14:33:27 +0700] cupsdAuthorize: No authentication data provided.
D [16/Sep/2008:14:33:27 +0700] cupsdSendError: 10 code=404 (Not Found)
D [16/Sep/2008:14:33:27 +0700] cupsdCloseClient: 10
D [16/Sep/2008:14:33:27 +0700] cupsdCloseClient: 8

When the hostname is added to /etc/hosts I get the same error message on the IPP queue, but it returns instantaneously.
time lpoptions -p Laserjet-1300 -l
lpoptions: Unable to get PPD file for LaserJet-1300: Not Found
real 0m0.023s
user 0m0.008s
sys 0m0.004s

D [16/Sep/2008:14:41:37 +0700] cupsdAcceptClient: 8 from localhost (Domain)
D [16/Sep/2008:14:41:37 +0700] cupsdReadClient: 8 POST / HTTP/1.1
D [16/Sep/2008:14:41:37 +0700] cupsdAuthorize: No authentication data provided.
D [16/Sep/2008:14:41:37 +0700] CUPS-Get-Printers
D [16/Sep/2008:14:41:37 +0700] cupsdProcessIPPRequest: 8 status_code=0 (successful-ok)
D [16/Sep/2008:14:41:37 +0700] cupsdReadClie...

Read more...

Revision history for this message
legodude (legodude) wrote :

I have the exact same problems. Removing the unresolvable ipp printer restored printing performance back to normal. My debugging thus far has been very limited - using the CUPS web interface functioned as expected with the unresolvable printer in the system so I think the problem is not directly CUPS-related. I am on Kubuntu 8.10. I'll try and do some more debugging this weekend if possible.

Revision history for this message
Alexander Sack (asac) wrote :

not really network-manager issue.

Changed in network-manager:
status: New → Invalid
Revision history for this message
cgonzalez (cmgonzalez) wrote :

Any chance of this bug getting solved?

Revision history for this message
Anakin Starkiller (sunrider) wrote :

Still nothing on this bug ? I think it should be renamed to something that doesn't contain wifi. In fact, this is just an issue of how to handle the situation when IPP server are not reachable...instead of hanging, a message should appear...It doesn't seem too complicated, and the problem doesn't not come from network-manager or cups, it is gnome print dialog that is somehow flawed ;)

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

Other bug subscribers

Bug attachments

Remote bug watches

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