Bug 466206 - imsettings-applet races with gnome-settings-daemon to own XSETTINGS manager
imsettings-applet races with gnome-settings-daemon to own XSETTINGS manager
Product: Fedora
Classification: Fedora
Component: imsettings (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
: Reopened
: 462111 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-10-09 03:23 EDT by Denis Leroy
Modified: 2009-03-10 06:45 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-10 06:45:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
g-s-d trace catching gdk_x_error (3.33 KB, text/plain)
2008-10-13 17:45 EDT, Denis Leroy
no flags Details

  None (edit)
Description Denis Leroy 2008-10-09 03:23:57 EDT
After rebooting with today's updates, I ran into another case of "gnome-settings-daemon" not actually running. This happened to me a few times before with F10-beta, but is not always reproducable. Essentially, after logging in, all the font sizes are wrong. Trying to launch the Appearances gnome dialog pops up the error "Unable to start the settings manager 'gnome-settings-daemon. Without the GNOME settings [etc...]'.

Didn't see anything useful in /var/log/messages. How could I provide more information ?
Comment 1 Bastien Nocera 2008-10-09 05:39:45 EDT
Which version of gnome-settings-daemon? And did you update to the latest version?
Comment 2 Denis Leroy 2008-10-09 05:47:12 EDT

Am fully updated right now.
Comment 3 Bastien Nocera 2008-10-09 05:53:44 EDT
Could you try launching /usr/libexec/gnome-settings-daemon by hand and gather a backtrace of the crash?
Comment 4 Denis Leroy 2008-10-09 06:05:11 EDT
Bastien, I'll try. When I launched the daemon manually, it seemed to work correctly. I've changed the kernel core pattern to /tmp and will try to reproduce. Since the daemon is launched by the /etc/xdg/autostart/ file, do you know if it will create a core dump by itself ?
Comment 5 Denis Leroy 2008-10-09 08:11:42 EDT
Well, here's the culprit:

The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 1344 error_code 8 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[1223552760,000,xklavier.c:xkl_engine_start_listen/] 	The backend does not require manual layout management - but it is provided by the application

Since this appears X related, and I am using the nvidia driver (don't really have a choice), I tried reproducing the bug with the "nv" driver, but without success. I can only guess this is an Nvidia-related problem, so unless you think there's still some value in pursuing this, I'm going to close this bug as WONTFIX. Let me know.

Now I have to figure out which g-s-d plugin makes nvidia unhappy... sigh :-(
Comment 6 Bastien Nocera 2008-10-09 08:54:45 EDT
Most likely not related to the driver directly, but to the X configuration you'd be using for it.

Passing on to libxklavier where the X error occurs.
Comment 7 Ray Strode [halfline] 2008-10-09 11:53:32 EDT
libxklavier is just the last thing to set up an X error handler.  It's probably unrelated to the problem.

The two plugins that have seen the most churn lately are the background plugin and the xrandr plugin.

Denis can you open up gconf-editor and navigate to


and unchecking active, then try to reproduce.  Once you've tested that one, reactivate it, and then navigate to


uncheck active and try to reproduce.

If you could do those two things and report whether disabling one of them fixes the problem, that'd be great.
Comment 8 Denis Leroy 2008-10-10 09:26:20 EDT
It seems to be 'background', at least I'm about 90% sure.
Comment 9 Thomas J. Baker 2008-10-13 10:22:24 EDT
I'm having this problem as well. From what I've seen, it seems to happen on the first login after boot. If I login and have it fail, then 'killall -u tjb' (which logs me out and puts me back to gdm) and login again, it usually works fine..
Comment 10 Matthias Clasen 2008-10-13 12:29:09 EDT
Can you run gnome-settings-daemon manually with

/usr/libexec/gnome-settings-daemon --no-daemon --sync

under gdb, and break in gdk_x_error

and produce a backtrace, please
Comment 11 Thomas J. Baker 2008-10-13 16:09:47 EDT
FWIW, I'm having the same problem on a laptop with intel graphics so I don't think it's related strictly to nvidia. I just went through a series of reboots since installing the gnome-settings-daemon-2.24.0-7.fc10.x86_64 update this morning and had it work fine 4 reboots in a row. Right when I was ready to say I think it's fixed, it happened again.

I tried running what you wanted there but am not sure I'm doing it right. When I ran it, it never got to gdk_x_error and so it never broke. Here's some of what it says:

(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) run --no-daemon --sync
Starting program: /usr/libexec/gnome-settings-daemon --no-daemon --sync
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff6d737a0 (LWP 4266)]

** (gnome-settings-daemon:4266): WARNING **: You can only run one xsettings manager at a time; exiting

** (gnome-settings-daemon:4266): WARNING **: Unable to start xsettings manager: Could not initialize xsettings manager.
Detaching after fork from child process 4282.
[New Thread 0x7ffff1684950 (LWP 4283)]
Detaching after fork from child process 4284.
Detaching after fork from child process 4285.
Shutdown failed or nothing to shut down.

Probably not much help.
Comment 12 Denis Leroy 2008-10-13 17:45:59 EDT
Created attachment 320235 [details]
g-s-d trace catching gdk_x_error

That was a tough one but I nailed the trace. I had never been able to reproduce the bug when running gsd manually, so I had to change the Session entry to make it run a script that launches an "xterm -e gdb -x cmds" with cmds being "set breakpoint pending on; break gdk_x_error; run --no-daemon --sync --debug". It caught the X error after a few tries. Attached. It is indeed coming from the background plugin.

Let me know if you need some RPMs recompiled with -g3 -O0
Comment 13 Ray Strode [halfline] 2008-10-14 14:56:39 EDT
This may be a race between nautilus and g-s-d

If they they both call gnome_bg_create_pixmap () and then race to gnome_bg_set_pixmap_as_root_with_crossfade then g-s-d's pixmap could get destroyed by nautilus.

Note, g-s-d has this code:

gnome_bg_load_from_preferences (manager->priv->bg,

/* If this is set, nautilus will draw the background and is
 * almost definitely in our session.  however, it may not be
 * running yet (so is_nautilus_running() will fail).  so, on
 * startup, just don't do anything if this key is set so we
 * don't waste time setting the background only to have
 * nautilus overwrite it.
nautilus_show_desktop = gconf_client_get_bool (manager->priv->client,

if (nautilus_show_desktop) {
        /* even when nautilus is supposedly handling the
         * background, apply the settings eventually to make
         * people running a nautilus-less session happy */
        manager->priv->timeout_id = g_timeout_add_seconds (8, (GSourceFunc)queue_draw_background, manager);

with the assumption being queue_draw_background won't get called for 8 seconds.

That assumption is wrong, because gnome_bg_load_from_preferences queues a "changed" signal which causes queue_draw_background to get called right away.

If we fix that bug, then I think this one will go away, too.

None the less, we should probably grab the server after gnome_bg_create_pixmap() and ungrab the server after copying the end pixmap
Comment 14 Ray Strode [halfline] 2008-10-15 12:03:59 EDT
Last night I commited code to fix the two above bugs.

I'm going to close this issue. If you still see it with latest rawhide, please reopen.
Comment 15 Bastien Nocera 2008-10-15 18:01:50 EDT
*** Bug 462111 has been marked as a duplicate of this bug. ***
Comment 16 Denis Leroy 2008-10-23 06:00:07 EDT
This bug made a stunning come back this morning after yesterday's big batch of updates :-(

I'll try to get a trace again.
Comment 17 Denis Leroy 2008-10-24 18:19:31 EDT
So a variant of this bug exists.

gnome-settings-daemon does not crash, it seems to run fine. However there is still some sort of race condition going on, since after I log in all my font sizes are wrong (i.e. they're default sizes, rather than the ones I configured explicitly). As a matter of fact, if I go into the appears menu and change the application font sizes or the font smoothing preference, nothing happens...

yet, gnome-settings-daemon is running (in gdb in my xterm window :-) )... This is after today's updates.
Comment 18 Denis Leroy 2008-10-24 18:29:10 EDT
Comparing the gdb output of g-s-d between a good and bad run, the following lines immediately stand out:

** (gnome-settings-daemon:3281): WARNING **: You can only run one xsettings mana
ger at a time; exiting

** (gnome-settings-daemon:3281): WARNING **: Unable to start xsettings manager: 
Could not initialize xsettings manager.
Comment 19 Matthias Clasen 2008-10-25 23:47:51 EDT
Interesting, what other xsettings manager could you have running ?
Comment 20 Denis Leroy 2008-10-26 05:36:30 EDT
The call to XGetSelectionOwner() doesn't return None as expected, but a Window id (39845922). Can you point me to a ways to map this to another running app ?
Comment 21 Matthias Clasen 2008-10-26 15:38:02 EDT
I don't know a tool to do that directly. If you run xrestop, you may be able to figure out which app created that window, by looking at the resource id ranges.
Comment 22 Denis Leroy 2008-10-27 04:29:51 EDT
And the winner is:

*drum rolls*



  XSetSelectionOwner (display, manager->selection_atom,
		      manager->window, timestamp);
Comment 23 Akira TAGOH 2008-10-27 05:23:28 EDT
Thanks for catching up the unpredictable order for session management between gnome-session and XDG autostart. Though imsettings-applet enables XSETTINGS manager only when no XSETTINGS manager is running and usually g-s-d should be running before looking at XDG autostart dir.  You could disable that feature manually to avoid that entirely with:

$ gconftool-2 -s -t string /apps/imsettings-applet/xsettings_manager disabled

I'm pondering to disable it from the command line and have different .desktop files for GNOME/XFCE and others with OnlyShowIn and NotShowIn. and put one for GNOME into /usr/share/gnome/autostart which may be reliable a bit more than /etc/xdg/autostart for GNOME.
Comment 24 Akira TAGOH 2008-10-27 08:54:33 EDT
Fixed in imsettings-0.105.1-2.fc10. the instance of XSETTINGS manager won't be no longer created for GNOME/XFCE anyway.
Comment 25 Matthias Clasen 2008-10-27 10:46:53 EDT
Can we _please_ nuke any remnants of rogue xsettings manager from input methods ?

Nobody but the desktop environment itself has any business running xsettings managers.
Comment 26 Akira TAGOH 2008-10-28 03:21:48 EDT
Matthias, I'm afraid I don't see your point on using XSETTINGS. you said before when I asked you "what's wrong when imsettings doesn't work on the desktop not having the own XSETTINGS manager", "it's not a bug in the desktop but it's a mistake imsettings chose it to deliver the setting".  If the desktop itself has any business running XSETTINGS manager and something relates to XSETTINGS doesn't work, is it still a bug in the desktop itself then, isn't it?
As you know imsettings isn't any desktop-specific framework and I don't even think it should be nor is a good idea the desktop has similar code except UI/toolkit related work, since it doesn't depend on the desktops. so just provides a facility to get it working for the desktops which doesn't have, since there are no common implementation of XSETTINGS manager (not for the desktop config) and all the desktops implementation doesn't necessarily have one. otherwise immodule selection behavior is unpredictable without it.

Though we had discussed about a common implementation of XSETTINGS manager before, but I don't still see why not. my understanding is, XSETTINGS itself doesn't depend on any configuration library. we could still have different backends to reference them to XSETTINGS keys and the backends could be loadable dynamically. if one doesn't want/need gconf/GNOME related desktop config, they could stop loading. similarly I can provide a backend for imsettings for a common implementation of XSETTINGS manager then. this would makes GTK+/GNOME applications working on non-GNOME desktop as well as non-GTK+/GNOME applications on GNOME desktop, which uses XSETTINGS for their configuration say. and noone needs to reimplement XSETTINGS manager for their desktops and won't mind if duplicate instance is running on the desktop anymore. what's wrong with this idea?
Comment 27 Matthias Clasen 2008-10-28 09:35:37 EDT
xsettings are a mechanism to export a small set of common cross-desktop settings from a desktop-specific configuration system (like gconf, or kconfig, or whatever) in a desktop-neutral way for applications to use. 

XSettings are not something you just implement for yourself because you are afraid to commit to any concrete configuration system. 

This whole notion that the input method framework could be something that sits in splendid isolation from the desktop itself is something that doesn't work, and needs to be revisited. 

There is a growing concern on the desktop side about scim breaking the desktop experience for users _who don't even want input methods_.

This bug is just one example of our fragile input method framework of frameworks breaking the desktop.

Sorry for ranting.
Comment 28 Kevin Kofler 2008-10-28 10:48:02 EDT
FWIW, from a KDE packager point of view, while KDE doesn't currently have an xsettings manager (which is its own interoperability issue we'll want to fix eventually - there's an xsettings-kde for KDE 3, but it doesn't work properly in KDE 4), I also don't think imsettings should be the xsettings manager for KDE, because it does not and should not know any settings apart from input.

I understand the need to work around the lack of an xsettings manager in KDE for now, but in the long term this is a bad solution.
Comment 29 Kevin Kofler 2008-10-28 10:55:40 EDT
And as Matthias Clasen says, xsettings may not be the right thing to use in the first place.
Comment 30 Bug Zapper 2008-11-25 22:41:14 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:

Note You need to log in before you can comment on or make changes to this bug.