GNOME Bugzilla – Bug 677081
non-responding print server prevents session initialization
Last modified: 2012-06-26 12:05:33 UTC
When a network print server is configured in ~/.cups/client.conf, but is not responding (typical example: corporate server, unreachable outside of corporate network), the session initialization fails with usual "ooops, something wrong happened" error windows. This was original reported as https://bugs.mageia.org/show_bug.cgi?id=4708
Here is relevant ~/.xsession-errors content: /etc/X11/gdm/Xsession: Beginning session setup... localuser:guillaume being added to access control list /etc/X11/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent -- /usr/share/X11/xdm/Xsession GNOME GNOME_KEYRING_CONTROL=/run/user/guillaume/keyring-AM1toK GNOME_KEYRING_CONTROL=/run/user/guillaume/keyring-AM1toK GNOME_KEYRING_CONTROL=/run/user/guillaume/keyring-AM1toK GPG_AGENT_INFO=/run/user/guillaume/keyring-AM1toK/gpg:0:1 GNOME_KEYRING_CONTROL=/run/user/guillaume/keyring-AM1toK GPG_AGENT_INFO=/run/user/guillaume/keyring-AM1toK/gpg:0:1 SSH_AUTH_SOCK=/run/user/guillaume/keyring-AM1toK/ssh gnome-session[25360]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout And here is tcpdump output showing attempt to reach a non-existing print server at 192.168.0.1, with exponential delay: 8 12.649647 128.93.30.10 -> 192.168.0.1 TCP 74 51391 > ipp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=13885146 TSecr=0 WS=128 9 13.651625 128.93.30.10 -> 192.168.0.1 TCP 74 51391 > ipp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=13886148 TSecr=0 WS=128 10 15.655615 128.93.30.10 -> 192.168.0.1 TCP 74 51391 > ipp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=13888152 TSecr=0 WS=128 |..] 12 19.663643 128.93.30.10 -> 192.168.0.1 TCP 74 51391 > ipp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=13892160 TSecr=0 WS=128 13 27.679640 128.93.30.10 -> 192.168.0.1 TCP 74 51391 > ipp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=13900176 TSecr=0 WS=128 14 43.727593 128.93.30.10 -> 192.168.0.1 TCP 74 51391 > ipp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=13916224 TSecr=0 WS=128
Hmm, thats pretty bad
Hi, I believe that this is the same problem as we solved in #586207 for Gtk+. I'll implement an asynchronous test of reachability of the CUPS server. I plan to use "g_socket_client_connect_to_host_async ()" which will perform test connection to specified host. Regards Marek
(In reply to comment #3) > I plan to use "g_socket_client_connect_to_host_async ()"... Or whichever async operation of Glib is suitable here.
Created attachment 216499 [details] [review] perform connection test before connecting to CUPS server Hi, attached is a patch which fixes the problem in master. It tests whether it is possible to connect to a CUPS server given by cupsServer() and ippPort() before it actually tries to get destinations from the server and before it tries to create a subscription. It does it asynchronously so it doesn't block start of the daemon. The communication with the CUPS server itself is synchronous. This improves the patch from #674551. Regards Marek
Review of attachment 216499 [details] [review]: ::: plugins/print-notifications/gsd-print-notifications-manager.c @@ +1034,1 @@ + get_dests_with_connection_test (manager); Shouldn't this be reorganized a little ? Do we really want to attempt the get_dests() when the connection test done for subscription already indicated that cups is not there ? And if get_dest fails here, do we ever attempt to get them again, later ? Basically, the flow I would expect (modulo async) is if (cups responds) { renew subscription get dests } queue subscription renewal
(In reply to comment #6) > Shouldn't this be reorganized a little ? I'll look at it next week. > Do we really want to attempt the get_dests() when the connection test done for > subscription already indicated that cups is not there ? And if get_dest fails > here, do we ever attempt to get them again, later ? > > Basically, the flow I would expect (modulo async) is > > if (cups responds) { > renew subscription > get dests > } > queue subscription renewal Marek
Created attachment 217016 [details] [review] perform connection test before connecting to CUPS server Hi, this patch runs connection test first. After successful connection it gets destinations, creates subscription and adds a timeout for renewing of the subscription. It fixes the problem for me. Unfortunately I found another problem during fixing of this. If you create a subscription on a remote server then you won't get dbus notifications from it. We have to implement a polling mechanism for pulling these notifications... I filled bug #678623 for this. Regards Marek
Review of attachment 217016 [details] [review]: Looks reasonable to me now. Unfortunate that it requires so much code
Comment on attachment 217016 [details] [review] perform connection test before connecting to CUPS server I've committed the patch to master branch. Marek