*** Bug 570588 has been marked as a duplicate of this bug. ***

Can you not start a GConf daemon like Nautilus does?

Eg, if I run "gksu nautilus", it starts successfully and spawns a GConf daemon as the root user. If I run "gksu gnome-terminal", it just terminates.

No, that is not what you want. If there is no gconf daemon, the application just needs to run with default settings. Nevermind that running random parts of the desktop as root is really not the right way to go about things either...

I wasn't suggesting that running random parts of the desktop as root was the right way to go about things - I just used that as an example to show that Nautilus actually spawns a gconf daemon if one is not already running

If I manually revert:

  /* 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);
    }*/

Then it works just fine.

I also agree, that you should continue running the terminal
How I can start gconf manually:

doing 

/usr/lib/libgconf2-4/gconf-2

didn't help

I can confirm this bug on 2.26. I am having exactly the same issue. Starting a terminal as root as many uses, I believe lots of users find this practical.

Not a fix, but as this bug has been opened six months ago, and I'm currently hit in F11 with remote gnome-terminal through ssh, 'sakura' is a fine terminal replacement (pending bug resolution).

I also see this issue, and had to downgrade to 2.24. I'm not running as root, it's that I don't actually have a session bus running. 2.24 works fine for me.

Everything we have to do if conf_ping_daemon fails:

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

start dbus for current session, set environment variables as printed by dbus-launch, start gconfd-2 in background, then continue launching.

dirty fix may look like this...

   */
  /*if (!gconf_ping_daemon ())
    {
-      g_printerr ("Failed to contact the GConf daemon; exiting.\n");
-      exit (1);
+      char buf[8192];
+      if(snprintf(&buf,sizeof(buf),"eval `dbus-launch --sh-syntax --exit-with-session`; /usr/lib/libgconf2-4/gconfd-2& %s $@",argv[0])>0)
+            execv(&buf,argv);
    }*/

Just wanted to add that it's not root user specific feature: I use gksu to start programs for non-root users such as myself when another family member is already logged on (security is not an issue here, it's more of transparent isolation). And I cannot start another X session because of video driver issues, and switching between sessions would not be convenient either. 
So now I cannot start terminal at all without loging-out the former user.

I'm using Xming to access Fedora boxen and export the gnome-panel.  This was working great with no tricks on FC10.  I started having problems with FC11, so rather than starting '/usr/bin/gnome-panel' on the remote FC11 box, what I do now is start a script that does the things vlad mentioned above.

#!/bin/sh

eval `dbus-launch --sh-syntax --exit-with-session`
/usr/libexec/gconfd-2&
/usr/bin/gnome-panel

This allows me to execute gnome-terminal from the panel menu with no problems.

Is this fixed?

I also agree starting gconfd is a bad solution, if you're trying to run it as root, gconfd will be spawned with such user permissions and you may have 2+ gconf daemons running, which would be left running but useless as soon as gnome-terminal is finished.

This bug is not fin FIXED stat, so no, this is not fixed.

The 'solution' from comment 9 is totally bogus, of course.

comment 5 has the correct fix here; gconf itself will take care of spawning a gconfd, if gnome-terminal just removes the explicit check for an existing gconfd.

This is really not appropriate as an "enhancement" bug; gnome-terminal completely fails to work in a non-GNOME login session until you happen to run some other GNOME app that spawns a gconfd.

Comment 5 has NO 'fix'; removing the check just re-exposes the original crash in bug 561663).

In 2.27.91, I changed this check however so that g-t doesn't expect the gconf demon to be already started, but tries to activate it and only fails if the gconf demon is neither running nor can be activated.

I don't intend to do anything further on this bug until porting g-t to gsettings/dconf.

As noted above, ideally Gnome Terminal should gracefully cope with a lack of D-Bus/Gconf/etc.

Gnome-Terminal is a terminal emulator; not a Regedit-alike configurations settings tool (for which a failure trying to fire up Gconf /might/ be considered fatal).

*** Bug 655367 has been marked as a duplicate of this bug. ***

Fixed on master.