GNOME Bugzilla – Bug 558375
gconfd does not refresh cache when sudo-ing current user to modify setting
Last modified: 2018-08-17 13:54:45 UTC
Please describe the problem: GConfd seems to be no longer refreshing the client-side cache properly in Intrepid beta. Changes made by the current user with the configuration-editor (gconf-editor), or using pure gconftool-2 or another program (e.g., gnome-network-preferences) will update GConfd's cache properly, however, changes made using sudo -u $USRE gconftool-2... will not notify GConfd to update it's cache. This is using the XML backend by the way. Steps to reproduce: This is most easily demonstrated by running the following in a terminal (WARNING: will modify your network proxy settings): 1. Check existing settings: gconftool-2 --get /system/proxy/mode #will echo the current state as gconfd see's things sudo -u $USER gconftool-2 --get /system/proxy/mode #will echo the current state as the underlying xml file actually is 2. Change the settings in gconfd gconftool-2 --type string --set /system/proxy/mode manual #will update the gconfd's settings gconftool-2 --get /system/proxy/mode #will echo 'manual' sudo -u $USER gconftool-2 --get /system/proxy/mode #will echo 'manual' 2. Change the settings in the underlying xml file sudo -u $USER gconftool-2 --type string --set /system/proxy/mode none #will update the gconfd's settings gconftool-2 --get /system/proxy/mode #WILL STILL ECHO 'manual' sudo -u $USER gconftool-2 --get /system/proxy/mode #will now echo 'none' Actual results: running gconftool-2 --set will update the xml backend, and gconfd properly, however running sudo -u $USER gconftool-2 will only update the xml backend, and gconfd will not reflect the updated value until either gconf-editor is opened (I assume this forces a cache refresh somehow), or gconfd is restarted (gconftool-2 --shutdown) Expected results: I would expect gconftool-2 and sudo -u $USRE gconftool-2 to behave identically, and update both the XML and the gconfd cache Does this happen every time? Yes Other information:
that's because sudo strips the environment. sudo -u $USER env DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS gconftool-2 ... should work
I can confirm this is the case. Why has this functionality changed between 2.22 and 2.24 release of gconf? I have tested this under Ubuntu Hardy and Intrepid, and Hardy works successfully (i.e., cache updates properly) without specifying the DBUS_SESSION_BUS_ADDRESS, while Intrepid exhibits the behaviour described in the bug. Was there an intentional change between these versions that should cause this effect?
Yes, see bug 141138 and and bug 507310. Maybe dbus should store the session bus address in the session kernel keyring, or in an X property instead of an environment variable though.
Thankyou for your help! Just putting this note here to help others in case they experience the same problem, the current dbus session for a specified user can be grabbed with the following code-snippet (there might be an easier way but I don't know it at the moment...): DBUS_SESSION_BUS_ADDRESS=$(sudo -u $USER dbus-launch --autolaunch=`cat /var/lib/dbus/machine-id` | grep BUS_ADDRESS | cut -d '=' -f 2-)
The aforementioned workaround needs to have an appropriate XAUTHORITY environment variable defined. To sudo without doing this (e.g., from a command line process), try something like the following: # assumes the $USER and $HOME directories are defined somehow DBUS_SESSION=$(grep -v "^#" $HOME/.dbus/session-bus/`cat /var/lib/dbus/machine-id`-0) sudo -u $USER $DBUS_SESSION gconftool-2 --type string --set /system/proxy/mode manual
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!