linux gedit: I always get "GConf Error: failed to contact configuration server ..."

Question

How come I always get

"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://projects.gnome.org/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.)"

when I start 'gedit' from a shell from my superuser account?

Gereron

(and yes, that's normal, I don't remember what's the culprit, but it's one of the environment variables that prevents contact with configuration server. most likely HOME). – Pratte

I think that this belongs to Super User or Server Fault. – Schadenfreude

Sorry guys... I'll move to Super User. – Gereron

Answer 1

The technical answer is that gedit is a Gtk+/Gnome program, and expects to find a current gconf session for its configuration. But running it as a separate user who isn't logged in on the desktop, you don't find it. So it spits out a warning, telling you. The failure should be benign though, and the editor will still run.

The real answer is: don't do that. You don't want to be running GUI apps as anything but the logged-in user, in general. And you never want to be running any GUI app as root, ever.

Pudendum

What's your argument for these prescriptions? – Teressaterete

ok, I didn't downvote, but won't upvote either because "never" is too harsh. I run the file manager as root when I want to easily copy a bunch of little (rootful) stuff without having to cp them all one-by-one. – Bujumbura

Still, this is not entirely a complete answer. A good example is 'ssconvert' from the gnumeric suite, which is a console application. It still calls gconf, and causes this error, if called from, eg., a cron job or over ssh. Setting DISPLAY:0 doesn't work either - dbus then complains. – Leesen

@Andy Ross: "you never want to be running any GUI app as root, ever" - you have to run GParted's GUI as root, for example :P (and there are many other examples...) – Singh

Answer 2

I've been using GUI apps as a logged-in user and as a secondary user for 15+ years on various UNIX machines. There's plenty of good reasons to do so (remote shell, testing of configuration files, running multiple sessions of programs that only allow one instance per user, etc).

There's a bug at launchpad that explains how to eliminate this message by setting the following environment variable.

export DBUS_SESSION_BUS_ADDRESS=""

Giusto

don't work. same GConf Error: Failed to contact configuration server;... – Carrissa

Did nothing for me. – Evanevander

Solved the issue in my case - and it now finds the configuration and not loading the default as before. Looks like a bug for sure. – Trafficator

Answer 3

For some (RHEL, CentOS) you may need to install the dbus-x11 package ...

sudo yum install dbus-x11

Additional details here.

Armington

Installing the dbus-x11 package on our RHEL 6.7 server eliminated most of the warnings for me, leaving only two warnings related to missing theme icons. – Denary

Answer 4

Setting and exporting DBUS_SESSION_BUS_ADDRESS to "" fixed the problem for me. I only had to do this once and the problem was permanently solved. However, if you have a problem with your umask setting, as I did, then the GUI applications you are trying to run may not be able to properly create the directories and files they need to function correctly.

I suggest creating (or, have created) a new user account solely for test purposes. Then you can see if you still have the problem when logged in to the new user account.

Staffard

Answer 5

I ran into this issue myself on several different servers. It I tried all of the suggestions listed here: made sure ~/.dbus had proper ownership, service messagbus restart, etc.

I turns out that my ~/.dbus was mode 755 and the problem went away when I changed the mode to 700. I found this when comparing known working servers with servers showing this error.

Imitate

I recently ran into this problem again. The permissions on ~/.dbus were fine. This is what solved the problem the second time it cropped up: 1) rm /var/lib/dbus/message-id 2) sudo service messagebus restart 3) export $(dbus-launch) – Imitate

Answer 6

I understand there are several different answers to this problem, as I have been trying to solve this for 3 days.

The one that worked for me was to

rm -r .gconf
rm -r .gconfd

in my home directory. Hope this helps somebody.

Deboer