[gnome-terminal SRU] Cannot start gnome-terminal (or x-terminal-emulator) because of gconf error

[Pete Goodall]

Binary package hint: gnome-terminal

IMPACT: gnome-terminal will fail to launch under any circumstance where gconfd isn't already running. This can include `sudo gnome-terminal` (since no gconfd is running for root), or starting gnome-terminal under a non-GNOME window manager.

DEVELOPMENT: The Debian maintainer added 02_let_gconf_autostart.patch in 2.26.2-2 to solve this issue (debbugs #531734). That version has been merged into Karmic.

PATCH: Patch available at http://launchpadlibrarian.net/30671489/gnome-terminal_2.26.0-0ubuntu2.1.debdiff, with test builds in https://launchpad.net/~broder/+archive/ubuntu-tests. The upstream gnome-terminal maintainer rejected the patch used for 02_let_gconf_autostart.patch, because it reintroduced gnome-bugs #561663. The attached patch instead cherry-picks the commit the maintainer added to fix this bug upstream.

INSTRUCTIONS: Attempt to run `sudo gnome-terminal`. It will exit with "Failed to contact the GConf daemon; exiting."

REGRESSION: Seems limited - this is a cherry-pick of an upstream change that only changes a handful of lines.

============
Original bug description:

I cannot start gnome-terminal. If I open an xterm and start gnome-terminal from the command line, here is what I get:

$ sudo gnome-terminal
Failed to contact the GConf daemon; exiting.
(original report didn't have sudo in this command, but a later comment by the submitter amended this.)

$ ps ax | grep gconf
 3956 pts/0 R+ 0:00 grep gconf
 6643 ? S 0:00 /usr/lib/pulseaudio/pulse/gconf-helper
 6647 ? S 0:06 /usr/lib/libgconf2-4/gconfd-2

This is in Jaunty Alpha 4 with all updates current as of 12 Feb.

 This bug is now understood. Read all the comments (or at least try some text searches) before adding your own, because a lot of things have already been covered.

summary of some stuff posted in comments:
 gnome-terminal on purpose refuses to start if it can't connect to gconfd to get its config settings.

 gconf clients now find the server using DBUS. Starting gnome-terminal as root doesn't work even when you have all the gnome bits and pieces running under your account, because DBUS is per-user.

executive of summary: We know what is going on. Everything that doesn't work is a consequence of the design. Everything is working as designed, although obviously there are problems with this design. Discussion about the design probably belongs on freedesktop-bugs #17970 (link in the remote bug sidebar).

 Workarounds to use until the bugs are fixed:
for the gconfd-not-running case:
start gconfd. e.g. add /usr/bin/gnome-settings-daemon to your X session startup script, ahead of any gnome-terminal commands. This applies whatever window manager you happen to be using. (except if you're using Ubuntu's default GNOME desktop, which already starts gconfd itself.)

multiple tabs over ssh:
use screen(1)
$ sudo aptitude install screen screen-profiles # if you don't have it already
The default config has unhelpful keybindings. I'm used to ^t as the command key, and F11/F12 as next/previous tab (screen calls them "windows"). I set up my own .screenrc before screen-profiles was packaged, so I don't know if its examples and samples are good or not.
If you insist on displaying a GUI over X11 over ssh, there are other terminal emulators with tabs, e.g. the lighter-weight mrxvt. (be careful, though: it doesn't support UTF-8.)

 You might also investigate ssh -M for connection sharing. As I understand it, this lets you tunnel multiple sessions over one SSH connection, so only one password prompt... You could presumably get a local gnome-terminal going with ssh connections in each tab.

root shells:
You can use sudo inside a gnome terminal that's running under your own account. sudo -s, sudo -i, sudo su, and sudo bash are all variations on getting a shell running as root. If you don't know which to pick, use sudo -s. Or, better, don't start a root shell, and simply use sudo or gksudo on the one or two commands that need it.

 This bug is partly that gconf requires DBUS, which breaks some remote-GUI situations, and partly that gnome-terminal just refuses to start without gconf, even though some people have found that it actually works if they comment out that part.

 Armed with this knowledge, this bug shouldn't be more than a minor inconvenience, esp. if you're not dealing with ssh. (GNU screen takes some time to get used to...)

 I hope it's ok that I turned this bug's description into a guide on how to deal with it. Please correct any inaccuracies.

[Halton Huo (halton-huo)]

Please check the comment by Erwann http://defect.opensolaris.org/bz/show_bug.cgi?id=2980#c7, is that correct way to go?

[Johnp-redhat (johnp-redhat)]

I was unaware that the D-Bus port of GConf made it into a stable release. For the most part it was a hack for the maemo and shouldn't be use unless there was some development there recently. I don't see it running as a D-Bus service on my system.

Most likely the report is wrong. There isn't much details other than there is an error and configuration is lost. Does GEdit run? It runs just fine for me though GnomeUI does complain:

 GnomeUI-WARNING **: While connecting to session manager:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.

That is absolutely because the user is trying to run as a different uid but still has the DBUS_SESSION_BUS_ADDRESS pointing to his own bus. This is completely a security feature and not a bug. Using `su -` is the correct way to log into a new session. BTW by the above warning it is the session manager that can't be connected to. The suggestion at http://defect.opensolaris.org/bz/show_bug.cgi?id=2980#c7 is correct except for the su suggestion is swapped. The correct command is su - not su.

Closing as not a bug.

[Colin Walters (walters)]

John: In the upstream code GConf uses DBus now just as a naming service to avoid multiple copies, but not yet for IPC.

Halton: Clearing the environment as Erwann suggested will probably work. But I want to emphasize that having a different uid connect to your X session is not something we want to support. The reason is that the other uid has *total control* over your X session, and therefore effectively can do anything it wants to programs running as your uid.

If you are running gedit as another user to gain access to a file for example, I suggest using ACLs. If you don't want the other programs to have access to your files etc. (i.e. you're running as a test user for sandboxing reasons), then the correct thing to do is to create a new login session as that user.

[Dar (darren-kenny)]

I agree that we shouldn't support allowing another user to connect, but this is only part of the issue, and I don't think closing this as not a bug is the right answer.

If this error occurs libgconf or libdbus should automatically start a local session bus so that the user isn't left unable to get any GConf settings (maybe this is not the case, but it's certainly the impression with the error being reported).

To not auto-start a session is essentially a regression over the prior behaviour.

[Colin Walters (walters)]

Can pfexec be patched to clear the DBUS_SESSION_BUS_ADDRESS environment variable? I believe libdbus will auto-spawn a bus for compatibility if it's not set.

The issue here is that we're getting permission denial; it would not be a trivial patch to libdbus to try connecting to a bus but then fall back after that instead of just noticing the environment variable isn't set.

Maybe a easier patch would put the uid in the environment variable; if it's not what we expect we ignore it.

Also do note the auto-spawning feature is really a terrible hack. If you run two different copies of gedit from two terminal tabs for example, you will get two session bus instances. That in turn means two instances of gconfd, which will happily stomp over each other's files in ~/.gconf.

In Fedora we are trying very hard to get rid of legacy usage of X applications running as root for this and a long list of other reasons.

[Dar (darren-kenny)]

I understand that unsetting the environment variable is a work-around, and it's looking like we will need to use for now, but it would seem to make sense that d-bus needs a way to auto-launch yet avoid lots of instances for the same user, I feel that this is going to become even more important if GConf is going to totally move to using D-Bus as it's IPC mechanism.

As I understand the way that d-bus locates it's service, it does one of the following:

1) Look for DBUS_SESSION_BUS_ADDRESS

2) Look for an XAtom

3) Look for address in a file in ${HOME}/.dbus/sessionbus

If we do auto launch then shouldn't we try to avoid that there is more than one for any given user, i.e. re-use an existing session if it exists?

I actually think that this is not unique to GConf, it's just that GConf is highlighting it now.

On OpenSolaris we have to also contend with applications that get launched in a separate Zone, which is like a chroot environment but totally isolated all the way into the kernel - this presents issues too with apps that require D-Bus since Zones are not UI environments usually.

Again, while we could spawn a specific session bus, in a zone there is no X, so we would rely upon environment variables and/or the file in ${HOME} to locate an existing session bus.

What do you think?

[Colin Walters (walters)]

At the high level, the expectation is:

1 user id <-> 1 login session <-> 1 dbus-daemon instance <-> 1 X server

Any situation that deviates from this will at best cause weird behavior, at worst data loss or app failure.

Right now libdbus only looks for the DBUS_SESSION_BUS_ADDRESS variable. We don't try to talk to the X server because we didn't want libdbus to strictly depend on libX among other reasons. We don't use the filesystem because it will break in network $HOME situations.

