CUPS hangs when remote CUPS server defined in client.conf is inaccessible

Bug #1050422 reported by Joe Harrington
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When a remote CUPS server is defined in /etc/cups/client.conf like this:

ServerName print.mpia-hd.mpg.de

and the server is not accessible (e.g., it is on a company's internal net and you take your laptop home), then CUPS applications hang for up to several minutes, and then timeout. The gnome printing dialog, for example, hangs Firefox and Chromium, and the lpr, lpq, lpoptions, lpstat, etc. programs also hang and then error out. The localhost:631 interface does NOT hang, and in fact can print test pages on locally accessible printers.

Note that this problem only affects remote SERVERS, not individual remote printers that are inaccessible. Those do not cause a problem.

Expected behavior: missing printers of any sort should not hang programs for any reason. A short delay of a few seconds is ok.

Description: Ubuntu 11.10
Release: 11.10

cups:
  Installed: 1.5.0-8ubuntu6
  Candidate: 1.5.0-8ubuntu6
  Version table:
 *** 1.5.0-8ubuntu6 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.5.0-8 0
        500 http://us.archive.ubuntu.com/ubuntu/ oneiric/main amd64 Packages

The server cited above serves 72 printers, and timeouts ranged from 3 minutes, 9 seconds, to 6 minutes, 19 seconds (I believe but I am not certain that in the longer case, the default printer was on the missing server). It does not matter whether the default printer is one of the missing ones or not, you get a long timeout either way (the duration may matter, as noted above). If you want to change the default printer with lpoptions, you can't, because it hangs, times out, and quits. If you know the printer you want to print to and say lpr -P foo bar.pdf, it still hangs.

Removing the client.conf file and restarting CUPS fixes the problem immediately. So, a workaround is to manually create and remove that file every time you enter/leave the network with the print server. This is not a viable workaround for most normal users.

SPECULATION:
The timeout may depend on how many printers were served on the missing server, and most servers don't have that many.

I very much hope this will be fixed! There do appear to be others experiencing this, but there is little clarity on the web about it (some scattered complaints but few solutions that are practical).

Possibly related:
Note that there is a related bug #264333. It is old and didn't get much response. It may or may not be the same problem. Some there reported it fixed long ago, but others said they still had a problem.
http://askubuntu.com/questions/16726/cant-print-cups-package-corrupted-and-hangs-on-re-install
http://forums.gentoo.org/viewtopic-t-878487-start-0.html

Thanks,

--jh--

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cups (Ubuntu):
status: New → Confirmed
Revision history for this message
Carthik Sharma (carthik) wrote :

See also Bug #264333

Revision history for this message
Joe Harrington (joeharr) wrote : Re: [Bug 1050422] Re: CUPS hangs when remote CUPS server defined in client.conf is inaccessible

Yes, this is noted at the end of the initial report.

--jh--

Revision history for this message
Steffen Neumann (sneumann) wrote :

Hi,

I can confirm the hanging on both a laptop running 14.04 and a freshly installed 14.04,
the cups client is on a Ubuntu 10.04.4 LTS running cups 1.4.3-1ubuntu1.13

But in our case the cups server IS perfectly accessible with ping,
and nmap shows an open port 631/tcp open ipp

Removing ServerName fixes the hanging.

Can I do other checks to see where e.g. lpq hang ?

Yours,
Steffen

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

Other bug subscribers

Remote bug watches

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