Ubuntu
gnome-settings-daemon package

gnome-settings-daemon freezes, desktop theming disappears

Bug #733253 reported by Jan Rathmann
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
gnome-settings-daemon (Ubuntu)
New
Low
Unassigned

Bug Description

Binary package hint: gnome-settings-daemon

Hello,

I'm reporting a bug here that happens in my VirtualBox installation of Natty since an early date in the releasy cycle.

It occurs permanently on a classic gnome session:
- I type my login password, the desktop appears and looks normal - for the first seconds
- then, usually 20-30 seconds after login, the selected GTK theme (Ambiance by current default) and icon theme (Humanity) disappear and the desktop and programs use the fallback Raleigh(?) GTK theme and the fallback icon theme (see screenshot below). Custom settings of font type/size are also not respected. However the correct metacity/compiz theme stays in use.
- The gnome-settings-daemon process seems to be responsible, as it is completely unresponsive at this state. It doesn't respond to SIGTERM, only SIGKILL (kill -9) can terminate it.
- If I manually restart gnome-settings-daemon it works (in most cases?).

Further observations I made about this issue:
- It happens all the time on a classic gnome session, regarding Unity I have seen it in the past to but on the last logins it worked with Unity running.
- It is independent of the video driver, regardless if I choose Vesa or Vboxdrv (for hardware accelaration).
- Settings up a fresh user account does NOT help!
- I once or twice saw this on a non-virtual real hardware installation, but that was some time ago (before Alpha 2 I think) and didn't happen again since then.

If I can provide any further informations for debugging, please let me know.

Kind regards,
Jan

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: gnome-settings-daemon 2.32.1-0ubuntu8
ProcVersionSignature: Ubuntu 2.6.38-6.34-generic 2.6.38-rc7
Uname: Linux 2.6.38-6-generic x86_64
Architecture: amd64
Date: Fri Mar 11 13:55:26 2011
EcryptfsInUse: Yes
ExecutablePath: /usr/lib/gnome-settings-daemon/gnome-settings-daemon
ProcEnviron:
 LANGUAGE=de_DE:de_AT:de:en_GB:en
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-settings-daemon
UpgradeStatus: Upgraded to natty on 2010-11-15 (116 days ago)
XsessionErrors:
 (nm-applet:1470): Gdk-CRITICAL **: IA__gdk_window_thaw_toplevel_updates_libgtk_only: assertion `private->update_and_descendants_freeze_count > 0' failed
 (nautilus:1446): GConf-CRITICAL **: gconf_value_free: assertion `value != NULL' failed

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :
Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

Here is a backtrace, hopefully done right.

Gary M (garym)
Changed in gnome-settings-daemon (Ubuntu):
status: Incomplete → New
Revision history for this message
Michael Flaig (mflaig) wrote :

Happens to me as well with natty in virtualbox, running unity (3d).
Disabling 3d accelration and using gnome classic doesn't affect the bug. It's there as well.

Revision history for this message
Daniel Wiberg (dannew) wrote :

Thanks, the suggested workaround works for me to.

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is no crash in that gdb log, do you get a .crash or apport triggering when you get the issue? could you add your .xsession-errors to the bug?

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

Hello Sebastien,

it indeed doesn't crash in the sense that Apport is triggered. g-s-d seems to get somehow into a completely unresponsive state, meaning you can't terminate it with anything but kill -9 . It seems to consume no CPU time, so g-s-d is obviously not running in a loop.

I did some further testing with g-s-d when it was properly running that showed interesting behaviour. If I sended a SIGTERM ("normal kill") to g-s-d, the custom desktop theming disappeared instantly, like one would expect when g-s-d has been terminated.
But looking at the running processes showed that the same g-s-d process was still there, allthough now in an unresponsive state (like it happens if I just start a desktop session on my virtual machine)! Doing kill -9 helps of course to terminate it completely.

I tested this both on my virtual machine when I had restarted g-s-d manually and also on my Maverick desktop running on real hardware (where never any problem with g-s-d has occured).

As a conclusion, could it be possible that the following happens: While the desktop session is loading, g-s-d receives (for an unknown reason) a SIGTERM and remains in an unresponsive state untill one kills it with kill -9 (and manually restarts it).

Is there any way I can help with debugging such an issue?

Anyway, here is my .xsession-errors file (beware, it inflates to 73MB!).

Kind regards,
Jan

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

I learned about Bug #649809 today, and since I am very fond this is the same bug I'm marking my report here as a duplicate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.