gam_server consumes lots of cpu time

Bug #36581 reported by Martin J. Bligh on 2006-03-25
92
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gamin
New
Medium
gamin (Fedora)
Won't Fix
Medium
gamin (Ubuntu)
Low
Unassigned

Bug Description

gam_server pegs the cpu and drags the whole laptop to a crawl.

This is easy to reproduce - get a compact flash card full of camera pictures.
Put it in CF-PCMCIA adaptor ($10) and plug it into the PCMCIA slot of a
laptop. Mount the resultant drive (/dev/hda1 for me) and copy the files off.
Now watch top.

That level of cpu usage is unacceptable. You can't remove the gamin package
because gnome depends on it for some inane reason.

I have this issue on my system too. gamim 0.0.25 on Fedora Core 3/AMD64.

My workaround is sending a SIGSTOP (killall -19 gam_server), which will freeze
the gam_server thread. As soon as the copy process has finished, I send a
SIGCONT (killall -18 gam_server) again. gam_server then works just as expected,
consuming just very few CPU time.

I hope this bug will be found soon. It's rather annoying. :)

I'm running 32-bit fedora Core 3, with all the latest updates according to
'yum', and was getting the 99% CPU usage by gam_server after I added some
pictures to one directory, and added some symlinks to some scripts in
.gnome2/nautilus-scripts/ which I then used to play with those images. All the
tricks above didn't work (including restarting it several times), but then I
upgraded to 0.0.26-1, restarted, and everything went back to normal.

I got the upgrade from:
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/

$ rpm -qf /usr/libexec/gam_server
gamin-0.0.25-1.FC3.i386

I'm seeing the issue described in comment 98. I'll attach the debug output
generated by sending the daemon SIGUSR2.

Created attachment 114906
gamin debug output

The strace output is looping like as below:

stat64("/usr/local/share/applications/defaults.list", 0xbfffe70c) = -1 ENOENT
(No such file or directory)
open("/usr/local/share/applications/defaults.list",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or
directory)
stat64("/home/jorton/.local/share/applications/mimeinfo.cache", 0xbfffe70c) =
-1 ENOENT (No such file or directory)
open("/home/jorton/.local/share/applications/mimeinfo.cache",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or
directory)
stat64("/home/jorton/.local/share/applications/defaults.list", 0xbfffe70c) = -1
ENOENT (No such file or directory)
open("/home/jorton/.local/share/applications/defaults.list",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or
directory)

try to update to 0.0.26 which fixes crashes and CPU consumption, or even
better 0.1.0 which also fixes a bunch of other problems.

Daniel

Do you have a copy of this built for FC3 somewhere?

> Do you have a copy of this built for FC3 somewhere?
There should be an FC3 update if gamin-0.1.0 fixes problems. However, there is
not fot the moment. You can just do an rpmbuild from the src.rpm.

For Daniel: I noticed that the following files disappeared from gamin-devel in
version 0.1.0:

/usr/lib64/libfam.la
/usr/lib64/libgamin-1.la

and this breaks things with libtool.
Therefore, upgrading FC3 to 0.1.0 for me is a no-no.

At the risk of being just another "me too", I'm getting this for the first time
after upgrading to FC4 (from 3). gamin-0.1.3-1.FC4.i386.rpm

Not sure what ths USR2 trick everyone's on about is; didn't do anything for me.

In a week, I've caught it twice, once I strace'd it cuycling through an infinite
loop of a directory's contents, the second gave zero output in strace.

Should this bug still be tagged "devel"?

I am seeing excessive CPU usage often with the Ubuntu packes of 0.1.5
(0.1.5-0ubuntu1) also. gam_server regularly goes fubar and consumes 99% CPU
time. It's highly irritating, it's come to that point that I have cron job that
kills it every 15 minutes automatically.

Anyway, I tried the SIGUSR2 trick and got the ouput, is there any other useful
info I should attach here? I can't attach with gdb to the running process since
everything is compiled without the debug option.

Here's the output when debugging is turned on for gam_server,
http://albin.abo.fi/~ninylund/dump/gamin-debug/gamin_debug_Op1icj
http://albin.abo.fi/~ninylund/dump/gamin-debug/gamin_debug_Oszxi0
http://albin.abo.fi/~ninylund/dump/gamin-debug/gamin_debug_dFcUS5

