gamin polls non-existent files and directories

[Dmitriy Kropivnitskiy]

gam_server is continuously polling the hard drive for a few non-existant
locations. In particular:
$HOME/Templates
$HOME/.local/share/applications/defaults.list
$HOME/.local/share/applications/mimeinfo.cache
/usr/local/share/applications/defaults.list

After doing some debugging and reading some docs on gamin I am fairly sure that
the problem related to kernel support of inotify.
In absence of inotify support (and extended attributes for supported file
systems) gamin server resorts to polling as method of
querying the file system. As a result, it keeps querying the hard drive and
prevents the machine going into low power mode.
I suggest adding the inotify patch to the kernel and have file systems mount
with extended attributes by default.
Will build a custom kernel, test and report results.

[Sebastien Bacher (seb128)]

the inotify support is planned but not sure of when. Jeff, some details on this ?

[Jeff Waugh (jdub)]

Seb: inotify support should be in the new 2.6.9 kernel in hoary. However, in the
absence of inotify support, gamin should be using dnotify.

[Jeff Waugh (jdub)]

I am, however, seeing the same issue. Turns out we don't have inotify headers
available, but it builds the inotify backend anyway. I'll check what's up with
that. But even on our normal dnotify-enabled 2.6, it shouldn't be polling.

[Jeff Waugh (jdub)]

Okay, silly me, this makes sense whether we're using inotify or dnotify. They
can't monitor non-existent files, so gamin has to poll. DV would accept a patch
that monitors the closest existing parent directory, and drills down as new
directories appear. It's kinda tricky to do well, though.

That said, I'll leave this as major - it has a dramatically bad effect on power
usage. :-)

[Sebastien Bacher (seb128)]

reassigning gamin bug to Jeff

[Dmitriy Kropivnitskiy (nigde)]

After a few more experiments, I have concluded, that I was mistaken. The source
of the disk activity seems to be dbus-1 daemon and not gamin. The hard drive
light keeps flashing (and disk IO counters register activity) even when I am
logged out and GDM is stopped, and these disk requests only stop when dbus-1 is
stopped. At the moment I disabled dbus-1 in the startup, but obviously, my
hotplu devices are no longer recognized and mounted. I didn't see any other ill
effects from disabling dbus, but supposedly more and more programs will rely on
it in the future.

[Dmitriy Kropivnitskiy (nigde)]

Here, a quick trace of hald shows that it polls the cdrom drive every two
seconds or so:

20:58:51 gettimeofday({1106618331, 708401}, NULL) = 0
20:58:51 poll([{fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}, {fd=8, events=POLLIN}], 5, 1990) = 0
20:58:53 gettimeofday({1106618333, 697901}, NULL) = 0
20:58:53 gettimeofday({1106618333, 698039}, NULL) = 0
20:58:53 poll([{fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}, {fd=8, events=POLLIN}], 5, 0) = 0
20:58:53 open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 3
20:58:53 ioctl(3, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
20:58:53 close(3) = 0
20:58:53 time(NULL) = 1106618333
20:58:53 gettimeofday({1106618333, 710010}, NULL) = 0
20:58:53 poll([{fd=6, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}, {fd=8, events=POLLIN}], 5, 1989) = 0
20:58:55 gettimeofday({1106618335, 698546}, NULL) = 0
20:58:55 open("/dev/hdc", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 3
20:58:55 ioctl(3, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
20:58:55 close(3) = 0
20:58:55 time(NULL) = 1106618335

[Matt Zimmerman (mdz)]

This is hal checking whether you have inserted a CD, and is perfectly normal.
It also should not result in any disk activity, since it is not touching any
files on disk.

However, with some CD-ROM drives, the kernel prints an error message when hal
polls, which would be logged to disk. Please attach the output from the "dmesg"
command

[Dmitriy Kropivnitskiy (nigde)]

Looks like my HD activity LED is wired in such a way, that activity on any IDE
device causes it to blink. I wonder though if constnat requests on the CDROM
would prevent the system from going into sleep mode?

[Dennis Kaarsemaker (dennis)]

Do any of the bugs reported here still occur in Breezy?

[Carthik Sharma (carthik)]

Thank you for reporting this bug.

and now, does this bug still bug you in the latest Dapper?

[Corey Burger (corey.burger)]

Dmitriy, closing this due to lack of recent information. If you can reproduce it in the latest dapper, please feel free to reopen this bug. Thanks.