gnome-settings manager freezes system on login

Bug #597512 reported by MarkG
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-settings-daemon (Ubuntu)
New
Low
Unassigned

Bug Description

Binary package hint: gnome-settings-daemon

When I first logged in, I started up firefox and it began loading the pages from the previous session, then froze. I could see the CPU usage was well over 50%, but looking in top no process was using more than 2%; instead, I was seeing about 75% I/O wait.

Checking iotop, I could see gnome-settings-daemon reading around 2MB/second for at least 30 seconds, while no other process was accessing the disk. So it must be responsible for blowing all my CPU time on I/O waits.

I don't even know what this program does, but this has happened fairly often on logins since installing Lucid and it makes the experience almost as bad as logging into Windows; my CentOS machine, for example, is usable about ten seconds after I log in.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gnome-settings-daemon 2.30.1-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue Jun 22 19:37:17 2010
EcryptfsInUse: Yes
ExecutablePath: /usr/lib/gnome-settings-daemon/gnome-settings-daemon
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_CA.utf8
 SHELL=/bin/bash
SourcePackage: gnome-settings-daemon
XsessionErrors:
 (polkit-gnome-authentication-agent-1:2412): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-terminal:3303): Gtk-CRITICAL **: gtk_accel_map_unlock_path: assertion `entry != NULL && entry->lock_count > 0' failed

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

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
Revision history for this message
Sebastien Bacher (seb128) wrote :

you could run gnome-settings-daemon by hand with --debug to figure what it's doing or try tweaking /apps/gnome-settings-daemon options in gconf-editor to see what code is creating the issue for you, could be the thumbnail cleaning code

Revision history for this message
MarkG (movieman523) wrote :

I do apparently have over 15,000 thumbnails, so that could be the issue.

Revision history for this message
MarkG (movieman523) wrote :

I finally managed to attach strace before it stopped screwing up the system and it's just repeatedly calling lstat() on thousands and thousands of thumbnail files. That's clearly a dumb thing to be doing but I'm still surprised that it's so insanely slow as I'd expect the directory information to be fairly small and cached pretty quickly.

I don't know whether lstat() itself has any performance issues which would make it this slow. Maybe it's having to read information which isn't stored in the directory structure and thereby having to do tens of thousands of single block reads?

Oh, hang on: I'm using ecryptfs for my home directory. I wonder if it's some interaction between a poorly thought out directory scan and extra overhead due to ecryptfs?

Revision history for this message
MarkG (movieman523) wrote :

I logged it on the Gnome bugzilla at: https://bugzilla.gnome.org/show_bug.cgi?id=625609

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

Other bug subscribers

Remote bug watches

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