Interesting... Are non Fedora/Red Hat gamin bugs OK here? Nikalus - did you
really reproduce this problem with Red Hat's rawhide or did you just choose that
because there was nothing else?

Oh bummer, didn't think about that this is redhat's bugzilla. There was just a link on gamin's homepage
that took me here.

I guess I didn't use rawhide, since I've never heard of such a thing.

I see this as well, on my one processor Thinkpad laptop. I haven't noticed a
pattern that triggers the excessive CPU consumption, I just occasionally
notice the CPU usage meter in my system tray get pegged at 100% (either all
user time or all system time, the latter is probably gam_server calling poll
in a tight loop).

This bug is "interesting".

Originally there was a bug that caused gamin to really go into a tight 100% cpu
loop, looping over a circular list. However, we now believe that the circular
list bug is fixed, and other reports of this is mainly about gamin using lots of
CPU when polling a large directory or when getting lots of change events from
dnotify (e.g. when downloading something fast).

It would be nice if people seeing this could try to determine what sort of
problem they are seeing. I.E. When this happens, attach to gamin (with debuginfo
installed) and see if its just spinning over one particular list forever.

What version do you think it was fixed in? Last one I investigated was comment#107

This happenned to me in FC4 with gamin-0.1.0-1.1. CPU usage would peg for a
while, then be normal for a while, on the order of 30 to 90 seconds.

I was running an application that reads and writes a couple large files at a
time for several minutes. I was watching the directory in File Browser and
clicked Reload in the browser several times, and deleted a few files at a time,
a few minutes before I noticed the CPU usage. The directory has about 220 files,
and is in the /data partition which is mounted under / It is a dual processor
system.

When I did kill -SIGUSR2 the CPU usage immediately went back to normal and
remained normal. I'm attaching the beginning of the debug file.

Created attachment 123024
beginning of gam_server log file

from FC4 gamin-0.1.0-1.1

I am seeing this problem with gamin-0.1.7-1.1 (FC5T2 + current rawhide).
I didn't have the debug package installed at the time. I will try to reproduce
and send gdb info.

I am seeing this bug a lot when I use konqueror under Gnome to browse for files
(ie: as a file manager) on my big NFS server. On a 2.4 P4 with 2GB of RAM it'll
go up to 70-90% CPU and stay there for dozens of seconds. It'll do this even
when I'm not doing anything with the folders that Konqueror is browsing.

It definitely is Konqueror triggering it because I don't use KDE apps normally,
and didn't used to, and never had this problem before. I'm not sure if the fact
I'm browsing a 2TB NFS server is exacerbating the problem.

FC3 gamin-0.1.1-3.FC3

This isn't just a FC bug:

http://www.gnusolaris.org/cgi-bin/trac.cgi/ticket/60
http://www.irclogs.ws/freenode/kde/30Oct2005/13.html

I just renamed and killed the gam_server binary and now all my gnome apps are
going nuts using 100% CPU:

27852 trevor 25 0 17664 3616 3120 R 16.7 0.2 0:44.11 gnome-settings-
30113 trevor 22 0 232m 65m 32m R 16.4 3.2 30:49.73 soffice.bin
10130 trevor 25 0 26320 8692 5360 R 14.4 0.4 1:34.74 gnome-panel
27932 trevor 25 0 19260 2484 2152 R 13.8 0.1 0:14.60 gnome-vfs-daemo
10674 trevor 25 0 142m 59m 15m R 13.1 2.9 13:41.91 galeon
27918 trevor 25 0 44808 5988 4832 R 12.8 0.3 1:00.80 nautilus

Seems to be stuck this way. As I kill those apps one by one the others take up
the slack to use up 100% CPU. Guess I have to restore the file.

The other thing, is I swear that over a week or two of an uninterrupted X
session that gam_server goes nuts more frequently. It may just be my perception
though.

Why is this 'file modification detection server' polling directories? This seems
to be suicide if there are large numbers of child nodes... why doesn't it just
listen to events fired by the kernel?

Some filesystems (i.e. NFS) don't fire events.

I saw this problem using 2.6.15-1.1833_FC4, gamin-0.1.1-3.FC4 . I was using
firefox-1.0.7-1.2.fc4 to download a 132 MB file from a server on our local 100
Mb lan. I am in gnome at the time. Here is a snippet from top:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11222 dacker 16 0 123m 52m 20m R 30.2 5.2 2:27.62 firefox-bin
11067 dacker 16 0 2464 1208 872 R 19.6 0.1 0:01.93 gam_server
11083 dacker 15 0 35116 17m 11m S 6.0 1.7 0:03.45 nautilus

