Bug 162535 - startup is extremely slow when famd is running
Summary: startup is extremely slow when famd is running
Alias: None
Product: digikam
Classification: Unclassified
Component: Database-Scan (show other bugs)
Version: 0.9.4
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2008-05-23 20:28 UTC by Thomas Eschenbacher
Modified: 2017-07-25 13:19 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.9.5


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Eschenbacher 2008-05-23 20:28:42 UTC
Version:           0.9.4-beta4 (using KDE 3.5.9)
Installed from:    Gentoo Packages
OS:                Linux


I have a quite large photo collection and everytime I start digiKam, it stays at the splash screen (reading database) for several minutes without showing and progress. A "strace" shows that it is going through all the directoriesof my album, but extremely slow.

But as soon as I stop "famd", even during the startup phase, digiKam immediately starts to come up within few seconds!

So I guess that there is some incompatibility between digiKam and famd!? (I use fam-2.7.0)

Without famd -> startup within less than 10 seconds. 
With famd -> startup takes several minutes.

Is that a known problem? 

kind regards,
Comment 1 Marcel Wiesweg 2008-05-24 15:49:22 UTC
Digikam is setting up a KDirWatch to monitor the directories it manages for added/removed files while it is running. That's all digikam is doing: Add a directory to the KDirWatch object.

KDirWatch from kdelibs can use different methods to watch files, one of them famd.

There has been a bug report about too many open file descriptors when using IIRC the inotify method, but I am not aware of a famd problem. Digikam is pushing the boundaries of dir watching by creating many watches, but from within digikam we cannot do too much about it. Kdelibs decides to use fam, and obviously this takes so much time. You can verify this by commenting out the three lines in digikam/albummanger.cpp containing "d->dirWatch->addDir"
Comment 2 Thomas Eschenbacher 2008-05-24 20:25:54 UTC
great, thank you for that hint!

A strace of the digikam confirmed that it was the KDirWatch that was setting up many connections to famd and then blocks for a long time. It seems that kdelibs are able to use other methods automatically if the necessary tools are installed in the system, but don't complain in any way if not.

I installed the packages "inotify-tools" and "dnotify" and now the startup of digiKam is like "instant-on" :-)

IMHO you can set the state of this bug to "RESOLVED".
Comment 3 caulier.gilles 2008-05-24 21:39:37 UTC

Just to be sure, What are debug messages printed on the console by digiKam, just after the startup ? 

Gilles Caulier
Comment 4 Thomas Eschenbacher 2008-05-25 09:18:13 UTC
Hello Gilles,

I now already have re-compiled kdelibs without fam support, so digiKam now only prints out one line with "Found dcraw version: 8.83" - nothing else, sorry.

But I remember that before (with fam) I saw strace output like "KDirWatch setup FAM (Req <x>) for <some_directory> ...", with "x" counting up to some high number (about 256) until it blocked. ("ulimit -n" gives 1024 on my system, so it shouldn't be a out-of-filehandle situation?).

Comment 5 caulier.gilles 2008-12-05 21:59:27 UTC

What's news with this report ?

Gilles Caulier
Comment 6 Thomas Eschenbacher 2009-01-01 11:26:15 UTC
Hi Gilles,

there is nothing new from my side.

As I already said (see comment #2), it already works fine for me and I had no reason to do any further investigation.