GNOME Bugzilla – Bug 725440
plugin blocks all operation when there is a network problem
Last modified: 2019-03-20 11:16:01 UTC
So here is how the problem can be fiarly reliably reproduced: I use my laptop at work and at home, with suspend to memory, I often end with gnome-setting-daemon being block. Among various symptoms, keyboard shortcut do not work ( like increase the luminosity, launch a specific software ). Upon investigation, i found that g-s-d is blocked on this :
+ Trace 233249
My analysis is that cupsDoRequest is synchronous, and if it cannot connect to the cups server ( cups.emea.example.org, in my case ), it wait around 30 seconds, but block the rest of the process. To test, that's quite easy, add a cups server $ cat /etc/cups/client.conf Servername cups.emea.example.org Then block the access to the server, either by having the server blocking, or just nullrouting the address ( or block on the firewall). In my case, this happen when i am connected to the entreprise LAN, and then suspend the laptop and unsuspend it at home. The connectivity to the cups server is no longer working until I start the corporate VPN.
Interestingly, I've started seeing something similar after upgrading to GNOME 3.16/fedora 22. I don't think I hit this issue in the past. Backtrace is different, but symptoms are the same, and imo backtrace is similar enough (cups blocked during a read() call):
+ Trace 234948
Thread 1 (Thread 0x7f2124473980 (LWP 2561))
Actually, must be a different bug as I just hit it after a fresh reboot without any network changes.
Created attachment 301630 [details] [review] Do not block because of authentication (In reply to Christophe Fergeau from comment #2) > Actually, must be a different bug as I just hit it after a fresh reboot > without any network changes. Hi, this is really a different bug. The problem is that the CUPS server you have in your /etc/cups/client.conf requests authentication when getting new notifications. Unfortunately, I don't have a correct solution right now but I've prepared a quick patch which at least prevents print-notifications plugin from blocking whole g-s-d because of the sync password prompt by setting a password callback which always returns NULL (it cancels the authentication). The password prompt is shown on the background only so there is no change for users except that g-s-d is not blocked with the patch. The original bug should be already fixed, I'll check that. Regards Marek
Review of attachment 301630 [details] [review]: ::: plugins/print-notifications/gsd-print-notifications-manager.c @@ +1308,3 @@ manager->priv->printing_printers = g_hash_table_new_full (g_str_hash, g_str_equal, g_free, NULL); + cupsSetPasswordCB2 (password_cb, NULL); Can you add a little comment above that that it is a temporary measure?
Comment on attachment 301630 [details] [review] Do not block because of authentication (In reply to Bastien Nocera from comment #4) > Review of attachment 301630 [details] [review] [review]: > > ::: plugins/print-notifications/gsd-print-notifications-manager.c > @@ +1308,3 @@ > manager->priv->printing_printers = g_hash_table_new_full > (g_str_hash, g_str_equal, g_free, NULL); > > + cupsSetPasswordCB2 (password_cb, NULL); > > Can you add a little comment above that that it is a temporary measure? Thank you for the review. I've added the comment there and pushed it to master and gnome-3-14 branches.
(In reply to Marek Kašík from comment #3) > The original bug should be already fixed, I'll check that. It is not fixed, but I don't want to check connection to the remote server every time we want to call a CUPS command. Maybe another thread would be a solution as Christophe suggested to me.
Fwiw, just had this issue with gnome-settings-daemon 3.22.1, similar backtrace to the one in the initial comment (from main() to cupsSendRequest()). This happened when I pulled the laptop off the docking station (which cut down the wired ethernet connection).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/243.