GNOME Bugzilla – Bug 555745
Programs using Gconf fail if you start via "su"
Last modified: 2018-08-17 13:54:30 UTC
If you start a program that uses GConf after running "su", then it will fail. This is because su allows the user's environment variables to remain, so the DBUS_SESSION_BUS_ADDRESS will be pointing to the wrong bus. I believe this is a new regression because GConf in GNOME 2.24 now depends on D-Bus. You get a lot of errors 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.) --- Note that this issue is also being discussed in D-Bus bug #17970: http://bugs.freedesktop.org/show_bug.cgi?id=17970
Created attachment 120318 [details] [review] patch to try to fix the problem I wrote the attached patch to try and make GConf try a second time to start D-Bus if it fails the first time. It unsets DBUS_SESSION_BUS_ADDRESS and then tries again. However, this doesn't work because D-Bus caches the connection information and will just continue to fail. In D-Bus bug #17970 there is a patch to D-Bus that fixes it so that it will avoid initializing on initial failure which makes this patch work. But perhaps this bug needs a new D-Bus interface to properly fix so that GConf can inform D-Bus to clear its cache before trying to restart. Thoughts?
(In reply to comment #1) > Created an attachment (id=120318) [edit] > patch to try to fix the problem > > > I wrote the attached patch to try and make GConf try a second time to start > D-Bus if it fails the first time. It unsets DBUS_SESSION_BUS_ADDRESS and then > tries again. However, this doesn't work because D-Bus caches the connection > information and will just continue to fail. > > In D-Bus bug #17970 there is a patch to D-Bus that fixes it so that it will > avoid initializing on initial failure which makes this patch work. But perhaps > this bug needs a new D-Bus interface to properly fix so that GConf can inform > D-Bus to clear its cache before trying to restart. > > Thoughts? > I get a lot of these errors using gnome-desktop 2.24, when running gksu. No programs started with gksu is able to connect to configuration server.. "su -" works fine. I can run gedit and load preferences. Although sometimes programs complains that it can not connect to gnome-settings-daemon, but on a rerun it seems to work.
I claim that using "su" instead of "su -" is basically a "don't do that then" situation - http://bugs.freedesktop.org/show_bug.cgi?id=17970 Or, at the very least, if using "su" then you should be switching to an account that is somehow authorized to connect to the existing DISPLAY and DBUS_SESSION_BUS_ADDRESS. I mean, either the new app is in the old session (so you want the old env variables and want to be able to use the display and dbus-daemon), or it's in a new session (and you don't want the env variables and don't want the eixsting display and dbus-daemon). But I don't see why you would ever want the env variables from the old session, but want to ignore them.
Created attachment 124218 [details] [review] updated patch Note we are currently using the attached patch to workaround this issue. Can this go upstream, or is this even needed anymore? I seem to remember some talk about this being fixed directly in D-Bus?
I have tried the updated patch using GConf 2.24.0 and it fails to compile on Slackware 12.2 using GCC 4.2.4: gconf-internals.c: In function 'get_ior': gconf-internals.c:2450: error: 'for' loop initial declaration used outside C99 mode If i move the 'int i = 0' out of the for loop it will compile fine. The updated patch does not solve the problem with gksu --sudo-mode --user root /usr/bin/gnome-terminal so i have tested the old patch also (gnome-terminal does simply crash: see my report on http://bugzilla.gnome.org/show_bug.cgi?id=561663 ) The old patch works as expected and the gnome-terminal opens with user root but using that old patch will cause beagle fail to start: Error: Failed to access dbus session bus. Make sure dbus session bus is running and the environment variable DBUS_SESSION_BUS_ADDRESS is set. System.Exception: Unable to open the session message bus. ---> System.ArgumentNullException: Argument cannot be null. Parameter name: address at NDesk.DBus.Bus.Open (System.String address) [0x00000] at NDesk.DBus.Bus.get_Session () [0x00000] --- End of inner exception stack trace --- at NDesk.DBus.Bus.get_Session () [0x00000] at NDesk.DBus.BusG.Init () [0x00000] at Beagle.Search.Driver.Main (System.String[] args) [0x00000] Without any patch beagle will start fine but a normal user will not be able to start a root-terminal... Markus
*** Bug 576346 has been marked as a duplicate of this bug. ***
*** Bug 575661 has been marked as a duplicate of this bug. ***
*** Bug 587765 has been marked as a duplicate of this bug. ***
So, for now there isn't solution? We have to wait future update?
Marking patch 'needs-work' based on comment #5
*** Bug 593298 has been marked as a duplicate of this bug. ***
The programs are working here (Mandriva2009.1) after I updated Java (guess not important) and tried to start them with su - root. PS: I've updated Java, cause a program (Songbird) told me something about Java-problems. PPS: I know it's never a good idea, but because 'nautilus' was not working with su, I logged in as root itself and found out, that after the Java-update the problem was not appearing anymore when I tried to start 'Songbird'.
*** Bug 598188 has been marked as a duplicate of this bug. ***
*** Bug 615486 has been marked as a duplicate of this bug. ***
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!