gconfd does not refresh cache when sudo-ing current user to modify setting

[Philip Peitsch]

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.

It is possible to work around this by either restarting gconfd (by running gconftool-2 --shutdown), or opening gconf-editor. Both of these seem to force the cache to reload somehow.

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'

gconf2:
  Installed: 2.24.0-0ubuntu1
  Candidate: 2.24.0-0ubuntu1
  Version table:
 *** 2.24.0-0ubuntu1 0
        500 http://mirror.optus.net intrepid/main Packages
        100 /var/lib/dpkg/status

== Regression details ==
Discovered in version: 2.24.0-0ubuntu1
Last known good version: 2.22.0-0ubuntu3

[arno_b (arno.b)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.
This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage.
I have classified this bug as a bug in gconf.

[gsubes (gsubes)]

I have the same problem, though using gconftool-2 --shutdown doesnt solve my problem.

I am trying to change the proxy settings of the main user depending on the vpn state via a networkmanager dispatcher script.

More info about the things i found out about this bug can be read in the forum thread:
http://ubuntuforums.org/showthread.php?p=6051923#post6051923

[Sebastien Bacher (seb128)]

that's not a bug as indicated on the upstream bug

[Philip Peitsch (philip-peitsch)]

Yes, I agree this isn't a bug so much as a "feature change"...

A workaround as recommended upstream is to export the DBUS_SESSION_BUS_ADDRESS with the sudo command, i.e., sudo -u $USER DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS <command>

In the case that one is running a script that doesn't *have* the right DBUS_SESSION_BUS_ADDRESS variable, it can be retrieved for an arbitrary user with the following snippet:
DBUS_SESSION_BUS_ADDRESS=$(sudo -u $USER dbus-launch --autolaunch=`cat /var/lib/dbus/machine-id` | grep BUS_ADDRESS | cut -d '=' -f 2-)

[Philip Peitsch (philip-peitsch)]

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

[Kaylee Hirsch (techyshishy)]

This is a bug in either su or sudo. When copying the user environment, it fails to correctly copy the DBUS_SESSION_BUS_ADDRESS, DBUS_SESSION_BUS_PID, and DBUS_SESSION_BUS_WINDOWID variables. This may be working as intended, I'm not sure exactly how sudo/su function in terms of copying transient variables from a currently running session. Note, the above solution *does* work, albeit being a bit of a hack. Because of it's failure to copy the variables, gconftool-2 cannot find the currently running gconfd process, and silently fails to send it the reload config signal.

gconftool-2 should report when it fails to find a running gconfd process.