Ok, eu meio que tenho uma correção para isso. Há uma boa explicação deste site link :
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.
Quando eu desconfio de DBUS_SESSION_BUS_ADDRESS, agora posso iniciar o emacs em X depois de su'ing. No entanto, ainda recebo avisos:
(emacs 1879): GLib-WARNING **: In call to g_spawn_sync()...