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

Bug #290647 reported by Philip Peitsch on 2008-10-29
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Won't Fix
gconf (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

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'

  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

description: updated
description: updated
arno_b (arno.b) wrote :

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) wrote :

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:

Sebastien Bacher (seb128) wrote :

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

Changed in gconf:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Triaged
Philip Peitsch (philip-peitsch) wrote :

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) wrote :

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

Changed in gconf:
status: Unknown → New

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.

Changed in gconf:
importance: Unknown → Medium
Changed in gconf:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.