remote printer : freeze when not available

[®om]

At home I have a desktop and a laptop. The printer is connected to the desktop.
On the laptop, I added a "remote printer", using ipp://... It works fine.

But when I am at work with my laptop, of course my desktop printer is not available. When I want to print something (in gedit for example, but the same with all softwares), It totally freeze the appli during about 1 or 2 minutes (wait... exactly 65 seconds) while it looks for the printer.

This search should be asynchronous, it should not freeze the program (during 65 seconds, which is not 1 or 2 seconds) which wants to print.

I use Ubuntu 8.04.1.

[Ian Weisser (ian-weisser)]

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.

[Juho Rutila (juho-rutila)]

I'm experiencing the same problem.

I'm running Ubuntu Intrepid (8.10).

Cups version is 1.3.9-2ubuntu6.1.

Is there some other information that I can provide?

Steps to reproduce:
1. Install remote printer with ipp-protocol
2. Unplug your computer from network (so no connection to server)
3. Try to print something from evince

Result: it doesn't open the print-dialog, Evince freezes and crashes finally

Should do: Open the print-dialog

[Richard Seguin (sectech)]

Thank you for reporting this issue. I believe that there is a timeout value that needs to be met when discovering remote printers so that's why it could appear as hung. I'll test this and see what I can come up with.

[Richard Seguin (sectech)]

* Flagging as incomplete as I will test and see if I can come up with a crash report for this.

[luebbecs (carlos-luebbe)]

I'm having the same problem with ubuntu 8.10 and cups 1.3.9

I defined a remote cups server via the /etc/cups/client.conf

When my laptop is not connected to the network and I try to open a printing dialog, the application freezes for about 1 minute. I tried with different applications. Also the /System/Adminstration/Printing utility freezes.

[Siegie (siegie)]

I'm still experiencing this issue in ubuntu jaunty.
It's a very irritating bug. I can't print a file to pdf quickly when i'm not at home connected to the network printer.

Richard can you reproduce this?

[luebbecs (carlos-luebbe)]

I updated cups to version 1.3.9-2ubuntu9 and it works for me now. But I'm still using intrepid.

[Juho Rutila (juho-rutila)]

I can confirm that cups 1.3.9-2ubuntu9 works on Intrepid 8.10. Problem solved for Intrepid, good job.

Siegfried, what version are you running?

[Siegie (siegie)]

I'm running the latest version available in jaunty.
Architecture: amd64
Version: 1.3.9-17

I will attach my printer.conf file.

[Siegie (siegie)]

It only happens when the network printer is the default printer.
When i install a local printer a default i don't have the problem. The print dialog shows up even if the local printer is unplugged.

I hope this is enough info to fix the bug.

[Juho Rutila (juho-rutila)]

Siegfried, now the latest package is 1.3.9-17ubuntu1. Are you experiencing the problem still? I'm not (I updated to jaunty awhile ago).
It doesn't matter if it is default or not.

[Siegie (siegie)]

sorry Juho,
I'm still experiencing this bug, and i'm using 1.3.9-17ubuntu1 .

[Pascal S (pascal.s)]

Same problem here : I wanted to print a web page to a pdf file at a moment when the remote printer was not available (because the printer it is connected to was off at that time). Instead of opening the printing dialog, firefox froze. I am using Ubuntu 9.04 and cups 1.3.9-17ubuntu3.1 (jaunty-updates).

[Pascal S (pascal.s)]

What kind of information or further tests are needed to change the status of the bug from incomplete to confirmed ?

[Sangala (sangala)]

The problem is not solved for now ? (For Ubuntu 8.04)
I ask too: "What kind of information do anybody need to find a workaround ?"
Acrobat reader printer dialog, Gnome configuration of printer dialog etc. freeze and the remote printer is not default printer!.