This happens if I save the file to the desktop. If I save it to my home, things
get better:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11222 dacker 15 0 123m 52m 20m S 30.3 5.2 3:19.01 firefox-bin
11067 dacker 15 0 2464 1208 872 S 10.6 0.1 0:26.35 gam_server

175 comments hidden view all 196 comments
Sitsofe Wheeler (sitsofe) wrote :

Ah this old chesnut. For reference see this bug over in Red Hat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132354

Martin:

Could you follow http://www.gnome.org/~veillard/gamin/debug.html to get a debug log of gam_server when it happens and use Add Attachment to add it to this bug?

Matt Zimmerman (mdz) on 2006-04-12
Changed in gamin:
status: Unconfirmed → Needs Info
Frank Siegert (fsiegert) wrote :

Running Kubuntu Dapper up to date as of 2006-04-13, I see gam_server constantly at 15% CPU usage and echoing a lot of messages into ~/.xsession-errors (more than once a second):

    Failed to process 26 bytes from server
    invalid length 24902
    invalid length 24902
    invalid length 24902
    invalid length 24902
.... many many times ... and then:
    end from FAM server connection
    invalid length 24902
    invalid length 24902
    invalid length 24902
    invalid length 24902
    invalid length 24902
... many many times

Funnily enough, after a reboot I was not able to reproduce it (using a VFAT storage device, browsing pictures, whatever...). But then doing nothing while writing this bug report (except for a look at "less ~/.xsession-errors") suddenly gam_server went mad again. I don't know, if accessing ~/.xsession-errors could cause this problem, sounds too weird.

I followed the debugging instructions and sent gam_server a SIGUSR2, which produced a big file in /tmp, of which I will attach a few hundred lines, which seem to repeat afterwards. maybe it is of help to track this annoying bug.

Btw... There seem to be a few duplicates of this: #30868, #31329, #3814

These are some lines from the gamin_debug_* file that is created in /tmp when you send a SIGUSR2 to gamin_server.

geofs (geof) wrote :

When I use ktorrent (kde bittorent client), gam_server uses up to 25% cpu (athlon 1200Mhz, 512MB).

I also have the same .xsession-errors messages

9172 geof 15 0 3280 1948 896 S 21.4 0.4 2:20.12 gam_server
23409 geof 16 0 50784 23m 18m R 9.1 4.7 0:04.48 ktorrent
 5939 root 15 0 62000 43m 5076 S 5.8 8.6 10:22.64 Xorg
 6028 geof 15 0 31972 15m 12m S 1.9 3.1 4:24.30 kded

I can provide the /tmp/gamin_debug_* file on request.
I contains interesting things like this

inotify recieved 1 events
inotify: moved 1 events to event queue
inotify: got MODIFY on = /home/geof/.xsession-errors
inotify: Emitting Changed on /home/geof/.xsession-errors
inotify: Emitting Changed on /home/geof/.xsession-errors
Event to ktorrent : 1, 1, .xsession-errors Changed
Event to kded [kdeinit] : 194, 1, .xsession-errors Changed
inotify recieved 1 events
gam_incoming_conn_read called
accepted incoming connection: 8
Created connection 8
gam_client_conn_read called
failed to read() from client connection
Shutting down client socket 7

and

inotify recieved 68 events
inotify: moved 69 events to event queue
inotify: got MODIFY on = /home/geof/.xsession-errors
inotify: Emitting Changed on /home/geof/.xsession-errors
inotify: got IGNORED event for unknown wd 414637
inotify: got IGNORED event for unknown wd 414636
inotify: got IGNORED event for unknown wd 414635
(...)

But i can't say what all this stuff means yet.

geofs (geof) wrote :

Not very interesting but i saw the cpu usage jump to 30% for gam_server. The torrent download is now finished and just seeding one file. Perhaps it's a ktorrent related bug. btw gam_server shouldn't consume that much.

Frank Siegert (fsiegert) on 2006-04-30
Changed in gamin:
status: Needs Info → Confirmed
Daniel Hahler (blueyed) wrote :

I'm also experiencing this problem with Kubuntu-Dapper: it uses constantly about 40% CPU and produces the same .xsession-errors.

