GConf Error: Failed to contact configuration server using root user

[Vadim Nevorotin]

Binary package hint: gconf

Since Ubuntu 8.10 (I've tried it in 8.10 and 9.04 alpha5) there is a very strange bug. If you set a root password (e.g. with command sudo passwd root) and then log in to root in a terminal using command su a lot of GNOME applications start from this root session with an error like this:

GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)

For example, gedit and firefox. But if you log in into root session with command sudo su everything works perfectly. To be honest, I can't understand difference between su and sudo su.
Yes, I extremely well know, that using sudo instead of root account is safer and preferable BUT sometimes it's better and easier to use root account.

[Sebastien Bacher (seb128)]

thank you for your bug report, that's not a bug though, you need to start a dbus session bus or use dbus-launch

[Arnaldo Mandel (am-ime)]

I just upgraded to Jauunty alpha6 from intrepid. The bug is new.

gnome-terminal opens fine from my user account. However
gksudo gnome-terminal
sudo gnome-terminal

end with just the line:

Failed to contact the GConf daemon; exiting.
(there was not even a linefeed at the end)

Tried the same with gedit, it came up.
Tried with tomboy (works normally from my account), it didn't come up, and produced a backtrace, attached.

This box is not an nfs client, so I suppose nfs locks are not to be looked for. As for orbit, I could not find any docs on how to enable networking for it.

dbus is on. From ps:

root 12572 1 0 17:38 pts/0 00:00:00 dbus-launch --autolaunch e1190ffd58d35b3da111b4f9495a54b1 --binary-syntax --close-stderr

Is it still a non-bug?

[kantor (kantorzsolt)]

Hi, it is not quiet a but, but indeed is annoying.
The explanation of the problem is the following:

When you su to root from a terminal where you are logged in as another user the new "su-ed" user gonna inherit the environment variables from the parent shell user.

Example: let's say that for the user jack the DBUS_SESSION_BUS_ADDRESS environment variable is set to: "unix:abstract=/tmp/dbus-l5SiTFzmR8,guid=1af28c9d83400a896ef6268d4a7af59f"
Now if you open a terminal as jack and make a su to root the DBUS_SESSION_BUS_ADDRESS variable shall remain
as for the user jack. And here is the problem, exactly this specific env. variable (DBUS_SESSION_BUS_ADDRESS) generates that problem.
Gnome programs like gedit, nautilus . . . use the dbus protocol to communicate with gconf where application specific configurations are stored, and not just.
A program executed as root uses a different D-Bus session bus address compared when you execute that program as the jack user for instance. So the problem is that you switch to root, but the DBUS_SESSION_BUS_ADDRESS variable still points the the jack's dbus session bus address.

Solution:
The root user has a separate dbus session address too (located in /root/.dbus/session-bus/. . .)
So to use the root's dbus address when you are in a terminal and "su-ed" to root just clear the DBUS_SESSION_BUS_ADDRESS variable. like: export DBUS_SESSION_BUS_ADDRESS=""
A program that needs dbus communication with gconf for instance, checks that environment variable, and if it is empty it reads the dbus address from the users ~/.dbus/session-bus/ directory (the right place).
To make this permanent add the following line to the root users .bashrc file:
export DBUS_SESSION_BUS_ADDRESS=""
This means that every time when you su to root and the terminal is not a login shell (the case when you are logged in as jack and opened a terminal and executed su) the DBUS_SESSION_BUS_ADDRESS variable is cleared, so the applications gonna read the dbus address from the right place.

by the way you do not need to start a new dbus session with dbus-launch. Even if you do so but the applications still read the dbus address from the wrong place, the problem will persist.

[Wladimir Mutel (mwg)]

It seems that DBUS_SESSION_BUS_ADDRESS is propagated not only through environment variable, but through X11 atom as well. So with Ubuntu 10.04 clearing the env.var just does not work ...

[Peter Schwekendiek (peter-schwekendiek)]

Got the same bunch of error messages until I tried

$ sudo -Hs

or

$ sudo -H gedit /somewhere

changing to root's home should also avoid overwriting your home .dbus. by root.