GNOME Bugzilla – Bug 586207
Printing dialog with a CUPS printer connected to a switched off remote PC hangs for ~30s
Last modified: 2009-09-24 07:15:30 UTC
Please describe the problem: This certainly happens in Ubuntu Intrepid, Jaunty and Karmic, but on Launchpad they say it's probably an upstream issue as well. So it's more than a year this bug is out in the wild for me. I've got a printer connected to a remote machine; on certain times that machine is powered off for various reasons. While I can queue jobs manually from the command line (for example, "lpr output.pdf"), if I try to print from evince, epiphany or any other program using the default gtk+ printing dialog, and I select the shared printer, the "Print" button is disabled, and thus I cannot queue any job. The funny part I noticed fairly recently, is that I can double-click on the printer name in the GtkListView, and printing starts even if the "Print" button is not enabled; but probably this is *another* bug (and unintended behaviour, too). However, the printing dialog freezes and doesn't redraw and is irresponsive for almost 30 seconds, probably because some polling is being done, making the user believe the application completely hung. I consider this a regression and a bug (not a feature). In my office, for example, there may be cases when the printing server is down, however twenty-thirty people want to queue jobs remotely, and come and retire their sheets only an hour later. They don't care if the printing server is up or not, and that is the benefit of having a local spooling server on a remote PC: as soon as the machine is up again all the jobs in queue get printed. They just want to send a job and forget about it. Expecially if they're printing orders from the sales department, and the sheets get collected only twice per day from the archivist in another room ten km off. Not being able to spool jobs for a unreacheable printer if you're roaming with your laptop, or if the server is down, is quite a drawback in my opinion. Steps to reproduce: 1. Set up a shared CUPS printer on computer A on the LAN 2. Make sure computer B sees the shared printer; in Ubuntu for example it does show in the "Printing" dialog under "System" -> "Administration". You may need to add it manually as a remote printer. 3. Shutdown computer A 4. Fire up Evince (or any other gtk+ app), and select "Print" from the file menu Actual results: a) the dialog comes up, but is empty for about 30s, doesn't get redrawn, and the whole app seems to hang b) the printer on PC A is in the list and you can select it, but the "Print" button is not active. Expected results: a) The dialog is displayed instantly and works well b) I can queue jobs also on the remote printer, even if the other PC is shut down Does this happen every time? Oh yes. Other information:
*** Bug 586208 has been marked as a duplicate of this bug. ***
*** Bug 586210 has been marked as a duplicate of this bug. ***
*** Bug 586211 has been marked as a duplicate of this bug. ***
Created attachment 139388 [details] [review] patch checking availability of remote CUPS printer Hi, this patch checks for availability of the host to which the remote printer is connected. If the host is not available (which means that we know nothing about the printer - we don't have its ppd file) then printing to this printer is disabled. The problem with double click on such printer is reported in the bug #576601. Regards Marek
Marek, I wonder if + GtkCupsConnectionTest *remote_cups_connection_test; should not be per printer, instead of being global for the backend ? Can't we have multiple remote printers whose ppds we try to get at the same time, possibly from different remote cups servers ?
Created attachment 142688 [details] [review] another patch checking availability of remote CUPS printer Hi Matthias, you are right. It is possible to require details for multiple printers at the same time. I modified the patch. It includes remote_cups_connection_test and get_remote_ppd_poll in GtkPrinterCups. It also adds a state message for failure of getting details to GtkPrintUnixDialog. Marek
Hmm, so cups_request_ppd is now a timeout that can be called repeatedly... If one iteration does this: + gtk_cups_connection_test_free (cups_printer->remote_cups_connection_test); + cups_printer->remote_cups_connection_test = NULL; Are we 100% sure that the next iteration won't run into the same if and try to check the status of cups_printer->remote_cups_connection_test again ? Maybe we are sure that the timeout gets removed whenever we go through that gtk_cups_connection_test_free line ? I haven't checked that. And why is the connection test freed in two places ? Maybe it would be cleaner to use gdk_threads_add_timeout_full and move the freeing of the connection test to the destroy notify ? Finally, we should probably look at unifying these timeouts when we fix the 'slow printer list' bug that complains about the 3 second timeout, and replace both cases with the same, shorter timeout.
Created attachment 143582 [details] [review] modified patch checking availability of remote CUPS printer > Hmm, so cups_request_ppd is now a timeout that can be called repeatedly... > > If one iteration does this: > > + gtk_cups_connection_test_free > (cups_printer->remote_cups_connection_test); > + cups_printer->remote_cups_connection_test = NULL; > > Are we 100% sure that the next iteration won't run into the same if and try to > check the status of cups_printer->remote_cups_connection_test again ? > > Maybe we are sure that the timeout gets removed whenever we go through that > gtk_cups_connection_test_free line ? I haven't checked that. If we go through the gtk_cups_connection_test_free() then the cups_request_ppd() function always returns FALSE which removes the timeout. > And why is the connection test freed in two places ? Maybe it would be cleaner > to use gdk_threads_add_timeout_full and move the freeing of the connection > test to the destroy notify ? I removed the freeing of the test in cups_printer_request_details(). It is not necessary. We can not move the freeing to the destroy notify because there is a possibility of success of the first calling of "cups_request_ppd()" which is not executed by the timeout (the line "if (cups_request_ppd (printer))"). > Finally, we should probably look at unifying these timeouts when we fix the > 'slow printer list' bug that complains about the 3 second timeout, and replace > both cases with the same, shorter timeout. I set the timeout to 200 ms.
Comment on attachment 143582 [details] [review] modified patch checking availability of remote CUPS printer Looks good now. Lets hold this until after the 2.18.0 release I'm doing tomorrow, though
Committed: Don't hang print dialog when remote CUPS printer is not available This patch tests availability of remote host before getting ppd file for selected printer (#586207). It also adds a state message for failure of getting details. Marek