I have a blog entry about this here:

http://cgwalters.livejournal.com/16885.html

> If we do auto launch then shouldn't we try to avoid that there is more than one
> for any given user, i.e. re-use an existing session if it exists?

I think that would make sense, but I don't see a good way to do it short of kernel support. Note if we enforce this in libdbus, we should also enforce one X server per uid.

Zones I think we basically want to treat the same way as full virtualization, i.e. this is the same as if you wanted to connect to your session from a remote machine, and the answer there is vino.

[Halton Huo (halton-huo)]

Created an attachment (id=19532)
trace for gconf-editor

Debug with dbus code, internal_bus_get() fails with timeout error.

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.

There must some other scenarios could generate this error message. So it is no use to check whether DBUS_SESSION_BUS_ADDRESS is belong to app-run user.

And from DBUS_SESSION_BUS_ADDRESS string itself, I do not see a way to get it's owner.

[Halton Huo (halton-huo)]

> > If we do auto launch then shouldn't we try to avoid that there is more than one
> > for any given user, i.e. re-use an existing session if it exists?
>
> I think that would make sense, but I don't see a good way to do it short of
> kernel support. Note if we enforce this in libdbus, we should also enforce one
> X server per uid.
>
> Zones I think we basically want to treat the same way as full virtualization,
> i.e. this is the same as if you wanted to connect to your session from a remote
> machine, and the answer there is vino.

I tried with 'su -', dbus-daemon is added one more after each 'su -' and 'gconf-editor'. I guess avoiding dup dbus-daemon is a different problem. Should I report another bug?

[Johnp-redhat (johnp-redhat)]

Spawning a new bus when you get a security denial is not the right way to go.
Having a UID embedded sounds like the sane way to do this. If it isn't the
same UID treat it as if it is unset. I don't know if this breaks the spec
though. The check would be done in the unix socket transport layer and the
socket name editing would be in dbus-launch or somewhere in the bus/ directory.
 We have the guid= we could also have a sessionuid= part. Patches welcome (I
would look at the GUID code to get an idea of how to write this).

BTW while D-Bus is not tied to X dbus-launch is and will store the address in X
if an X connection is present when autolaunching a bus.

Also per user buses have been discussed at length and been rejected because of lifecycle issues. Please read the archives on the mailing list. If GConf needs to be per user it has to do that itself.

[Brian-cameron-oracle (brian-cameron-oracle)]

Created an attachment (id=19543)
See comment.

I realize that the best way to fix this is probably to add the uid to the DBUS_SESSION_BUS_ADDRESS environment variable, as has been suggested. However, we need to fix this issue in the short-term or else we will get a lot of people complaining about the regressions, and we only have a few days to get some sort of fix into the next release.

So, I patched GConf so that if the call to gconf_activate_server failed it would unset DBUS_SESSION_BUS_ADDRESS and try again. However, this still failed with GConf complaining that it couldn't connect to the same temp file as specified by the environment variable before it was unset. This confused me for a while.

I figured out that this is because D-Bus caches the bus_connection_addresses, and there doesn't seem to be any interface to uninitialize D-Bus so you can try again like I was trying to do in GConf.

The attached patch modifies internal_bus_get in dbus-bus.c so that if dbus_connection_open fails *and* if bus_connection-addresses was not initialized when the function was called, then it will uninitialize the bus_connection_addresses by calling addresses_shutdown_func. This is, I'm sure, a hacky way to workaround the problem. However, it does seem that D-Bus shouldn't cache the connection information if it fails to startup. Otherwise, how can the calling program try again with different connection info?

Or, it might be better if D-Bus just offered a public interface to tell D-Bus that the calling program wants to try to start up D-Bus again a second time but with different connection information (e.g. by messing with unsetting DBUS_SESSION_BUS_ADDRESS or something), and that would just uninitialize things.
Then GConf could call that function before trying again.

While this doesn't really fix the problem as elegantly as fixing the environment variable to contain uid information, it does seem that D-Bus should offer an interface to allow calling programs to try again if they want (either by D-Bus automatically not caching on initial failure as this patch tries to do, or by providing a public interface to clear the cache). So I think this issue should also be fixed regardless of how we fix the long-term issue of how to run programs which require GConf to run via su.

Thoughts? Any suggestions on a better way to do this?

[Brian-cameron-oracle (brian-cameron-oracle)]

Created an attachment (id=19544)
GConf patch for reference

For reference, here is the patch for GConf which solves the problem assuming the D-Bus patch in my last comment has also been applied.

[Brian-cameron-oracle (brian-cameron-oracle)]

Since people have suggested that this should be fixed in GConf, I also filed GConf bug #555745 so the GConf team can get involved.

   http://bugzilla.gnome.org/show_bug.cgi?id=555745

[Colin Walters (walters)]

Brian - libdbus does offer such an interface: dbus_bus_get_private. But again we really don't want apps trying to work around this.

I'll try to cook up a patch this weekend to have libdbus put the uid in DBUS_SESSION_BUS_ADDRESS and ignore it on mismatch.

Did you guys consider patching pfexec?

We should keep in mind the big picture too about how the desktop should work and interact with things like pfexec/su. As I mentioned, Fedora is driving towards a more PolicyKit-type setup for most things; I think it would make sense for OpenSolaris to push for a similar architecture if not PolicyKit itself.

[Hp-pobox (hp-pobox)]

One question to ask; DBUS_SESSION_BUS_ADDRESS is modeled on DISPLAY and our answer to "how should it work?" has always been "just like DISPLAY"; so, how do the X server and DISPLAY work in your setup? The Correct Fix is probably for dbus to work in exactly the same way.

This is also the answer for ssh forwarding, etc.

I'm not sure I get how this is a bug; if you have DBUS_SESSION_BUS_ADDRESS set to the wrong value, that is just like setting a DISPLAY that you can't connect to. Don't do that then. I can't quite tell from the comments, but I think using "su -" would fix the problem, wouldn't it? That's what should be done if switching to a random user.

I mean, either you want a new login session with its own dbus, i.e. don't want DBUS_SESSION_BUS_ADDRESS; or you want to share the old login session so want to forward DISPLAY and DBUS_SESSION_BUS_ADDRESS, *and* you want to ensure the new session has the right cookies to authorize to the old display and dbus-daemon.

But I don't see how it's possibly correct to create a situation where DBUS_SESSION_BUS_ADDRESS are forwarded to the new session, *and* no cookies and auth are set up, so they don't work. Either forward the env variables and make them work, or don't forward them. Right? What am I missing?

[Johnp-redhat (johnp-redhat)]

I think the issue is that XAuth and D-Bus auth are two different systems so where su'ing to another user will allow an app to run as that user on the primary user's display, D-Bus will prevent the app from connecting to the primary user's session bus.

There are edge cases, however small, where the user wants to run an app using another user's configuration (for theming, permissions, remote access, etc.) but want to run on their display. Since configuration in GNOME apps are starting to require D-Bus applications can fail to start up in this configuration. G-Conf uses D-Bus to see if there are any other G-Conf instances in this session.

This is most likely a flaw in G-Conf but does in a round about way point to the issue of sessionless D-Bus requests, and what to do about them. Right now we orphan autostarted busses.

[Hp-pobox (hp-pobox)]

What I'm saying is basically that whenever xauth is forwarded to another user, the dbus auth needs to also be forwarded. These two should never be out of sync.

If not wanting to hack su or pam or whatever, one approach is to add an X-based auth mechanism to dbus (store a cookie on the X root window or something like that).

Adding crazy hacks here is probably going to end in tears. The only sane model is that the session is defined by dbus and X, and 1 bus goes with 1 X server ...

[Freedy (freedy)]

an added problem with su - is that programs can't communicate. For example login as "work" and su - test -c thunderbird results in tbird not being able to run the browser in response to a click on an url.

This is possible with su thunderbird.

This would seem to be another arguement for passing the session rather than dumping the inaccessible one and auto creating a new one.

My gut feeling is that there will be many such issues spouting from this well if it is implemented with hacky workarounds, as commented in #10 and #17

[Colin Walters (walters)]

I've changed my mind on this bug slightly - I'll now argue that what the session bus should be strongly tied to is $HOME, but the X server can vary.

