GNOME Bugzilla – Bug 575916
gconfd becomes confused when $HOME is temporarily unavailable
Last modified: 2018-08-17 13:55:45 UTC
Forwarded from https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/181760 I'm testing kerberos with NFSv4, and this particular bug has been annoyed me for too long, sorry for not filing it earlier.. When your $HOME is on a network filesystem protected by kerberos, you lose all access priviledges when the kerberos ticket expires (usually 12h). So for instance if you lock your screen after the work hours, sometime in the night the apps don't have access to your $HOME anymore. When you unlock the screen, the ticket is refreshed and all is well (pam_krb deals with that, gnome-screensaver et al support that). But, gconfd can become confused some time after the ticket has expired. I don't know what happens, but it doesn't regain the ability to use the $HOME when the ticket is refreshed, instead the app that needs to poke at the configuration spawns a new daemon. This obviously brings problems every time an app tries to save some setting, so you get an error-popup when you just hit the capslock ("No database available to save your configuration...."). Killing all the gconfd's is a workaround, but obviously not what I'm after :) Please let me know how to debug this further.
GConf has been deprecated since 2011. GConf is not under active development anymore. Its codebase has been archived: https://gitlab.gnome.org/Archive/gconf/commits/master dconf and gsettings are its successors. See https://developer.gnome.org/gio/stable/ch34.html and https://developer.gnome.org/GSettings/ for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of dconf/gsettings. Thanks!