Description of problem: While GNOME starting, gnome-settings-daemon doesn't start. Doesn't gnome-session load gnome-settings-daemon.desktop, maybe? Version-Release number of selected component (if applicable): 2.24.0-2.fc10.i386 How reproducible: always Steps to Reproduce: 1. login on GDM. 2. 3. Actual results: Expected results: Additional info: After launching gnome-appeariance-propertis, gnome-settings-daemon start. gnome-session-2.24.0-4.fc10.i386
Jon and Ray would know.
i think there was recently a problem with a crashy xrandr plugin. if you run /usr/libexec/gnome-settings-daemon do you get anything interesting in the console?
(In reply to comment #2) > i think there was recently a problem with a crashy xrandr plugin. > > if you run /usr/libexec/gnome-settings-daemon > > do you get anything interesting in the console?
Created attachment 318156 [details] /usr/libexec/gnome-settings-daemon --debug --no-daemon Sorry! ignore comment #3 (In reply to comment #2) > i think there was recently a problem with a crashy xrandr plugin. > > if you run /usr/libexec/gnome-settings-daemon > > do you get anything interesting in the console? No. i don't get special message. This issue is random. Sometimes g-s-d works well. Sometimes g-s-d doesn't start. When this issue happens, only rebooting makes this issue fixed.
Are you still seeing this ? Ray fixed a problem in the background capplet recently that could lead to crashes.
Right, I'm going to close this bug, but if it happens again, please reopen.
Inital Booting After background flashing, themes (gtk2, icon theme) become default. $ ps ax | grep gnome-settings-daemon None gnome-settings-daemon-2.24.0-14.fc10.i386 gnome-session-2.24.1-3.fc10.i386 gnome-desktop-2.24.1-5.fc10.i386 gdm-2.24.0-12.fc10.i386
I'm seeing this on and off since upgrade to F10; doesn't appear to be consistent- maybe some kind of race condition. Any debugging tips/requests welcome; really irritating bug. :/
Does disabling the background plugin with gconftool-2 --set /apps/gnome_settings_daemon/plugins/background/active --type boolean false make the problem disappear?
since it isn't deterministic, it is hard to say, but I'll do that and see what happens. [I do notice that the background changes even when g-s-d otherwise fails, so maybe that is part of the problem.]
Oh, whoops -- pasted the wrong comment when resolving bugzilla comment collision. Sorry Ray. This is happening consistently to me on login, but I can't reproduce it once the session has started. I don't know if its the same problem Luis has, but I'll try to get a core file later this afternoon.
Good point- if I run settings-daemon from the command line after login, it always works fine.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can confirm this bug. I installed F10 friday and I have rebooted 3-4 times since. But, the last time I rebooted was this morning and I have encountered this bug. gnome-settings-daemon don't start at Gnome launch. If I start an application that need it (ex : keyboard shortcut), the first time it gives me an error saying that gnome-settings-daemon is not running. The second time, gnome-settings-daemon start and everything is back to normal. Let me know if I can provide more informations.
FWIW, since disabling the plugin I haven't seen the bug. Seems like it should be disabled by default until fixed.
One small change for me, my laptop has been opened for the whole day and gnome-settings-daemon has start well this morning. But, in the PM, I press the button to mute sound and nothing happen. I check just to see the gnome-settings-daemon is not running anymore. I don't know yet what cause the crash.
Ok, I try to find the cause of this crash. I have some questions to help find a common cause for the bug. Does any of you can provide : - The video card you have - If you have dual screen setup - If you have played with the session preference in Gnome For me, it's Nvidia, dual screen setup with twinview and yes, I have played with the session preference. Some of my colleague don't experience this bug but don't have played with gnome session and don't have dual screen setup.
X31 laptop (intel video maybe?); don't boot with dual screen; have played with some session preferences but probably more crucially have upgraded the same ~ directory for, um, roughly forever.
*** Bug 474565 has been marked as a duplicate of this bug. ***
I have a dell XPS M1210 Video card is 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) I am using it with an external monitor plugged into the VGA output, so yes, dual screen setup (although the LVDS is turned off with xrandr). I haven't touched session preferences. HTH
Ok, weird. gnome-settings-daemon always start for good now. I have updated my system as of yesterday and the problem is not there anymore. Can anyone confirm?
The gnome-settings-daemon seems to be starting without probs for now, but the behaviour described in Bug #474565 seems to be persisting. When I try to create a new user and after login going to the system->preferences->hardware->keyboard the error appears.
I don't have any problem now. gnome-settings-daemon start well for me at startup and don't die after.
I found it had been behaving itself for a while, but recently I've logged in and found things like my preferred icon theme not being set. Found this in .xsession_errors, could it be related? 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 946 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.) xorg-x11-drv-i810-2.5.0-4.fc10.x86_64 on Intel X3100 xorg-x11-server-Xorg-1.5.3-6.fc10.x86_64 gnome-settings-daemon-2.24.1-3.fc10.x86_64
I had a crash this morning, probably same cause. Bug buddy popped up at login to gnome desktop, saved a text file. After bug buddy finished, desktop would not respond to mouse clicks. A reboot started normally. First part of bug buddy text: System: Linux 2.6.29-0.258.rc8.git2.fc11.i586 #1 SMP Mon Mar 16 20:53:59 EDT 2009 i686 X Vendor: The X.Org Foundation X Vendor Release: 10600000 Selinux: Permissive Accessibility: Disabled GTK+ Theme: Unity Icon Theme: Tango GTK+ Modules: canberra-gtk-module, pk-gtk-module, gnomebreakpad Memory status: size: 0 vsize: 0 resident: 0 share: 0 rss: 0 rss_rlim: 0 CPU usage: start_time: 0 rtime: 0 utime: 0 stime: 0 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 0 ---- Critical and fatal warnings logged during execution ---- ** Gdk **: The program 'gnome-settings-daemon' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 635 error_code 9 request_code 14 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.) ----------- .xsession-errors (33 sec old) --------------------- Gdk-ERROR **: The program 'gnome-settings-daemon' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 635 error_code 9 request_code 14 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.) aborting... MCS->Xfconf settings migration complete ** (nautilus:2642): WARNING **: Unable to add monitor: Not supported -------------------------------------------------- I will send rest of bug buddy report, or other log data, if requested.
g-s-d keeps crashing here. Please tell me what I can do to help debugging the problem.
(In reply to comment #9) > Does disabling the background plugin with > > gconftool-2 --set /apps/gnome_settings_daemon/plugins/background/active --type > boolean false > > make the problem disappear? At least it worked for me once. I tried to start g-s-d manually and it crashed directly 3 times. After disabling the background plugin it worked. Will investigate further.
've just seen this for the first time in F11, with gnome-settings-daemon-2.26.1-5.fc11.x86_64: ** (gsynaptics-init:2178): WARNING **: Using synclient 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 913 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.) It's only started doing it in the last few days, I'll see if downgrading g-s-d helps.
I should also add that starting g-s-d manually this time crashes the session. I don't know specifically what died and how, but the only thing of possible relevance I can see in messages is: May 21 08:20:10 localhost gnome-session[2013]: GLib-GObject-WARNING: cannot register existing type `PkPangoFcFontMap' May 21 08:20:10 localhost gnome-session[2013]: GLib-GObject-CRITICAL: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed May 21 08:20:10 localhost gnome-session[2013]: GLib-GObject-CRITICAL: g_object_unref: assertion `G_IS_OBJECT (object)' failed May 21 08:20:10 localhost kernel: compiz[2201]: segfault at 4fa04be ip 000000000040ed8e sp 00007fffa511aca0 error 4 in compiz[400000+3a000]
James, seems like that may be some sort of packagekit bug that should get filed separately.
OK, downgrading didn't help. The issue showed up eventually. Attempting to start g-s-d still kills the whole session, but I can't find anything in the logs showing precisely what part died and under what circumstances.
I kind of have a similar problem here with f11. I've already selected clearlooks-classic as my gnome theme when logging in locally. When I starts a vnc gnome session, the gnome theme changes to nodoka(the window decorator is a mix of clearlooks and nodoka). If I open the appearance window from System->Preferences, the theme will change back to what I selected. Close that window, theme changes back to nodoka. I notice there is a gnome-settings-daemon running: $ ps ax |grep gnome-settings-daemon 2292 ? Ssl 0:00 /usr/libexec/gnome-settings-daemon --gconf-prefix=/apps/gdm/simple-greeter/settings-manager-plugins 2729 pts/1 S+ 0:00 grep gnome-settings-daemon It should be gdm. If I open the appearance window a second time, I will get a crash notification: The application notification-daemon has crashed. Information about the crash has been successfully collected... And sometime my whole session will also crash. I tried manually starts gnome-settings-daemon from command line: $ /usr/libexec/gnome-settings-daemon $ ** (gnome-settings-daemon:3589): WARNING **: XKB extension not available ** (gnome-settings-daemon:3589): WARNING **: Neither XKeyboard not Xfree86's keyboard extensions are available, no way to support keyboard autorepeat rate settings ** (gnome-settings-daemon:3589): WARNING **: Connection failed The program 'gnome-settings-daemon' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 1040 error_code 3 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.)
Aaron, this comment here: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/199245/comments/19 was a workaround that stopped the gnome-settings-daemon from crashing in a vnc session. FYI.
Thank you Mike, it worked well for me.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.