I don't know, what has been the cause, because a reboot would probably fix it again; killing gam_server does not: it gets restarted and produces the same errors.

I'm using a vanilla kernel (2.6.16.11), because of hibernation.

170 comments hidden view all 196 comments

I am seeing this on fc5 - and I don't use NFS at all. It is just
the default(?) LVM2 root with ext3 and boot with ext3, and a few sshfs/fuse
mounted.

169 comments hidden view all 196 comments
Haakon Nilsen (haakonn) wrote :

I too am being plagued by this. Using Kubuntu/Dapper (i386) on my AMD Athlon 64 3700+ system with 2GB ram, gam_server constantly consumes around 11.6% CPU according to top. It doesn't matter what applications are running or not. I tried to switch it to do polling on /* instead, which only tripled the CPU consumption. My .xsession-errors fills up with this:

invalid length 24902
end from FAM server connection
invalid length 24902
invalid length 24902
invalid length 24902
invalid length 24902
end from FAM server connection
invalid length 24902
invalid length 24902
invalid length 24902
...

I really hope this can get fixed in time for Dapper release, because it is quite annoying.

swoke (swoke) wrote :

I got the same problem.

This is quite boring.

I hope it will be fixed soon.

Daniel Hahler (blueyed) wrote :

It seems to be related to some KDE app, at least here. Perhaps KMail or Akregator, because twice already I've just closed some apps and CPU usage went down.

I'll look closer at which app fixes it next time.

Haakon Nilsen (haakonn) wrote :

>It seems to be related to some KDE app, at least here. Perhaps
>KMail or Akregator, because twice already I've just closed
>some apps and CPU usage went down.

I do run such apps as aKregator and amaroK. Closing amaroK did not change anything, but I didn't try aKregator. It's too late to try now, since I simply replaced the gam_server executable with a noop shell script to shut it up :-)

FroZtY (p-tommassen) wrote :

I also have this problem; shutting amaroK down solves it. According to the log files, amaroK is monitoring three paths:

/home/frosty (my home dir)
/etc/security
/etc/samba/smb.conf

The last two paths are monitored by nearly every KDE application, and they don't seem to create any problem. However, amaroK is the only program monitoring my ~, so it seems safe to assume that the problem lies here.

When monitoring the gamin debug output from amarok, it seems to report a change with .xsession_errors every time. This seems correct, as .xsession_errors is changed a lot, but it is changed by gam_server itself, filling it with the familiar messages:

invalid length 24902
 end from FAM server connection
 invalid length 24902
 invalid length 24902
 invalid length 24902
 invalid length 24902
 end from FAM server connection
 invalid length 24902
 invalid length 24902
 invalid length 24902
....

It seems that the solution can be found by stopping those messages from appearing, resulting in less frequent updates to .xsession_errors and thus, amusingly, in a lower CPU usage.

I hope this helps anybody in solving this bug.

Greetings.

Sebastien Bacher (seb128) wrote :

that would be an issue from amarok that should not monitor .xsession-errors, a music player has no need for that

Daniel Hahler (blueyed) wrote :

You are right, of course.

But somehow this seems to point out a design problem: any other app might monitor "~" and cause the same problem.

Sebastien Bacher (seb128) wrote :

so that app would be to fix too, stoping writing to logs because apps might monitor the log is not a reasonable option

Daniel Hahler (blueyed) wrote :

What about if gam_server (or whatever get the I-want-to-monitor-this requests) would ignore requests to ".xsession-errors"?

Anyway, is this the cause of the initial error ("invalid length 24902") anyway?

Martin J. Bligh (mbligh) wrote :

You can't expect to be able to isolate (and make exceptions for) every log file.

Gamin needs to do something sane (ie rate limit itself). Otherwise it will always be flaky as hell.

Sebastien Bacher (seb128) wrote :

gamin could use some work but note that's not used by Ubuntu on dapper so it's not a priority for the Ubuntu team at the moment, probably something that could be worked upstream though

Wolfgang Hoffmann (woho-woho) wrote :

Could you elaborate on that? http://packages.ubuntu.com/dapper/base/ubuntu-desktop lists gamin as required. I installed a kubuntu daily dapper-live-i386.iso of last week and have gamin installed by default, showing the above bug.

I cannot tell what triggers it, I tried to reproduce but failed, it happens randomly. I have neighter KMail nor Akregator running on this system.

