Application lock if default printer can't be reached

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

Still an issue. Current configuration looks like this:

Linux pokeefe-laptop 2.6.27-10-generic #1 SMP Fri Nov 21 12:00:22 UTC
2008 i686 GNU/Linux
Ubuntu 8.10

cups-config --version
1.3.9

gedit 2.24.2

One remote printer configured as default:
lpp://10.0.0.1:631/printers/Photosmart-C4200-series

Second machine is currently powered off. Print dialog in gedit hangs
for approximately 1 minute in this configuration before giving me a
dialog that allows selecting an alternate printer. If I power on the
machine with the printer attached, dialog is instantaneous.

On Fri, 2008-12-05 at 23:41 +0000, IanW wrote:

> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering is this still an issue
> for you? Can you try with latest Ubuntu release? Thanks in advance.
>
> ** Changed in: cups (Ubuntu)
> Sourcepackagename: None => cups
> Status: New => Incomplete
>

This happens when the default is a raw IPP queue which points to an IP address which does not exist in the network, as the dialog asks CUPS for the properties of the selected printer (which is the default printer in the beginning) and the appropriate CUPS library function sees a raw IPP queue and for this it assumes that it is a printer on a remote CUPS server and tries to get the PPD from there. Then it tries to access the remote CUPS server without forking a sub-process and without setting a very low timeout (if this is possible).

This is a bug of the CUPS library, as it happens also with non-GNOME/GTK clients.

Workaround:

Remove your IPP queue pointing to your home printer.

Make sure that your home print server broadcasts the printer (set printer to be "shared" in system-config-printer and in the "Server Settings" mark the field for sharing your printers, too). On the laptop set in the "Server Settings" of system-config-printer that you want to use remote printers. Then you home printer will get available again on your laptop, with the same queue name as on the server (click "Refresh" in system-config-printer if you do not see it). Set it as system-wide default. If your laptop cannot reach your server now, this queue will completely disappear and the dialog will point to "Print to a file" by default. The printer will appear again and get default as soon as you return to your home network.

Reported upstream as

http://www.cups.org/str.php?L3033

There is also a GNOME/GTK upstream report about it:

http://bugzilla.gnome.org/show_bug.cgi?id=508905

Qt upstream bug report:

http://trolltech.com/developer/task-tracker/index_html?method=entry&id=232664

Only OpenOffice.org does not hang, but in such a case it does not show the PPD options of any local print queue, even not of the locally defined queues.

OpenOffice.org can also hang in this case under certain circumstances:

http://www.openoffice.org/issues/show_bug.cgi?id=65739

Also system-config-printer has the problem:

bug #207395
https://fedorahosted.org/system-config-printer/ticket/117

Mike Sweet (author of CUPS) has closed the bug report on CUPS. This means that the problem has to get fixed in the individual printing dialogs, in Qt, GTK, and if needed also in individual applications like OpenOffice.org or system-config-printer.

I hope we will have the Common Printing Dialog (https://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialog) soon.

sigh ... too bad when important projects are a one-man-show.

CUPS lacks a feature that openldap for example implments with LDAP_OPT_NETWORK_TIMEOUT.

You can easily reproduce the problem in CUPS by setting

ServerName some-unused-ip-address-in-your-local-subnet

in /etc/cups/client.conf.

Samba had the same problem and implemented a workaround for the lack of a connect timeout in cups:

http://git.samba.org/?p=samba.git;a=commitdiff;h=765e5d2282959770ea9648e0f2b72e51e5b4cdd8