[Travis O'Brien (travis-obrien+ubuntu)]

I confirm the issue on Ubuntu 9.04, Jaunty.

The work-around proposed by Siegfried De Bie doesn't entirely fix the problem, because programs that open the last-used printer instead of the user's default printer (like Adobe Reader) will still try to open the printer and hang if the missing remote printer was the one last-used.

[Sangala (sangala)]

Yes, default printer not solve the problem.
Some application (ex. Adobe Reader) try open dialog with last-used printers - that is the problem.

Very stupid workaround № 1 is:
 1. Disconnect from ethernet
 2. Open the silly application (Acrobat Reader etc.)
 3. Print document - using another accessible printer (usb printer or pdf printer)
 4. Connect to ethernet
Last-used printer is the usb printer for now…

Workaround № 2 - use a lot of your memory resources:
You HAVE TO print a document by pdf printer EVERY TIME after you print by remote printer.
Last-used printer is PDF printer for next use.

High IT solution № 3 is:
Create a virtual machine in each network - with IP address of remote printer and add CUPS fail printer.
(When remote CUPS answer "This printer is off" it is OK)

Somebody please find a solution № 4! - thank's

[Sangala (sangala)]

When is REJECTed all outgoing packed it is OK (freeze 3-5sec only).

Wok-around № 5
If remote printer is not present insert firewall rule:
iptables -I OUTPUT -p tcp -d ipadress --dport 631 -j REJECT
If remote printer is presented delete firewall rule:
iptables -D OUTPUT -p tcp -d ipadress --dport 631 -j REJECT

My working wok-around № 5
I write scripts /4pcs/ (it is attached in zip file):
reject-remote-printers script:
  define function processByPing()
and
 call function processByPing() for each remote printer. It is at the end of this script.
The function has 3 parameters
1st = IP address of remote printer or remote printer server
2nd = port, usually 631
3rd = MAC address of remote printer or remote printer server

Example: processByPing 192.168.0.116 631 00:02:17:D4:1B:32
(It is included in the script on the 4th row from the end of the script - you have to modify this line.
 You can repeat this line for every remote printer with valid IP and MAC address)

reject-remote-printers
 insert call of this script to /etc/rc.local file (with & at the end of line)
 call this script every time after connect to network (I use WICD manager, the manager has this option - /after-connect script/)

run-wicd-off-reject-remote-printers
 call every time after disconnect from network
   WICD manager run disconnect script BEFORE disconnect - it is a smal problem.
   Solution is use "run-wicd-off-reject-remote-printers" instead reject-remote-printers.
     "run-wicd-off-reject-remote-printers|" script call asynchronously script "wicd-off-reject-remote-printers"
        and "wicd-off-reject-remote-printers" sleep for 3 seconds ... and next call "reject-remote-printers" script

g-reject-remote-printers
 add to a GNOME menu for manually renew all remote printers.
  You have to use visudo command and insert next line for use this command by every user without password:
   ALL ALL=NOPASSWD: /YOURfullPathToScript/reject-remote-printers

(I hope you understand my English)

[glass.dimly (jmjohn)]

This is too much.

I mean, seriously, the core printing component on the largest Linux distribution in the world freezes for sixty seconds when attempting to print to a remote printer through CUPS (the native Linux print system) when that remote printer is not present.

This is the sort of bug that needs to be closed. I refuse to utilize an enormous workaround script to solve this.

Some developer has to have a good way to close this bug.

Bug confirmed on Jaunty.

[Steve Kroon (kroon)]

I've also got this problem, running Firefox 3.0.14 on Jaunty, with cups version 1.3.9-17ubuntu3.2.

I must connect to a CUPS server to print at work, but this server is inaccessible from home due to a firewall. If I forget to edit the client.conf before printing at home, my firefox is out of action.

[Bob Blanchard (blabj)]

This problem rears its head in many applications. Some WINE apps, for example, try to connect to ALL defined cups printers (regardless of whether they are set as default, or were the "last-used" printer), and hang, waiting for connection to remote printer which isn't connected. Another example is "vym", which won't even start if it cannot connect to ALL printers.. see https://bugzilla.novell.com/show_bug.cgi?id=418439 ...

Some apps will timeout, but some seem to hang forever (Adobe acrobat).

MacOS uses CUPS - I wonder how it handles the same situation??

Anyway, the best solution I could find so far is based on what was posted above by Sangala. IE. a script that checks which printer is accessible and IF NOT, rejects packets destined there.

I toyed with the idea of having a script which actually removed the printer from cups (lpadmin -x), but re-creating the printer is a little more involved, and it seems like overkill. Unfortunately disabling or rejecting the printer within CUPS, does not stop it from broadcasting the printer to requesting applications.

Anyway, I simplified Sangala's script (removing requirement for MAC) and put it in cron to run every 5 minutes (this is on a server running 24x7 with some off and on VPN connected printers):

#!/bin/bash

PINGTIME=3
PINGCOUNT=1
PINGCMD="/bin/ping"

processByPing(){
  if [ $# -eq 2 ]; then
    $PINGCMD -c $PINGCOUNT -q -W $PINGTIME $1 > /dev/null
    if [ $? = 0 ]; then
       iptables -D OUTPUT -p tcp -d $1 --dport $2 -j REJECT &> /dev/null
       #"Printer on IP: $1 port: $2 is accessible"
    else
      iptables -D OUTPUT -p tcp -d $1 --dport $2 -j REJECT &> /dev/null
      iptables -I OUTPUT -p tcp -d $1 --dport $2 -j REJECT &> /dev/null
      #"Printer on IP: $1 port: $2 is NOT accessible"
    fi
  else
    echo "Bad parameters"
  fi
}

#Detect remote printers
#every remote printer server or printers
#1st IP addres
#2nd port

processByPing 10.8.0.62 631 #vpn connected printer #1
processByPing 10.8.0.74 631 #vpn connected printer #2

exit 0

I saved it as /usr/local/sbin/reject-remote-printers (and chmod 744) and added this to cron:

*/5 * * * * /usr/local/sbin/reject-remote-printers

This way, within 5 mintues of VPN users connecting, their printers are able to receive packets... and within 5 minutes of disconnecting, the packets are rejected.

Thanks Sangala for the idea! It maybe convoluted, but it works!!

[Joe Harrington (joeharr)]

This problem (or a closely related one, I can't tell) is still not (fully?) fixed in:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.10
DISTRIB_CODENAME=oneiric
DISTRIB_DESCRIPTION="Ubuntu 11.10"

using

cups-1.5.0-8ubuntu6

Here is some more detail than given above:

Printers defined locally that are not connected/accessible, whether by USB or directly on the net, do not cause a problem. However, a remote CUPS server defined in /etc/cups/client.conf like this:

ServerName print.mpia-hd.mpg.de

causes a hang of 3-6 minutes if the server is not there. For the record, this server serves 72 printers, and the longest measured timeout was 6 minutes, 19 seconds. It does not matter whether the default printer is one of the missing ones or not.

Applications hang in predictable ways: the print dialogue in gnome, which Firefox and Chromium use, causes that entire browser to hang while waiting, even if all you want to do is print to file. 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 specify lpr -P foo bar.pdf, it hangs. So does lpq, and so on.

However, the localhost:631 interface is *unaffected*, and can print test pages without delay.

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.

My guess is that few people think they are experiencing it because the timeout depends on how many printers were served on the missing server, and most don't have that many. This looks like it should be a simple fix of querying the printers in parallel and giving them a few-second timeout.

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).

Thanks,

--jh--

[PomCompot (pomme-compote-launchpad)]

I can confirm this problem is gone for me in Precise Pangolin.

[Lars Mohrmann (lars-mohrmann)]

I can confirm the bug as described by joeharr on Kubuntu 12.10 Quantal Quetzal. Also, his workaround removing the client.conf file does not work for me, since the file does not exist in that location for me. Restarting cups did not solve the problem either. I did not have this problem with Kubuntu 12.04 or Kubuntu 11.10. Can anybody confirm or provide a workaround for this?