(In reply to comment #17)
> What I'm saying is basically that whenever xauth is forwarded to another user,
> the dbus auth needs to also be forwarded. These two should never be out of
> sync.
>
> If not wanting to hack su or pam or whatever, one approach is to add an X-based
> auth mechanism to dbus (store a cookie on the X root window or something like
> that).
>
> Adding crazy hacks here is probably going to end in tears. The only sane model
> is that the session is defined by dbus and X, and 1 bus goes with 1 X server
> ...

What I'd say is that's the most obvious and well defined model. But let's consider what happens right now if you use "ssh -Y" to some server and run Firefox (and people do this). What happens today is that Firefox is able to connect to your X server, but when Firefox tries to access DBUS_BUS_SESSION, none exists, so libdbus auto-spawns one. This results in two session buses on two different machines, and one X server.

How *should* the ssh -Y case work? Do we say "don't do that"? Teach ssh how to forward dbus back to the local session? (Note this only works if running freedesktop on the client, if you're using one of those X-on-MS-Windows programs it will obviously fail.)

Now, I will argue that the ssh -Y use case is broken, and what we really want is something like VNC with client side fusion-type integration. However - we can't actively break the legacy behavior here. People expect "ssh -Y myserver firefox" to not break.

The other major case here is "sudo gedit", which is the original bug report. Here again, people expect this to work; we can't just say "don't do that". My suggestion is that we make this case match the ssh case by creating a second session bus (implemented by ignoring the existing DBUS_SESSION_BUS_ADDRESS because of a uid mismatch).

In both of these cases now, the session bus the application sees matches the machine $HOME is seen from, which I think is right.

[Colin Walters (walters)]

One other thing I wanted to mention here is that for non-local applications, metacity actually suffixes their title with "(on $hostname)". I think it should actually go further and have a differently-colored border to more strongly emphasize "This application is not local" with the implication that it may not behave as you might expect (for a variety of reasons, among them that it's not able to talk to the local session bus).

Similarly for applications run under sudo, especially for applications running as uid 0, metacity could draw e.g. a pulsing red border.

While this may sound like crack at first, remember that essentially only sysadmins (or people acting under the direction of one) are going to end up in either of these situations, so having a weird border a good thing, since something weird is going on.

[Pete Goodall (pgoodall)]

I cannot start gnome-terminal. If I open an xterm and start gnome-terminal from the command line, here is what I get:

$ gnome-terminal
Failed to contact the GConf daemon; exiting.

$ ps ax | grep gconf
 3956 pts/0 R+ 0:00 grep gconf
 6643 ? S 0:00 /usr/lib/pulseaudio/pulse/gconf-helper
 6647 ? S 0:06 /usr/lib/libgconf2-4/gconfd-2

This is in Jaunty Alpha 4 with all updates current as of 12 Feb.

[Pedro Villavicencio (pedro)]

is this still an issue? could you attach your ~/.xsession-errors file to the report? do you get the same with another new user created on your system? thanks you.

[Ubuntuxer (johannes-schw)]

The problem occurs just as sudo, without sudo it works well.

johannes@johannes-pc:~$ sudo gnome-terminal
[sudo] password for johannes:
Failed to contact the GConf daemon; exiting.

In the attachment you find my ~/.xsession-errors.

Jaunty with last updates

[[e-mail] (billw)]

I haven't been able to use the root terminal since my upgrade to jaunty
billw@kasimir:~$ sudo gnome-terminal
Failed to contact the GConf daemon; exiting.

[Pete Goodall (pgoodall)]

I am no longer seeing this issue. Afaict this is fixed.

[Ubuntuxer (johannes-schw)]

It still doesn't work for me.

[Mystique (mystique-x)]

does not work for me too

# gksudo gnome-terminal
Failed to contact the GConf daemon; exiting.

# gksudo synaptic
or
# gksudo nautilus

working.

wanna have the root-terminal menu-entry enabled, but does'n work

any solution?

[endeneu (dotsw)]

I also have this bug.UbuntuJauty,all last updates
Temporary solution $ gnome-terminal -e "sudo -i"

[Andreas Moog (ampelbein)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: http://bugzilla.gnome.org/show_bug.cgi?id=576346

[Gilles Teisseire (gilles-teisseire1)]

Hi!

Same for me on jaunty beta,

can't open gnome terminal as root

error message: "Failed to contact the GConf daemon; exiting."

[shevegen (shevegen)]

Have this issue also - anyone has an idea how to resolve it? Obviously gnome-terminal needs "something" from gconf, or expects it to run (in a special manner perhaps?)...hmm

[Stepan Roucka (rouckas)]

I confirm this bug with todays updates. It affects probably most of other GNOME programs. I tried epiphany, gnome-terminal, and update-manager and all of them fail, which makes them unusable over ssh. Is there some way to start the gconf manually?

[Hp-pobox (hp-pobox)]

> Now, I will argue that the ssh -Y use case is broken, and what we really want
> is something like VNC with client side fusion-type integration. However - we
> can't actively break the legacy behavior here. People expect "ssh -Y myserver
> firefox" to not break.

There are two ways I can think of to keep it from breaking:
* add a dbus transport that tunnels over X protocol
* have ssh and su forward the dbus connection also

Anything else simply will break. Having two sessions connected to the same X server is not tractable for app developers and gnome developers to get right. There's no coherent semantic to it, since supposedly single-instance things become unpredictably multi-instance, and portions of the desktop you want to talk to become impossible to contact.

autolaunch produces undefined, incoherent, undocumentable behavior. Nobody can explain how to write an app or a per-session desktop daemon that works correctly in all cases if dbus-daemons are launched at random.

Failing actually fixing it (using the X tunnel idea or fixing ssh), my preference is not to autolaunch, but to force people to manually set DBUS_SESSION_BUS_ADDRESS _or_ manually launch dbus-daemon; i.e. make people actually figure out what's going on and deal with it. Then they'll at least understand exactly how it breaks. Autolaunch gives this sort of "well, I'll try to automatically work, but won't really, then fail mysteriously" sort of behavior.

There was a time when ssh and su did not magically handle X forwarding either, and people had to manually set up DISPLAY, and we liked it. In the snow, etc.

[Colin Walters (walters)]

(In reply to comment #21)
>
> There are two ways I can think of to keep it from breaking:
> * add a dbus transport that tunnels over X protocol
> * have ssh and su forward the dbus connection also
>
> Anything else simply will break. Having two sessions connected to the same X
> server is not tractable for app developers and gnome developers to get right.
> There's no coherent semantic to it, since supposedly single-instance things
> become unpredictably multi-instance, and portions of the desktop you want to
> talk to become impossible to contact.

Keep in mind unintended consequences.

Let's say hypothetically that Firefox (correctly) grabbed a name on the session bus for uniqueness instead of using the X server as it does now.

If we turned on DBus forwarding over ssh when you specified -Y, then that would *break* the Firefox use case, because Firefox would now see the name on the session bus on the other machine, and just open the URL there and exit. Thus, the sysadmin couldn't download that tarball of mediawiki they were trying to.

Here's another one - we recently changed GConf to use DBus to lookup the IOR for various reasons. If we started forwarding the session bus, then all of a sudden "ssh -Y" launched apps would try to look up that IOR (something in /tmp) and *fail*, because obviously the CORBA socket is on a different machine.

I understand your original design was that the session bus matched the X server, but as I said before I've come to the perspective that there's a huge difference between X and DBus.

Namely, X is a display system. Everything around it is focused on display. Not that other things aren't wedged into it, but still. DBus on the other hand is for *entirely arbitrary* things. Preferences, power management, networking, etc. If we change how the DBus scoping works it affects everything. All DBus services have to be evaluated for behavior in this case.

A very common problem in all of these is going to be services which have an implicit dependency on a shared filesystem as well, as in the GConf case. Think for example of a "recent files" service which has a method like org.freedesktop.Recent.GetRecent(). Obviously that's going to be in terms of local files, which anything remote can't access.

So going back to the 3 key things:

1) X server
2) DBus
3) Filesystem (really kernel, let's skip the NFS insanity for the moment)

2) and 3) are both essentially arbitrary protocols where anything can happen. 1) has always been about display.

So my argument again is that the least confusing thing is that 1) is can vary, and 2) and 3) should come together.

The reason we don't just put the dbus socket as $HOME/.dbus to enforce this is simply to avoid breaking outright on NFS. But NFS is an application problem, not something DBus can solve.

[Hp-pobox (hp-pobox)]

Fair points, some thinking out loud.

Examples where you want dbus-daemon and X server to go together
===

Say the session manager has a "logging out now, please save files" signal. You want everything on the X server to get that signal.

Or say you have a "suppress screensaver" API. You need every app on the X server to be using the same one of those.

Or basically everything in gnome-settings-daemon (theme, font, etc.) has to be singleton to the X server.

Shared NFS, separate sessions as same user
===