Besides the CPU load, filling up .xsession-errors is a serious problem, mine is 114 MB right now.

mvisa (mikko-puolikuu) wrote :

Dapper Release Candidate:

 5274 foo 15 0 2940 1356 752 S 18.6 0.1 5199:33 gam_server

(constant 20% cpu)

-rw------- 1 foo bar 1679968547 2006-05-29 13:11 .xsession-errors

(1.6 GB)

Frank Siegert (fsiegert) wrote :

Seems to me like a major bug: Has a severe impact on a small (?) portion of Ubuntu users. If developers don't consider this as major, I apologize, and you can set it back to normal.

Sebastien Bacher (seb128) wrote :

as written before dapper doesn't use gam_server, but maybe kubuntu still uses it?

FroZtY (p-tommassen) wrote :

The only programs registered to gamin on my computer are KDE programs. While it indeed impacts Kubuntu users the most, I assume Ubuntu users that run some KDE programs are also affected by this.

An ugly workaround is to make .xsession-errors write-protected; it prevents the file from changing, and gam_server doesn't detect it as changing anymore. Of course, this solution is far from desirable if you need the log.

Frank Siegert (fsiegert) wrote :

What do you mean by "dapper doesn't use gamin"? edubuntu-desktop depends on it, as do many KDE apps in Kubuntu (like k3b, which is probably used by a few non-Kubuntu users as well). After all it is in main and many main-packages depend on it.

Is it possible that all these packages can use another file alteration monitor then gamin?

Sebastien Bacher (seb128) wrote :

I mean that gam_server is not used when you do an Ubuntu installation (ie: the one with GNOME), it doesn't mean the bug should not be fixed but that's just not a priority for the Ubuntu desktop team right now

Wolfgang Hoffmann (woho-woho) wrote :

I don't quite understand. Does the Ubuntu desktop team care only about Ubuntu, not Kubuntu?

If you do a standard Kubuntu 6.06 install, you're hit by this bug. This will concern many users, and should be a priority, I think. Otherwise Kubuntu CDs will ship with this bug ...

Sebastien Bacher (seb128) wrote :

what I call "desktop team" is people working on the GNOME desktop, that issue should be worked by the kubuntu team if that's a priority for them

Vyacheslav Rodionov (bepcyc) wrote :

