gnome-settings-daemon extensive disk usage

[Gergely Csépány]

Binary package hint: gnome-settings-daemon

Upon login to Gnome and waking up the laptop from sleep the gnome-settings-daemon is extensively reading something from the hard disk. I watched it by iotop, tried to figure out what does it open by lsof and readahead-watch, but I only found some screensaver files and gnome-libs. I have no clue what is it looking for.
It's really frustrating when I have 10 minutes in the morning to read my emails and I have to wait 5-6 minutes for gnome-settings-daemon to finish it's something before I get use my computer normally (normally means that I can launch programs in a sensible time).
If I kill gnome-settings-daemon, of course the problem is gone so as my gnome theme making it a not really working workaround.
The problem also existed on Jaunty, now on Karmic too, how could I track it down and find out what causes this behaviour?

ProblemType: Bug
Architecture: amd64
Date: Sat Jan 9 09:55:17 2010
DistroRelease: Ubuntu 9.10
Package: gnome-settings-daemon 2.28.1-0ubuntu2
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: gnome-settings-daemon
Uname: Linux 2.6.31-16-generic x86_64

[karlrt (karlrt)]

i got the same problem. in iotop, i see that after gnome-do finished reading harddisk, gnome-settings-daemon starts to read at full power for about 5 min at least.

[Gergely Csépány (cheoppy)]

I made a strace log about gnome-settings-daemon a few days ago when it was doing this mysterious disk reading. I found that it was reading the whole .thumbnails directory, which, on my laptop contains 12,429 items, totalling 210.8 MB. I'll try now to clean it (or just rename it to be safe) and I'll watch out for excessive disk usage by g-s-d.

I don't know what g-s-d might do with the thumbnails, it might cache them, check if they are ok or something strange. The sensible operation would be to it check if the original file still exists and delete the orphaned thumbnails, but since I have 12k+ thumbnails, this doesn't seem probable.

You can do an strace tracking by 'strace -p $(pidof gnome-settings-daemon) -o strace-g-s-d.log' which will save the output to strace-g-s-d.log file (don't forget that you need to press ctrl+c to stop tracking!).

[karlrt (karlrt)]

my thumbnails folder has 32.000 images and 450MB. I didnt strace g-s-d yet but yeah that might be the problem.

[karlrt (karlrt)]

Oh, and i ran a strace-tracking, it showed me exactly the same as your log. It reads all the thumbnails.

if you look at https://bugzilla.gnome.org/show_bug.cgi?id=150483 and https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/37643 i think there lies the problem:

in gnome-settings-daemon, they implemented a "housekeeping" plugin:

"- Added a new "housekeeping" plugin to set limits on the size and age of the
      thumbnail cache"

I think this housekeeping mechanism just goes crazy and checks my 32.000 thumbs every boottime for consistency. Perhaps someone could check if thats it? Should we reopen the old bug because their fix braught up this problem?

[karlrt (karlrt)]

workaround renaming/deleting the .thumbnails folder works

[Gergely Csépány (cheoppy)]

On https://bugzilla.gnome.org/show_bug.cgi?id=150483 in the last comment there's this:
"Starting with gnome 2.23.x, the oldest thumbnails are purged shortly after login when the cache exceeds 64 MB, or if they are older than 60 days, (...)"

However the limits were redefined in Ubuntu, see in gconf-editor:
/desktop/gnome/thumbnail_cache/maximum_age and
/desktop/gnome/thumbnail_cache/maximum_size

They were set to 512MB and 180 days, that means dozens of thousands of thumbnails to keep, simply doesn't make sense, these limits should be lower.

[Gergely Csépány (cheoppy)]

After setting the time to keep the thumbnails to 60 days and the cache size to 128MB, gnome-settings-daemon got to work and reduced my thumbnails cache to 2,503 items, totalling 36.6 MB.
I really hope this solves the problem, I'll see it in a few days.

[karlrt (karlrt)]

i agree these values are high, but honestly, i got enough space to have these thumbnails saved, and its quite comfortable to browse through large photo-directories without having to regenerate the thumbs.

the real bug here is that it takes g-s-d 5-10 minutes to evaluate if some thumbs should be kept or deleted. Deleting files older then 180 days shouldnt take that long!

[Felipe Blanco-Ollé (fblanco)]

How come this has not been corrected in Lucid?

In my opinion, these values are way too high for anyone not involved with photography or graphic design: with over 40,000 items on my thumbnail cache, it took my laptop about one minute to be available for any meaningful work after logging in. This on a Core i7 system, which actually takes 20 seconds to boot the whole OS!

I just deleted all items from the thumbnail cache, and set the thumbnail-cache values at 1 day and 32 MB: I rather wait while my computer generates thumbnails on the fly, than to wait one minute every time gnome loads. My system is now back to normal.

Anyhow, I have to agree with karlrt: the real bug is g-s-d taking so long to process the cache folder. Anyways, my suggestion is to either fix g-s-d, so as to process the thumbnail folders in an efficient manner, or lower the default values for the cache dramatically. I'm so happy I finally came home after a two week work trip where I didn't have an internet connection to research on the problem or even install iotop. Ohh, and my gnome themes are not crashing randomly at boot anymore.

[ylsdd (ylsdd)]

Lucid on my laptop has the same problem. Every time it resume from suspend, g-s-d spend a huge amount of time on check the cache, where there are 28,000 files.

1) It is not just a problem of too-high-limits. Indeed, on my laptop, maximum_size=512, which is the default value, however, the actual cache size is

  du -sm .thumbnails/
  664 .thumbnails/