One thing I'm assuming is that there's a shared NFS homedir. If you are running as a different *user* on the remote system, then the right thing may be to have a separate session on that remote system.

Two sessions on one X server is kind of a mess and hard to make work right, but if you're going to say it's allowed, then yeah it's two different dbus-daemon.

I guess it's logical that if you can have two sessions for *different* users sharing an X server, then two sessions for the *same* user has to work also. A difference here is that if we prohibit two sessions for the *same* user sharing an X server, then we can say that each dbus-daemon on the same X server will have its own separate home directory. Which is at least something.

Gconf
===

> Here's another one - we recently changed GConf to use DBus to lookup the IOR
> for various reasons. If we started forwarding the session bus, then all of a
> sudden "ssh -Y" launched apps would try to look up that IOR (something in /tmp)
> and *fail*, because obviously the CORBA socket is on a different machine.

Right, but this is just because gconf/CORBA are fucked up and not using dbus (you can, btw, enable tcp for orbit... not that it's advisable). If we weren't dealing with some nest of legacy corba crap, then what we'd want is that ssh -Y launched apps *do* use the original config daemon on the original machine - using dbus to locate that daemon and talk to it.

I'm OK with hacks to fix the legacy stuff, but not if they break doing it right eventually... so I think first you want the right way to work (that in fact you could share the config daemon for your whole session) and then second try to figure out some hack for this old gconf junk.

Firefox
===

> If we turned on DBus forwarding over ssh when you specified -Y, then that
> would
> *break* the Firefox use case, because Firefox would now see the name on the
> session bus on the other machine, and just open the URL there and exit. Thus,
> the sysadmin couldn't download that tarball of mediawiki they were trying to.

But sometimes what you want is that your existing firefox instance is used. Especially if the homedir is shared; then I can download the tarball from either machine and it's fine. But say I'm running email on one machine and firefox on the other, when I click a link in my email for it to do the right thing it has to open in firefox on the firefox machine.

Recent files
===

> A very common problem in all of these is going to be services which have an
> implicit dependency on a shared filesystem as well, as in the GConf case.
> Think for example of a "recent files" service which has a method like
> org.freedesktop.Recent.Get...

[Hp-pobox (hp-pobox)]

here's an idea: every session has to have its own (potentially rootless) X server. So basically to have a separate session for root or on a remote machine you have to run either xephyr or vnc or vmware or xen or a rootless X server.

That would make it a lot easier to get apps right (at the expense of having to implement the rootless X server).

[Peter Cordes (peter-cordes)]

I noticed this problem because my .fluxbox/startup wasn't starting my gnome-terminal anymore. (that's a shell script run by startfluxbox that runs some X clients then execs /usr/bin/fluxbox. I put some of my startup stuff in it.)

 If I run
/usr/bin/gnome-settings-daemon &
before gnome-terminal, then it works. If I leave that commented out, gnome-terminal refuses to start, with the "Failed to contact the GConf daemon; exiting." error message everyone's reporting. Obviously when gnome-terminal is run as root, there's no root-owned gconf daemon for it to talk to. (BTW, why would you want to do that? sudo -s not good enough?)

 I already had /usr/bin/gnome-settings-daemon in my fluxbox startup, but I used to run it as

gnome-terminal --geometry=132x30 --tab-with-profile=default --tab-with-profile=default --tab-with-profile=default &
(sleep 1 && setxkbmap -option ctrl:nocaps && xset r rate 195 60 && /usr/bin/gnome-settings-daemon ) &

 I use sleep to spread out the disk I/O load of starting X a bit. gnome-terminal used to load, then after gnome-settings-daemon loaded, the font would switch to my configured font. But now my desktop was coming up with no terminal. gnome-terminal would work later, since by then gnome-settings-daemon would be started.

 So now I do
/usr/bin/gnome-settings-daemon &
(sleep 1 && gnome-terminal --geometry=132x30 --tab-with-profile=default --tab-with-profile=default --tab-with-profile=default & )
(sleep 1 && setxkbmap -option ctrl:nocaps && xset r rate 195 60 )&

 and my X startup script should start everything nicely.

 If gnome stuff is going to require daemons, they should start them automatically if they're not running. KDE stuff does that. If GNOME can come up with a convincing reason why this is a bad idea, then this is not a bug. Although it had better be documented, and the error message should suggest starting gnome-settings-daemon. So IMHO something has to change before this bug can be closed.

[Peter Cordes (peter-cordes)]

forgot to say that this is maybe not gconf2's bug, but rather a bug in things that use it. (esp. if the fix is a more useful error message.)

[Maxim Levitsky (maximlevitsky)]

Affects me too.
Jaunty with all updates

[Paolo Benvenuto (donpaolo)]

Jaunty beta.

affects me too, both if I run it with sudo and if I run it remotely with ssh:

$ sudo gnome-terminal
[sudo] password for paolo:
Failed to contact the GConf daemon; exiting.

$ ssh -Yf paolo gnome-terminal
paolo@paolo's password:
paolo@parroco:~$ Failed to contact the GConf daemon; exiting.

Notably the issue is only with gnome-terminal. All other applications run well in both situations.

Also when local pc = intrepid, remote = jaunty : running gnome-terminal with ssh => the same error

[Scholli (schollidesign)]

Can put somebody this bug as medium-importance? It's a very nerving bug! Thx

[Colin Walters (walters)]