This is a very annoying bug for laptop users ;(

I use latest packages of Kubuntu Dapper, but still have this issue.

Now I can't leave my laptop powered on for the whole night ;(

I guess that's a gamin's bug only not other programs, because sometimes I doesn't run any program but gam_server makes an activity.

Hop,e that bug will be fixed in Release. I don't really want to switch distro because of such a small bug ;(

This is debug output of gamin on a fresh kubuntu dapper drake flight 7 install:
root@rhee:/tmp# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=6.06
DISTRIB_CODENAME=dapper
DISTRIB_DESCRIPTION="Ubuntu (The Dapper Drake Release) Development Branch"
root@rhee:/tmp# uname -a
Linux rhee 2.6.15-21-386 #1 PREEMPT Fri Apr 21 16:43:33 UTC 2006 i686 GNU/Linux
root@rhee:/tmp#

I'm running into high CPU utilization by gamin, about 30%. KDE definitly seems to want to monitor a lot of stuff, but it really drags down performance.

Fuji (rfujimoto) wrote :

--I mean that gam_server is not used when you do an Ubuntu installation (ie: the one with GNOME), it doesn't mean the bug should not be fixed but that's just not a priority for the Ubuntu desktop team right now

It is in main, this software is supposed to be tested. Can this be reassigned then to whomever is in charge of "admin" or whomever this software is a priority for (Kubuntu devs maybe...)?

I've found I have to kill all konqueror's (or any application that will poll $HOME). When killing konq, remember to search for any preloaded ones.

Rocco Stanzione (trappist) wrote :

I now know why this is happening, at least to me. All my music is on a remote samba share, mounted under /mnt. AmaroK monitors the directory for changes using gamin. Gamin expects things under /mnt to be temporarily mounted, so instead of the MUCH more efficient kernel dnotify method of watching for updates, it actually polls all the files in the mounted directory every second. In my case, it probably can't even list all the files in one second, so it's constantly working as hard as it can, in userspace, to do its thing. I'm going to request (upstream) a compile-time option to specify the directory or directories to poll without dnotify, so we can package it as /media, where we expect our temporary mounts to be (the gamin author, I think, is a redhat guy, and expects them under /mnt). Changing to "needs info" because I wonder how many of the rest of you have a similar setup (directories with lots of files under /mnt) that would allow us to close this bug if we get the new compile-time option and a new package for it.

Changed in gamin:
status: Confirmed → Needs Info
Edu (martinez-bernal) wrote :

I have tons of mp3 in a fat32 partition, but amarok is not the only thing that makes gam_server eat cpu (in my case). It happens appartently with no reason. Of course, running amarok gam_server goes mad for sure.

Andre Heßling (ahessling) wrote :

I have a similar configuration.
Under /media I have mounted 3 ntfs partitions which have lots of files on it.
My entire music collection is located on one of the ntfs partition which is accessed by amarok and therefore apparently by gamin.
I am quite sure that I noticed high cpu usage one time after I copied a (small) file from one of my ntfs partition to my root partition using Krusader.

Tom Lawton (tlawton) wrote :

Brand new install of Kubuntu
No networked devices, nothing under /mnt at all
Root is xfs, /home is xfs, /boot is ext2 - all partitions on a single HD (400Gb Maxtor)

gam_server is constantly using ~16% CPU and repeatedly writing to .xsession-errors

Failed to process 26 bytes from server
invalid length 24902
invalid length 24902
invalid length 24902
invalid length 24902
invalid length 24902
Failed to process 26 bytes from server
invalid length 24902
invalid length 24902
invalid length 24902
invalid length 24902
invalid length 24902

etc

OR

invalid length 24902
invalid length 24902
invalid length 24902
invalid length 24902
end from FAM server connection
invalid length 24902
invalid length 24902
invalid length 24902
invalid length 24902
end from FAM server connection

This file is growing at a rate of about 1Mbyte every 10 minutes

I think this may be a separate bug to the original 'lots of files under /mnt' bug, but it's the same as a few people have mentioned above.

From my fresh-install kubuntu system with a rapidly-filling ~/.xsession-errors and gam_server on a constant 16% CPU

Gard Spreemann (gspreemann) wrote :

The same thing happens here (relatively fresh Kubuntu Dapper install). It seems to be brought on either by KTorrent, amaroK or both.
I replaced the gam_server executable with an empty shell script, so now my system behaves normally. Of course, various applications complain about a lacking FAM, but other than that, it seems fine.

I will be out of the office through Wednesday June 21st, 2006. I will
be back in the office on Thursday, June 22. If you require assistance,
please use the Systems Help Request Form:
http://intranet.mse.jhu.edu/forms/helprequest.php.

If you need immediate assistance please contact Mercy Anaba (x65306,
<email address hidden>), or phone the IT@JH Help Desk (x6-HELP). If it is an
emergency, please instruct the IT@JH Help Desk to contact the Library
Systems On-Call Pager.

>>> "<email address hidden>" 06/14/06 14:42 >>>

The same thing happens here (relatively fresh Kubuntu Dapper install).
It seems to be brought on either by KTorrent, amaroK or both.
I replaced the gam_server executable with an empty shell script, so now
my system behaves normally. Of course, various applications complain
about a lacking FAM, but other than that, it seems fine.

--
gam_server consumes lots of cpu time
https://launchpad.net/bugs/36581

matt_hargett (matt-use) wrote :

This bug is killing my laptop's battery life, generating heat, and making drive accesses slow. I'm not running amarok, ktorrent, or anything like that. I've got kontact and konq open to a web page and that's it.

 I'll give $50 to whomever fixes it and gets it into the KUbuntu 6.06 main repository.

matt_hargett (matt-use) wrote :

Adding the following lines to the /etc/gamin/gaminrc fixed this problem for me.

none /var/log/*
fsset ext3 notify
fsset ext2 notify

If anyone is using NFS, they'll have to uncomment the config line about NFS in there as well.

jmspeex (jean-marc-valin) wrote :

Until the problem is fixed, I think Ubuntu should include an option to just disable gamin without having to remove the binary. Considering the little benefit it provides (haven't really noticed a difference after removing it), gamin causes far more harm than it helps. Actually disabling it by default would be even better.

138 comments hidden view all 196 comments

See also bug 196444 with regards to constant 4% CPU usage for no reason and
*huge* mem leak. Probably related. Bugs confirmed in FC3, 4 and 5. gam_server
blows.

(In reply to comment #120)
> Some filesystems (i.e. NFS) don't fire events.

Perhaps, but even NFS must call though the kernel I believe.

Unless there is really some exception to this (even on newer kernels), it seems
like gam_server needs to switch into some kind of a callback mode and notify its
client via those messages... instead of polling directories. Retain the polling
mode for really old kernels, that's fine..

I ran a few tests. Killing all konqueror and any other KDE apps I could find
(there were none) didn't help. gam_server still eats a constant 3.5-4.5% CPU on
my 2.4 P4. I tried killing/restarting gam_server after that and it immediately
starts up again and still eats 3.5-4.5%. I can't easily umount my NFS as it's
used for important server processes.

Another possible common thread: another reporter says they have a 2TB fs
(local). I have a 2TB fs (non-local) mounted over NFS. Do other reporters have
large fs's? Also, I run SMP kernel.

I want to add a "me too":
RHEL4 on quad-cpu x86_64 server, I have a 2TB+ volume (over lvm2) as well,
gamin-0.1.1-3.EL4
gamin-0.1.1-3.EL4
I run NFS server, but there are also some directories NFS-mounted to this server.

I see I put myself in the cc-list in May, but honestly I haven't seen the problem
recently (on FC5, still only local LVM volumes < 80GB + sshfs/fuse mounts).
I assume that the bug has either been fixed since, or that I have somehow managed
to work around it - I have switched off nautilus in the session manager, for
example, since I don't use nautilus at all anyway.

Another "me too" here.
TwoDual core CPUs x86_64 workstation running 2.6.9-34 kernel (Red Hat Es 4
Workstation) with 8Gb RAM.
I have a couple of 2+Tb LVM arrays.
gam_server using 85-95% of one CPU.

Not sure when this issue started or what set it off.

Another "me too".
Dual Xeon fileserver running 2.6.9-34.0.1.ELsmp with 4Gb RAM. Attached to FC
SAN (multi-TB). Many other servers NFS-mount and CIFS-mount to this box.
gam_server using 80-95% of one CPU constantly.

me too.
gamin-0.1.1-4.EL4
thunderbird-1.5.0.10-0.1.el4.centos
kernel-2.6.9-42.0.8.EL

i used to see this alot on a prior system running courier-imap. running dovecot
on this one. wasn't seeing the gam_server hang much recently until recent yum
update when among others thunderbird upgraded (to above) from
thunderbird-1.5.0.9. now i frequently find gam_server eating all available CPU.
 kill it, and it immediately gets respawned. kill thunderbird, and gam_server
quiets down. relaunch thunderbird and things are fine again for a couple days.
 if you want more info let me know what would be helpful.

Changed in gamin:
status: Needs Info → Unconfirmed

This is not a "Medium" problem - it is a very severe problem. In years of
running Linux, I have never seen a package perform like this - its practically
a virus.

gam_server constantly causes problems, and I must renice it. It seems to have a
terrible interaction with KDE. This has been going on for too long, a package
needs to be created to remove this software or it needs to be fixed!

This is not a medium bug - just do a google search on gam_server!!!!!

i have reduced the effects of this bug by (1) every 15 minutes launch a cron job
to renice all gam_server processes to bottom priority, and (2) backout
thunderbird from 1.5.0.10 to 1.5.0.9, which seems for whatever reason to far
less frequently encounter the bug. but of course, the bug remains.

Gamin is up to version 0.1.9 now in F8 and rawhide; F7 has 0.1.8, and even RHEL4
has been updated as far as 0.1.7. Older distro releases are EOL/in maintenance
support at best (i.e. go grab an SRPM and update it yourself) There have been
no new reports added to this bug in half a year. I personally haven't seen it
in *years*. Is anyone experiencing this with a semi-current version of gamin?
Or can we finally close this one?

We have just begun upgrading our compute farm to RHEL4 and we are seeing this
problem.

We have a fairly complex NFS setup with several netapps volumes.

I'm not the sysadmin, so I don't have root access.

To give a little insight, we have set up a single machine with freenx and are
using it for our local site session server. I am only paying attention to this
machine right now, but I know that other RHEL4 machines have had issues prior to
this when users were starting VNC sessions before the freenx transition.

We did not have this problem with RHEL3.

lngl0116:/home/kbingham-> rpm -qf /usr/libexec/gam_server
gamin-0.1.7-1.2.EL4
gamin-0.1.7-1.2.EL4

Here are the contents of the gaminrc file:
lngl0116:/home/kbingham-> more /etc/gamin/gaminrc
# configuration for gamin
# Can be used to override the default behaviour.
# notify filepath(s) : indicate to use kernel notification
# poll filepath(s) : indicate to use polling instead
# fsset fsname method poll_limit : indicate what method of notification for the
filesystem
# kernel - use the kernel for notification
# poll - use polling for notification
# none - don't use any notification
#
# the poll_limit is the number of seconds
# that must pass before a resource is polled again.
# It is optional, and if it is not present the
previous
# value will be used or the default.

fsset nfs poll 10 # use polling on nfs mounts and poll once
every 10 seconds

Not all users are seeing this run out of control:

lngl0116:/home/kbingham-> ps -eaf | grep gam_server
ssirun 1096 1 0 2007 ? 00:05:31 /usr/libexec/gam_server
hsales 2055 1 0 Jan02 ? 00:00:56 /usr/libexec/gam_server
szanatta 2882 1 0 Jan03 ? 00:00:11 /usr/libexec/gam_server
dreed 3710 1 0 Jan03 ? 00:00:22 /usr/libexec/gam_server
jkoller 3801 1 0 2007 ? 00:00:12 /usr/libexec/gam_server
jlawson 6022 1 0 Jan04 ? 00:01:40 /usr/libexec/gam_server
wstrickl 8332 1 36 Jan05 ? 11:33:38 /usr/libexec/gam_server
nphillip 9248 1 0 2007 ? 00:00:41 /usr/libexec/gam_server
nmysore 13140 1 55 Jan04 ? 1-04:11:33 /usr/libexec/gam_server
rkhan 13352 1 0 2007 ? 00:01:54 /usr/libexec/gam_server
bonfanti 23065 1 0 Jan03 ? 00:00:21 /usr/libexec/gam_server
bcruiksh 24066 1 0 Jan03 ? 00:00:08 /usr/libexec/gam_server
mbarnes 24673 1 0 Jan02 ? 00:00:20 /usr/libexec/gam_server
bgreiner 24736 1 54 Jan04 ? 1-01:59:05 /usr/libexec/gam_server
kbingham 25283 1 0 Jan05 ? 00:00:01 /usr/libexec/gam_server
kbingham 25419 21283 0 15:28 pts/4 00:00:00 grep gam_server
mfalkinb 26903 1 0 Jan05 ? 00:00:01 /usr/libexec/gam_server
lphillip 27510 1 0 Jan04 ? 00:00:38 /usr/libexec/gam_server
jkeefer 29207 1 48 Jan05 ? 18:10:39 /usr/libexec/gam_server

Any suggestions?

UPDATE to my comment #135:

We did not see this previously:

http://kbase.redhat.com/faq/FAQ_85_11914.shtm

Our sysadmin is doing the upgrade to gamin-0.1.7-1.4.EL and we will see if we
have any additional issues.

2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 09:40:21 EST 2007 x86_64 x86_64 x86_64
GNU/Linux

Sorry, Wes - I'm running 0.1.9 on a production server and experience the runaway
problem.

gam_server will behave for a few hours - sometimes a few days.

I wrote a custom daemon that uses the fam-2.7.0 library. gam_server is, of
course, required by fam.

As a temporary solution a cron job now stops my daemon. Doing this is not
enough, however. I still have to kill gam_server, and then restart my daemon.
(I'm a little worried about the effect of killing gam_server in the midst of
some operation).

Is there a better alternative? My daemon monitors a few directories and
triggers actions when files appear. gam runs in polling mode because I don't
want to re-build the kernel on the production box. Maybe this isn't a problem
if it runs from the kernel?

I've tried the config file trick:

/etc/gamin/gaminrc:

fsset ext3 poll 5

Still, no joy.

Changed in gamin:
status: Unknown → Fix Committed
Changed in gamin:
status: New → Triaged
Changed in gamin:
status: Unknown → New

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Changed in gamin (Ubuntu):
importance: High → Low

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in gamin (Fedora):
status: Fix Committed → Won't Fix
Changed in gamin:
importance: Unknown → Medium
Changed in gamin (Fedora):
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 196 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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