which is well above the limit.

2) It shouldn't perform check too frequent. If thumbnails will expire in 180 days, they only need to be checked once a few days.

3) If it do have to check files, this task should be done when the computer is not idle, instead of the busy moments of every booting or every resuming.

[Eric Link (link-sandlion)]

I've been suffering from this same problem as well. This s obviously broken on a few levels. @ylsdd you are right on all three points. +1 for those three. Immediate fix should be to make this low priority thread or something; it disables my computer usage for many minutes on login and is a usability show stopper.

find .thumbnails/ |wc
  18849 18849 1055354
du -sm .thumbnails/
625 .thumbnails/

[Eric Link (link-sandlion)]

my hackaround it (remove thumbnail files older than 10 days, via cron, each hour:

sudo vi /etc/cron.hourly/tmp-cleanup

#!/bin/bash
## login disk thrashing
find /home/elink/.thumbnails -mtime +10 -type f -exec rm -rf {} \;

:wx

sudo chmod 755 /etc/cron.hourly/tmp-cleanup

[Aisthesis (aisthesis)]

Having this issue as well on every reboot/start. Finally got tired of it, researched, and found this bug. I have to go into the office twice a week and it really just started doing this only a few weeks ago. Also, it only started doing it to me on Lucid. Unless it just took some time for this problem to appear? I think it would be safe to assume it affects everyone using Ubuntu+Gnome+Nautilus.

In my case, it took about 2-4 minutes on my laptop for this process to stop. Laptop HD is only 5400rpm with a 2.3ghz Core2duo. I was at 446mb and between 25-30k files in the directory. The IO prevents everything else on the machine requiring read/write from the disk from operating at an acceptable speed.

[Sebastien Bacher (seb128)]

The bug should be reported to the GNOME bugzilla by someone who has an opinion about what to change, the default seems reasonable though

[karlrt (karlrt)]

The appropriate upstream-bug was already done!

[Vish (vish)]

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

 - This is a bug and not a papercut.
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.
Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

[KennoVO (kenno-xs4all)]

For anyone struggling with this problem and searching for workarounds, the upstream discussion is a good read. Apparently, it is possible to entirely disable the housekeeping mechanism that is responsible for this problem:
https://bugzilla.gnome.org/show_bug.cgi?id=625609#c6

Doing so will
(1) disable purging of old thumbnails, so one either has to live with the thumbnail cache growing boundlessly, or implement a different workaround, such as the one suggested by Eric Link
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/505085/comments/13
(2) disable the low disk space check and warning - if your disk is nearly full, you'll have to keep an eye on it yourself
(3) possibly disable other housekeeping functionality - when experiencing additional side effects, it might be a good idea to feed them back to the community

Of course, this is still a (somewhat unsatisfactory) workaround, and we're eagerly awaiting an actual fix from the upstream gnome-settings-daemon maintenance team.

[Ric Flomag (ricflomag)]

Why not fix this bug just by running the house keeping thread with an appropriate ionice priority ?

Anyone able to test this ?

[Ric Flomag (ricflomag)]

Anyway, this bug will be solved when this one https://bugzilla.kernel.org/show_bug.cgi?id=12309 (Large I/O operations result in poor interactive performance and high iowait times) is solved... But it might be wiser not to wait and find an alternative solution, as the former bug is three years old...

[Mark Ellis (mark-mpellis)]

The attached patch checks if max_age and max_size are both -1, ie thumbnail cleaning is disabled, before scanning the thumbnail dirs. This enables the performance hit to be removed through a simple configuration option.

Please apply this patch in ubuntu, it doesn't really fix the problem, but at least allows it to be disabled easily, without disabling the entire housekeeping process. I've also submitted it upstream, where it will probably gather dust for years.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "patch to properly allow disabling of thumbnail cache cleaning" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Sebastien Bacher (seb128)]

@Cedric: no the fix is not released to Ubuntu yet, please keep the status as it is

[Cedric Elslander (cedric-elslander)]

@Sebastien: sorry for that

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-settings-daemon - 3.8.5-0ubuntu6

---------------
gnome-settings-daemon (3.8.5-0ubuntu6) saucy; urgency=low

  * debian/patches/git_thumbnail_cleaning_use_less_ios.patch:
    - Optimise for "do nothing" when cleaning thumbnails (lp: #505085)
 -- Sebastien Bacher <email address hidden> Fri, 04 Oct 2013 18:21:45 +0200

[Lukas Winter (webmaster-geloescht)]

This is not really fixed, just can be worked around by some obscure setting now. Voting to re-open.