(In reply to comment #23)

> One thing I'm assuming is that there's a shared NFS homedir.

Not applicable in the two major cases of:

* ssh -Y sysadmin from laptop to server
* su -

I'm not saying there aren't cases where the homedir is shared, but there are important cases where it isn't.

Anyways a lot to think about here, let me just dump some random thoughts:

* Not a big fan of requiring a rootless X server; admittedly in reality for the next 10+ years we'll need X on the free desktop, there does exist a wayland future ideally

* NFS home directories are always going to be last-one-wins "eat my data please" semantics, unfixably broken

* One *huge* wrench in any plans we have when discussing making remoting scenarios better (ssh etc.) is the possibility of different versions of dbus/X/ssh. In reality people are going to be running slow-releasing OSes like RHEL5 on servers for many years to come. And developers/sysadmins are likely going to be running faster-releasing OSes on their laptops. If for example we fix libgconf to be a special case in any way, that doesn't help because the machine-running-libgconf (client in X terms, RHEL5 server) isn't going to have it.

* In general, this kind of thing is always going to be broken in some way. We have enough problems with the regular desktop case as is. I think the focus should be on compatibility (don't break what worked before like "ssh -Y server firefox" to download stuff on the server), and flexibility (let apps make choices).

Anyways I'll try to evaluate your possible scenarios soon.

[Removed by request (stoni.ch-deactivatedaccount)]

Hello Folks,
I just encountered this problem during LiveCD Building with Ubuntu Customization Kit. I used Xubuntu CD image as base so far, always worked well - now with 9.04 rc / Ubuntu Edition this problem comes when selecting 'run console'. If unsolved, LiveCD building with UCK is jeopardized, unless the scripts get patched with a workaround as mentioned above. Will dive deeper now, just fyi. Regards, Daniel

[Hp-pobox (hp-pobox)]

> In general, this kind of thing is always going to be broken in some way.

Agreed; the bottom line for me though is that we don't want to run around in circles. It's just like the old X clipboards stuff; app A worked around app B and app B worked around A at the same time, and then they were both broken again, and had to toggle back to work around the other, and then they were both broken again...

So if there's a tradeoff where scenario such-and-such works and some other one does not, there should be a document that just says: we've agreed to change ssh, X, dbus, distribution defaults, gconfd, apps, session manager, settings daemon, etc. to support such-and-such, and this other scenario abc we've agreed to not care about.

And then when the bug reports come in for abc that's been traded off and punted, we can just point to the writeup document and WONTFIX because we want to keep the such-and-such scenario working and that requires that abc does not work.

> I think the focus
> should be on compatibility (don't break what worked before like "ssh -Y server
> firefox" to download stuff on the server), and flexibility (let apps make
> choices).

"ssh -Y server firefox" more just happens to work ... it isn't really defined _why_ it works and what the desktop has to do to make it keep working. Picking the "why" for how it keeps working is what will determine which other scenarios work or break. In the short term, ssh -Y server firefox can probably keep working regardless, the question is what else breaks given the "why", or which desktop features firefox might start to rely on that might break "ssh -Y server firefox" inadvertently... gconf being a great example.

> * Not a big fan of requiring a rootless X server; admittedly in reality for
> the next 10+ years we'll need X on the free desktop, there does exist a
> wayland future ideally

Wayland could theoretically design-in a solution, who knows. The possible win of rootless X is that you could avoid any tricky stuff for apps to get right, and keep the app-visible model very simple (and virtualization-compatible...).
A second X server, whether nested or rootless, or VNC for that matter, is the direct analog of opening a new terminal session on a remote server. Opening just one app on an existing X session is kind of like running something on a remote server and having it be a job in your local shell. If that melts your mind, that's the problem created by letting "ssh -Y server firefox" work.

The big appeal I think is to be able to solve one problem (a nice way to open a nested display or VM) instead of fixing N apps.

Anyway, to stay on topic for dbus, re-reading the original bug topic...

You said only this can be expected to work reliably:
1 user id <-> 1 login session <-> 1 dbus-daemon instance <-> 1 X server

And I think that is pretty much the de facto situation, that's all that's going to work all the time without screwing around, because there's no agreed-upon way that anything else does work or doesn't. There's some real spec work and thinking to be done about other situations that could work. I think maybe they could, and maybe there are related dbus changes, but who knows what those ...

[Hp-pobox (hp-pobox)]

Another possible solution is an X11 transport for dbus, btw. Which allows 1 X server to 1 dbus always, even without ssh or su changes.

The only trick at that point is that stuff on the same X server and dbus-daemon doesn't have to share a home directory.

I guess this is an implementation of "Possible direction 2" from comment 23, but without having to modify ssh or su.

"Possible direction 2" is the least amount of work to get to a solution that is reasonably well-defined and functional, perhaps. But it means killing off autolaunch...

[Matt (matt-wintergarden)]

I'm having the same error.

I'm running Ubuntu 9.04 final.

$ sudo gnome-terminal
Failed to contact the GConf daemon; exiting.

[Peter Cordes (peter-cordes)]

Thanks to everyone for confirming that this happens under normal circumstances. No further confirmation is required. Just subscribe to the bug without making a post, unless you have anything new to add. (Correct me if I'm overstepping here, Ubuntu maintainers.)

 Further posts on this thread should be about what to do about this, or ideas for how the relevant programs and libraries should behave so gnome-terminal can start when gnome-settings-daemon isn't already running.

 I've always found it kind of messy the way KDE programs start daemons that clutter your terminal with log messages even after the first KDE program (that started them) has exitted. If it wasn't for the messages on stdout or stderr, it wouldn't be so bad. Obviously, you don't want to hide the messages either, so I don't really see any good solution. I guess it's something you get used to as a user, though. I start most of my long-lived GUI stuff from one screen(1) window, so only one window will get clogged with messages if any of them feel like spewing. So it would probably work to start any required daemons when they're needed.

  I don't see any obvious solution, if there's no way around requiring a daemon. Hmm, possibly if there's no daemon, read settings from a file yourself? Using the same code (in a library) that the daemon uses to get the settings? This might have to be read-only to avoid danger in case the daemon does start while gnome-terminal is running...

[Maxim Levitsky (maximlevitsky)]

gnome-settings-daemon doesn't help:

I do:

# sudo -i
$ gnome-settings-daemon &
$ gnome-terminal

and it still fails with same message

It did work fine in 8.10
Now I can't open it nether from root nautilus or from remote share
and can't open like I said above

[Jim10 (g-van-zweeden)]

Copy of my posting in "Bug #326158 in Ubuntu:
============================

As far as I 'm concerned it's not a big issue, a (temporary?) solution is simple. Add a starter to the taskbar (or your menu) with:

gnome-terminal -e "sudo -i"

and the terminal starts immediately asking for your password. As long as you keep that terminal open you will have root-permissions in it.

Gr,
Jim

[Maxim Levitsky (maximlevitsky)]

@Jim, this isn't what makes it fail.
The problem is that if I launch nautilus as root, I can't open terminal from it.

I strongly suspect this bug prevents above from working

[Maxim Levitsky (maximlevitsky)]

I did some brief look, and discovered a workaround, or maybe even a fix:

The message you see comes from gnome-terminal, but it can work fine without gconf, or maybe check for it is broken:

in terminal.c:

  /* If the gconf daemon isn't available (e.g. because there's no dbus
   * session bus running), we'd crash later on. Tell the user about it
   * now, and exit. See bug #561663.
   */
  if (!gconf_ping_daemon ())
    {
      g_printerr ("Failed to contact the GConf daemon; exiting.\n");
      exit (1);
    }

If I comment out this condition block, then it works just fine

[Jim10 (g-van-zweeden)]

Maxim Levitsky wrote:
QUOTE: @Jim, this isn't what makes it fail.
The problem is that if I launch nautilus as root, I can't open terminal from it.

Do'nt understand that, opening a terminal from within nautilus?

But OK, I do understand that the real problem must be some bug in the gconf deamon so we will wait for the solution of that I suppose.

Gr,
Jim

[Zaeggu (zaeggu)]

Same problem, "gksu gnome-terminal" and "sudo gnome-terminal" not start the Terminal!

"gnome-terminal" is ready for use the Terminal!

Fix this Bug Please!!!!!!!

[Brian J. Murrell (brian-interlinx)]

Aw crap! Now I'm going to have to go back to Intrepid. Not being able to open a gnome-terminal over an ssh connection is a show stopper for me!

~sigh~ It's been too long now since I have been able to do a Ubuntu upgrade and everything just works as well as it did before the "upgrade".

Please fix this ASAP.

[Roman Polach (rpolach)]

I also have this problem:
gksu /usr/bin/x-terminal-emulator ...does not work, displays "Failed to contact the GConf daemon"
/usr/bin/x-terminal-emulator ...works ok
gksu gedit ...works ok

[Russel Winder (russel)]

Having just upgraded to Jaunty from Intrepid, I have arrived at this "cannot do 'gksu gnome-terminal'" bug. How did this happen? What change was made Intrepid -> Jaunty that broke this oft used (even if some people consider it the wrong thing to do) feature? I really am not looking for workarounds, I am looking for this not to have been broken in the first place.

This problem has clearly been known about since the beginning of this year and still Jaunty was released with the bug for us unsuspecting people to get hit by.

This really does need to be considered as a security bug and fixed asap: the whole point of using this idiom is that it requires the password and it gives a new type of terminal so that it can be coloured differently from other terminals to show it is a dangerous terminal.

[Adam Yao (adam-yao)]

This bug affects more applications. please fix it asap.

[JimmyJimJames (jimmyjimjames)]

I just upgraded to Ubuntu 9.10 on two machines and both exhibit the same problem when attempting to open a root terminal via the built in gksu command.

The suggestion to use:
   gnome-terminal -e "sudo -i"
is not sufficient for me, as I defined a different default profile for the root user which has a different text color (to visually differentiate a normal terminal from a su terminal) and the root profile is not loaded using this workaround.

Very annoying that a built in option like "Root terminal" was broken by the 9.10 upgrade....

[Pibo (paibotm)]

@ Adam Yao:
could you please be more specific? Are you meaning that you've found some applications other than the root terminal which undergo this GConf's issue, or that the fact the terminal is unusable affects other activities of yours? Or maybe referring to something you read on other pages about this same bug? Just to know.
Thanks :)

[Brian J. Murrell (brian-interlinx)]

On Wed, 2009-04-29 at 13:39 +0000, Pibo wrote:
> @ Adam Yao:
> could you please be more specific? Are you meaning that you've found some applications other than the root terminal which undergo this GConf's issue, or that the fact the terminal is unusable affects other activities of yours? Or maybe referring to something you read on other pages about this same bug? Just to know.

The problem is that this affects way more than just gksu gnome-terminal.
It also makes it impossible to do:

$ ssh -Y jaunty_system gnome-terminal

As you can see, where I may launch 12 other terminals or tabs (i.e. from
the New Terminal/Tab menu options) from that one gnome-terminal, using
12 or more ssh -Y commands is simply an unacceptable work-around. I
want the functionality of the gnome-terminal on the remote machine, not
on my local machine.

[bjd (bjd-xs4all)]

Been following these comments -- all the while finding myself more and more
dumbfounded. This bug is over two months old.

Never mind the new notification system -- people want to get some serious
work done and here's some essential functionality that, well..... isn't functioning.

There's another bug there: how could a much anticipated release make it out the
door, even with this fundamental breakage already having been reported?

bjd

[Maxim Levitsky (maximlevitsky)]

While I agree with most of stuff said here, lets not turn this bug into a flame war.

I want to repeat myself, that commenting out this:

in terminal.c:

  /* If the gconf daemon isn't available (e.g. because there's no dbus
   * session bus running), we'd crash later on. Tell the user about it
   * now, and exit. See bug #561663.
   */
  if (!gconf_ping_daemon ())
    {
      g_printerr ("Failed to contact the GConf daemon; exiting.\n");
      exit (1);
    }

made it work for me

[Brian J. Murrell (brian-interlinx)]

On Wed, 2009-04-29 at 17:44 +0000, bjd wrote:
> Been following these comments -- all the while finding myself more and more
> dumbfounded. This bug is over two months old.

More and more bugs lately seem to befall this fate sadly, of just
lingering on and on and nothing being done.

> There's another bug there: how could a much anticipated release make it out the
> door, even with this fundamental breakage already having been reported?

Because "it was time". Sadly, in this day and age, releases are made
based on squares on a calendar, not on suitability of release. To be
sure, much work is put into trying to make the release stable by the
time that square on the calendar comes up but it doesn't always happen.
The square comes and the release has to be made.

While this does not seem to have been a problem in the past, the past
couple of releases of both Ubuntu and evolution seem to have fallen
victim to "it's time" and not "it's ready". Hopefully this changes in
that the release date is allowed to slip or more hands are put into
getting it ready by that release date or less ambitious are set for
releases.

It's one of those old "pick two" songs. In this case the three choices
are "on time", "feature packed", "stable". Pick two.

b.

[Andrew (andrew-rw-robinson)]

I do not see how commenting that out is a good idea if that comment is
correct. Instead, it appears to me to be a bug in the
gconf_ping_daemon. If the gnome-terminal can run just fine under sudo,
then the gconf_ping_daemon should be using the actual user ID, not the
effective user ID to try to get the running gconf process.

Since I know for a fact that I am running X and GConf is accessible,
then this function does not appear to be detecting the daemon
correctly.

[Sebastien Bacher (seb128)]

the best way to get that bug worked would be to opened a bug against the concerned software to the software writters on bugzilla.gnome.org, ubuntu only distribute it, the quality comments are not useful, the usecase described there is just not the most common one and technical users having the issue should be able to help and send that to GNOME early

[bjd (bjd-xs4all)]

With all due respect Sebastien -- I can hardly believe that
I'm reading this: "ubuntu only distribute it".

(why even have a bug reporting system in the first place,
one wonders, btw.).

[Russel Winder (russel)]

Sebastien, your comment seems to imply that Launchpad bug reports are a waste of time. Is this really what you meant? I had been under the impression that Launchpad was intended to be a gateway/portal for bug reporting. If Launchpad reports do not get forwarded upstream automatically once triaged then what purpose does it have?

[Maxim Levitsky (maximlevitsky)]

For some sense that seems to be true, I often find out that reporting bugs upstream is better.

Yet, this also usually doesn't help, bugs just remain in bugzilla, and nobody fixes them.

Thus the only way to fix the bugs is just grok the code, and fix them up myself.
(No matter how hard that is)

This bug is an exception, as the 'real' fix for it might involve some big changes in way root applications are handled

There is nothing wrong with the above, linux just has few users and developers, and I feel that majority of linux users, just use it because they have to for one or another reason, and will thus use it as little as possible (eg run in VM, try cygwin, bring own laptop with windows, as a backup, etc...)

This is sad.

[Sebastien Bacher (seb128)]

> your comment seems to imply that Launchpad bug reports are a waste of time. Is this really what you meant? I had been under the impression that Launchpad was intended to be a gateway/portal for bug reporting. If Launchpad reports do not get forwarded upstream automatically once triaged then what purpose does it have?

No, the issue is just that the number of bug reports and issues is just high for the team working on those so it might take some time to get issues triaged, confirmed, sent upstream etc. If you know what you are doing you are welcome to speed the process by sending the bug upstream too rather than waiting on overworked triagers to pick it for you

[OlivierS (olivier-olivier)]

The problem is that there is no session-dbus. The following lines of shell code start a session dbus, start gconfd and start the gnome-terminal

#!/bin/sh
eval 'dbus-launch --sh-syntax --exit-with-session'
/usr/lib/libgconf2-4/gconfd-2&
gnome-terminal

add it to a script, and start the script.

[Arnaldo Mandel (am-ime)]

I didn't work, until I caught on the typo (ticks instead of backticks). Here is the corrected script:

#!/bin/sh
eval `dbus-launch --sh-syntax --exit-with-session`
/usr/lib/libgconf2-4/gconfd-2&
gnome-terminal

Now it does indeed work. I can gksudo this script and can also invoke it remotely.

[Maxim Levitsky (maximlevitsky)]

Indeed.

as a workaround one can create /usr/local/bin/gnome-terminal with the above code:

#!/bin/bash

if [ "$EUID" = "0" ] ; then

 eval `dbus-launch --sh-syntax --exit-with-session`
 /usr/lib/libgconf2-4/gconfd-2&
fi

exec /usr/bin/gnome-terminal $*

[Maxim Levitsky (maximlevitsky)]

What is 'interesting' is that I don't see any gnome program except gnome-terminal that needs that workaround

[Maxim Levitsky (maximlevitsky)]

Thus I still thing gnome-terminal should work without gconf

[Stepan Roucka (rouckas)]

> What is 'interesting' is that I don't see any gnome program
> except gnome-terminal that needs that workaround

In case of running programs over ssh, every gnome program that I
tried is affected by this bug. For example nautilus:
$ nautilus

(nautilus:8367): Eel-WARNING **: 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: Failed to connect to socket /tmp/dbus-SmPGlbnjCX: Connection refused)

(nautilus:8367): Eel-WARNING **: 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: Failed to connect to socket /tmp/dbus-68o2xY0A4a: Connection refused)
GConf warning: failure listing pairs in `/apps/nautilus/preferences': 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: Failed to connect to socket /tmp/dbus-653EukrRMz: Connection refused)GConf warning: failure listing pairs in `/desktop/gnome/file_views': 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: Failed to connect to socket /tmp/dbus-7PdDqACLDB: Connection refused)GConf warning: failure listing pairs in `/apps/nautilus/desktop': 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: Failed to connect to socket /tmp/dbus-v4zT60f1OD: Connection refused)GConf warning: failure listing pairs in `/apps/nautilus/icon_view': 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: Failed to connect to socket /tmp/dbus-W31BvrdFGB: Connection refused)

[etc... and crash]

$ gnome-calculator
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: Failed to connect to socket /tmp/dbus-XL6x5ZWna8: Connection refused)

[etc... and crash]

I remeber that i tested also epiphany and update-manager, neither of them works without the above
...

[MaskedMarauder (edstrom-teleport)]

I'm just re-confirming the same problem with today's latest updates (May 6, 2009).

I only run *UBUNTUs now. I'm curious if this bug has cropped up on other distributions, eg RedHat, Suse, etc., or is it just in the UBUNTU family? If it isn't general then maybe its a *UBUNTU configuration quirk.

[Alwin Roosen (info-alwinroosen)]

I have the same problem after upgrade from Intrepid to Jaunty.

I don't know of this is information is useful, but i experience this issue problem trying to start gnome-terminal from /etc/gdm/PostSession/Default. This script is run when the user logs out of the system. In Intrepid, a terminal pops out in front of the user, but it does nothing in Jaunty. The terminal does not start, and I get this very same error.

What I don't understand is that the very same command works perfectly when started from /etc/gdm/PostLogin/Default. This script is run right after user logon.

And when i try to run it between logon and logoff, manually from terminal, it also works.

I tried the suggested workaround which seems to solve the problem when executed from /etc/gdm/PostSession/Default

[Aviv (ademorga)]

Let me be more accurate here. Gnome-terminal works fine, *ONLY* root terminal
fails (gksu /usr/bin/x-terminal-emulator fails to execute). Hence, GConf may be
error-free in this case.

Quoting Maxim Levitsky <email address hidden>:

> Thus I still thing gnome-terminal should work without gconf
>
> --
> Cannot start gnome-terminal because of gconf error
> https://bugs.launchpad.net/bugs/328575
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

------------------------------------------------------------------------
This message was sent using IMP, the Webmail Program of Haifa University

[Aviv (ademorga)]

Let me be more accurate here. Gnome-terminal works fine, *ONLY* root terminal
fails (gksu /usr/bin/x-terminal-emulator fails to execute). Hence, GConf may be
error-free in this case.

Quoting Alwin Roosen <email address hidden>:

> I have the same problem after upgrade from Intrepid to Jaunty.
>
> I don't know of this is information is useful, but i experience this
> issue problem trying to start gnome-terminal from
> /etc/gdm/PostSession/Default. This script is run when the user logs out
> of the system. In Intrepid, a terminal pops out in front of the user,
> but it does nothing in Jaunty. The terminal does not start, and I get
> this very same error.
>
> What I don't understand is that the very same command works perfectly
> when started from /etc/gdm/PostLogin/Default. This script is run right
> after user logon.
>
> And when i try to run it between logon and logoff, manually from
> terminal, it also works.
>
> I tried the suggested workaround which seems to solve the problem when
> executed from /etc/gdm/PostSession/Default
>
> --
> Cannot start gnome-terminal because of gconf error
> https://bugs.launchpad.net/bugs/328575
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

------------------------------------------------------------------------
This message was sent using IMP, the Webmail Program of Haifa University

[Alexey Balmashnov (a.balmashnov)]

Aviv here is some clarification:
$ ls -l /usr/bin/x-terminal-emulator
lrwxrwxrwx 1 root root 37 2009-04-27 14:01 /usr/bin/x-terminal-emulator -> /etc/alternatives/x-terminal-emulator
$ ls -l /etc/alternatives/x-terminal-emulator
lrwxrwxrwx 1 root root 31 2009-04-27 14:00 /etc/alternatives/x-terminal-emulator -> /usr/bin/gnome-terminal.wrapper

[BlueSky (bluesky)]

> I'm just re-confirming the same problem with today's latest updates (May 6, 2009).
>
> I only run *UBUNTUs now. I'm curious if this bug has cropped up on other distributions, eg RedHat, Suse, etc., or is it > just in the UBUNTU family? If it isn't general then maybe its a *UBUNTU configuration quirk.

Heya, just got there from Google, I report that I have the same problem under Gentoo, from updates today.

I am aware it's not the place to report Gentoo bugs, just letting you know you're not the only ones having the bug.

[notelopuedesimaginar (notelopuedesimaginar)]

Still happening here with 9.04 and all the updates.

I can confirm that it only keeps me from running a new gnome-terminal from the root account, users can. I can run other graphical shells like konsole or xterm with no trouble.

[Andy (abarrett79)]

I'm having this gconf error from a regular account. I use fluxbox. Here's the command throwing the error.

x-terminal-emulator -T "Bash" -e /bin/bash --login

This issue seems to resolve itself after some usage. I suspect gphpedit fires up the gonf daemon properly. I like to fire up my terminals immediately after login though, and dropping to a text terminal (ctrl-alt-F1) to fire up a terminal is really annoying. I'm not knowledgeable about EUIDs or some of the other crazy stuff above, but I think they are related to the root user, which is not what I'm trying to use. I just want to open a terminal! And I'd rather not change the terminal I'm used to.

The main purpose of this message is to point out that this is NOT just a su issue.

[Peter Cordes (peter-cordes)]

> The main purpose of this message is to point out that this is NOT just a su issue.

 Right, it's an X11-without-gconf issue. See my post, above, for my workaround for fluxbox. Like you, I use fluxbox and gnome-terminal. It's a simple matter of getting gconf running. I do it by running gnome-settings-daemon in my .fluxbox/startup. (startx does start DBUS, so gnome stuff can find itself once started.)

BTW, ctrl-alt-f1 is not the simplest way. There are other viable terminal emulators you can start from the menu: Applications->Terminal Emulators->anything but gnome terminal. If you don't have any others installed,
aptitude install xterm
It's not very nice, but it works well as a failsafe.

 Or start any other GUI program that lets you run shell commands. e.g. emacs, and M-x shell.
(and start gnome-settings-daemon that way.)

[BlueSky (bluesky)]

Huh.. no it's not okay to turn it into a guide.. People have been using gnome-terminal as root for years. Lecturing them on the dangerousity of their ways is just an excuse not to fix the bug.

I do not mean to attack you personally, but I just hate it when people say "why do you do that anyway?" or "it's much better if you do it the other way" when there is a real bug.

While I understand Ubuntu is targeted at the general public (including very, very dumb users), well not only dumb users use it, I guess. Those should have the freedom to launch gnome-terminal as root, knowing and accepting the risk.

As for me, I have turned to x11-terms/terminal (gentoo package terminology), which is the xfce terminal emulator. It has nearly all features from gnome-terminal, without the wont-launch-as-root bug. But I seriously hope this bug is fixed upstream in gnome-terminal.

Additionally, running gnome-settings-daemon is not always an acceptable workaround, since it messes up with gtk+ themes, desktop background, etc. Gnome is a trustworthy partner, but an invasive ex. (ie. when you just want to "stay friends" = just run gnome applications)

As a conclusion, well, I guess a guide is better than nothing. Thanks for that effort already.

[Peter Cordes (peter-cordes)]

BlueSky wrote:
> Lecturing them on the dangerousity of their ways is just an excuse not to fix the bug.

> I do not mean to attack you personally, but I just hate it when people say "why do you do that anyway?" or
> "it's much better if you do it the other way" when there is a real bug.

 Thanks for the comments. You're right, I went way overboard with the lectures against running too much as root, when all that was called for in that space was workarounds that would let people do the things they wanted to. I see how that would give the impression that it's actually the user's fault, not a bug (which is not the case.)

 I've tried to make it more clear that this should be considered a bug. e.g. "Workarounds:" ->
"Workarounds to use until the bugs are fixed:". Although I did already try to make it clear that this is still a bug, not just simply the new way that GNOME works. OTOH, unless gnome-terminal will just work without gconf, this bug will probably take a long time to get fixed, since it's the result of the design, not just a problem implementing it correctly. That's what I was trying to make clear, and prepare people for a long wait.

 It's true that my "workarounds" for root and remote usage cases are what I do anyway, and I do in fact consider them better than actually running gnome-terminal as root, or remote-displaying it. That's what makes them such great workarounds... (esp. since I'm a command line guy, and I always have gnome-terminal open, and usually have a shell already cd'ed to whatever directory I want to do something in... This is not the case for everybody, e.g. the people who want to start a shell from nautilus. That's fine, use your computer however you want, as long as it's not a security disaster that's going to have your computer infected and trying to crack mine and relaying spam.) Without the big lecture, I'm probably less likely to put people off actually trying anything I suggested.

> running gnome-settings-daemon is not always an acceptable workaround, since it messes up with gtk+ themes, desktop background, etc

 Isn't it just providing settings that were configured when you still used GNOME? If you had an empty ~/.gnome* and ~/.gconf*, wouldn't you get the same defaults as when gconfd isn't running at all? (try moving those directories aside before deleting them). I guess really you just need gconfd, which is started by gnome-settings-daemon. Does running
/usr/lib/libgconf2-4/gconfd-2&
change your themes and fonts? Or only g-s-d? If it's ok, then you could update the workaround to suggest just that, instead of g-s-d.

[BlueSky (bluesky)]

> I've tried to make it more clear that this should be considered a bug.
I am very pleased: I didn't expect a positive/constructive reaction. This is great work, now it's up to gnome/gconf developers.

> Isn't it just providing settings that were configured when you still used GNOME?
I never used GNOME on this installation =)

> If you had an empty ~/.gnome* and ~/.gconf*, wouldn't you get the same defaults as when gconfd isn't running at all? (try moving those directories aside before deleting them).
I had ".gnome2" and ".gnome2_private" directories in ~/, which I renamed before running gnome-settings-daemon. Didn't change anything, gnome-settings-daemon is still taking over.
Moreover, my custom Openbox key bindings for XF86AudioPrev, XF86AudioNext, etc. don't work anymore once gnome-settings-daemon has been launched (even after g-s-d is killed).

> I guess really you just need gconfd, which is started by gnome-settings-daemon. Does running
> /usr/lib/libgconf2-4/gconfd-2&
> change your themes and fonts? Or only g-s-d? If it's ok, then you could update the workaround to suggest just that, instead of g-s-d.
Running this doesn't change anything, and, in fact, it exits immediately :
------------------
tsubaka ~ # /usr/libexec/gconfd-2&
[1] 12114
tsubaka ~ # (press enter)
[1]+ Exit 1 /usr/libexec/gconfd-2
tsubaka ~ #
------------------

Olivier Sessink provided a working way to launch gconfd-2 and then gnome-terminal, as root ( https://bugs.launchpad.net/ubuntu/+source/gconf2/+bug/328575/comments/42 ):
>The problem is that there is no session-dbus. The following lines of shell code
> start a session dbus, start gconfd and start the gnome-terminal
>
> #!/bin/sh
> eval 'dbus-launch --sh-syntax --exit-with-session'
> /usr/lib/libgconf2-4/gconfd-2&
> gnome-terminal
>
> add it to a script, and start the script.

So in my case, it's a no-go for gnome-terminal, and I'm off using xfce's terminal emulator, which is just fine, and lightweight too =)

[Mike Heise (heisem)]

Thank you, whoever added the workaround guide to the bug description. It was concise and extremely helpful.

[HavocXphere (havocxphere)]

>What is 'interesting' is that I don't see any gnome program except gnome-terminal that needs that workaround
Not 100% convinced about this. I've had lots of "gksu nautilus" commands mysteriously failing lately (from ALT-F2). Exact same behaviour....requests password and then nothing. The annoying thing is that it happens randomly & I can't duplicate it right now. :(

Might just be a co-incidence...but its been annoying me for some time now.

[Chris Coulson (chrisccoulson)]

franik4ever - have you got the link to the Debian bug report so it can be tracked here, seeing as you added the Debian task?

[Tom V (tvice)]

I just noticed this behavior in an update to Jaunty from Intrepid. If it is not a bug then it is a "feature" and should be in a change log somewhere. I liked being able to click on a root terminal icon, give it my password and be presented with a root terminal.
I guess I can just as easily su to root.

[Cory Davis (cory-d-davis)]

It's not explictly stated here, but this also occurs for other users than root (it's implict in the "doesn't work over
ssh" case).

For me, I run Ubuntu on my home PC with one user name, and have a separate user for my work environment, which I generally access with `su - other_user`. I was a bit flabbergasted when I couldn't launch a "work user" terminal because of this issue, as I done this with gnome-terminal on one of those "other" linux distributions in the past. I adapted the dbus workaround shown above. I'm posting in case someone with the same need but less shell scripting experience (not that this takes much) finds it useful until this is fixed.

#!/bin/sh
eval `dbus-launch --sh-syntax --exit-with-session`
/usr/lib/libgconf2-4/gconfd-2&
if [ -z "$DISPLAY" ]; then
  DISPLAY=:0
  export DISPLAY
fi

title="`whoami`@`uname -n`"
cmd="gnome-terminal --disable-factory --sm-client-disable --window --title \"$title\""
# open six tabs
tab_count=5
i=0
while [ $i -lt $tab_count ]
do
  i=`expr $i + 1`
  cmd="${cmd} --tab --title \"${title}\""
done

eval $cmd < /dev/null > /dev/null 2>&1 &

[Mark-doffman-codethink (mark-doffman-codethink)]

This issue is also a blocker for D-Bus Accessibility.

I believe that the issue is EXACTLY the same as for a D-Bus based GConf, but I'll describe our issues just to make sure.

1) Applications launched via "sudo <app>" or "su <user>; <app>" should be accessible.
2) Applications launched over ssh should be accessible.

Currently neither of these situations work with AT-SPI D-Bus. We are mainly worried about the "multi-user" case. This is very important as the "greeter" and the "gksudo" windows need to have access to the same D-Bus bus as the main user session and therefore to Orca and other ATs.

The ssh forwarding we can probably wait for / Is not so important.

Adding my two cents. What we imagine is necessary is a D-Bus bus that has the same authorizations and access as the X server. I won't try and defend it, but this was the situation in CORBA AT-SPI as the accessibility IOR was set on the root X window.

This issue is listed on the gnome a11y bonobo deprecation page
http://live.gnome.org/Accessibility/BonoboDeprecation.

The issue is described as:

"""
UNASSIGNED/AT-RISK: With the AT-SPI/CORBA solution, assistive technologies can access GUIs that are not running as the user logged into the desktop. For example, they can access system administration GUIs running as root. There is currently no support in the GNOME D-Bus offering for this. There is a general consensus, however, that there should be an "X Session Bus" for all manners of things, including accessibility. The team needs to work with the larger GNOME/D-Bus community to help make this happen and then migrate the AT-SPI/D-Bus solution to use this newly created bus.
"""

[Evan Broder (broder)]

Here's a patch that cherry-picks an upstream commit to fix this problem for Jaunty.

[Geoffrey Thomas (geofft)]

I've confirmed that installing Evan's package addresses this issue (i.e., that gnome-terminal starts with this patch applied, and doesn't produce any GTK warnings or other ill effects).

[Martin Pitt (pitti)]

According to the bug description this problem is fixed in Karmic.

[Martin Pitt (pitti)]

Seems this isn't a bug in gconf, just a problem in how g-terminal uses gconf.

[Martin Pitt (pitti)]

Accepted gnome-terminal into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[linfidel (linfidel)]

I'm not sure if this is important or not, but thought I'd add just in case...

I just discovered the problem in Ubuntu Jaunty running Root Terminal, something I rarely do. I installed the jaunty-proposed package as described by Martin, and at first, it gave me a blank screen. Then, I noticed that if I resized the window, it would redraw and be OK. This only happens with the root terminal, run gksu; it seems as if using sudo from a terminal works OK, and using gksu from a terminal sometimes worked, I believe (when it didn't re-prompt for the password).

But, I remembered I had tried out a Window Rule using a Compiz Window Management plugin that resized gnome terminal windows. After disabling this rule, the Gnome terminal worked normally at all times.

[Filofel (filofel)]

Update manager downloaded and installed the fix this morning.
Everything works fine now.
Lotsa thanks!

[JimmyJimJames (jimmyjimjames)]

I too loaded the jaunty-proposed package last week and it fixed my problems. Many thanks to the team for tracking this down and creating a fix. I once again have my root terminal with a different color font, launched from a toolbar button. :)

Regards,
   Jim Evans

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-terminal - 2.26.0-0ubuntu2.1

---------------
gnome-terminal (2.26.0-0ubuntu2.1) jaunty-proposed; urgency=low

  * Backport f41c3d14 from upstream to try to start gconf before assuming
    it's not there (LP: #328575)

 -- Evan Broder <email address hidden> Sat, 22 Aug 2009 13:00:55 -0400

[Brian J. Murrell (brian-interlinx)]

Any progress here?

This issue makes "ssh $host $gnome_app" completely useless. It has broken the most wonderful aspect of X11 (over ssh) which is remote application transparency.

Would have been nice if this was fixed for Gnome 2.28. :-(

[Pacho Ramos (pacho)]

Have you tried "ssh -Y..." ?

[Brian J. Murrell (brian-interlinx)]

This bug still exists on Lucid:

karmic-pc $ ssh lucid-pc gnome-terminal
Failed to get the session bus: Failed to connect to socket /tmp/dbus-B95HmT1Dsv: Connection refused
Falling back to non-factory mode.
Failed to summon the GConf demon; exiting. 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: Failed to connect to socket /tmp/dbus-B95HmT1Dsv: Connection refused)

This is what, 3 releases in a row now that this bug has persisted?

$ apt-cache policy gnome-terminal
gnome-terminal:
  Installed: 2.29.6-0ubuntu5
  Candidate: 2.29.6-0ubuntu5
  Version table:
 *** 2.29.6-0ubuntu5 0
        500 http://apt.interlinx.bc.ca/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

[Lennart-poettering (lennart-poettering)]

BTW, here's what I'd propose:

http://lists.freedesktop.org/archives/dbus/2010-May/012853.html

[Hp-pobox (hp-pobox)]

I started a thread with a mail to try to summarize:
http://lists.freedesktop.org/archives/dbus/2010-May/012860.html

[mclay (michael-j-mclay)]

I had the same problem as Brian Murrell in post #74. I have fixed the bug for the past two releases by commenting out the broken code in terminal.c. The test for gconf using gconf_ping_daemon() failed if the program was being called over an ssh connection. When I tried to compile the 2.29.6 source from the Ubuntu source the make command failed didn't compile. The error message was:

    gnome-terminal-2.29.6/src/terminal-window.c:3330: undefined reference to `GTK_WIDGET_REALIZED'
    collect2: ld returned 1 exit status

I am puzzled about the failure to build. It appears that the binaries for gnome-terminal in 10.4 may have been built against a different release.

The solution was to download the 2.29.92 release,and build it. The comment at line 451 of src/terminal.c describes the fix that was made in this release. Here are the steps required to build and install this release:

Download the gnome-terminal-2.29.92.tar.gz from https://launchpad.net/gnome-terminal/main/2.29.92:

    wget http://launchpad.net/gnome-terminal/main/2.29.92/+download/gnome-terminal-2.29.92.tar.gz

Get tools for building deb packages:

    sudo apt-get install autotools-dev fakeroot dh-make build-essential checkinstall

unpack tarball and enter the source directory:

    tar -xzf gnome-terminal-2.29.92.tar.gz
    cd gnome-terminal-2.29.92/

 build, and install the deb:

    ./configure
    make
    sudo checkinstall

The new gnome-terminal will be installed in /usr/local/bin.

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/7.