It looks like a lot of people runing 64-bit Gentoo on AMD64 systems have a problem that famd process starts using 100% of CPU power. You can read more about the problems in this forum topic:
For me the problems begin most frequently when I have Krusader open (in /usr/doc/ in one panel) while doing "emerge world". But this is not the only time it happens. I then have to restart the famd service to get it back to normal.
Steps to Reproduce:
1. open Krusader or Konqueror
2. go to /usr/doc
3. start emerge world
Frequently famd starts using 100% CPU
famd should never use 100% CPU
Portage 2.0.51-r8 (default-linux/amd64/2004.3, gcc-3.4.3,
glibc-188.8.131.5241102-r0, 2.6.9-gentoo-r10 x86_64)
System uname: 2.6.9-gentoo-r10 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.6.8
Python: dev-lang/python-2.3.4 [2.3.4 (#1, Dec 18 2004, 17:14:05)]
ccache version 2.3 [enabled]
sys-devel/autoconf: 2.59-r6, 2.13
sys-devel/automake: 1.8.5-r2, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.3
CFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -frename-registers"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -frename-registers"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
USE="X acpi alsa amd64 apm arts avi berkdb bitmap-fonts cdr crypt cups curl dvd
dvdr encode esd exif f77 fam fbcon flac foomaticdb fortran ftp gdbm gif gnome
gphoto2 gpm gstreamer gtk gtk2 imagemagick imlib ipv6 jabber jp2 jpeg kde libwww
lzw lzw-tiff mad mikmod motif mozilla mpeg multilib ncurses nls nptl oggvorbis
opengl oss pam pdflib perl png posix ppds python qt quicktime readline samba
scanner sdl slang slp speex spell ssl tcltk tcpd tetex theora tiff truetype
unicode usb userlocales videos xml xml2 xmms xosd xpm xrandr xv xvid zlib
This is also happenening to me at least once a day. Everytime my computer (AMD64) slows down.. I look over and famd is using 100% again. Although I do not use Krusader, the time that this happens to me most is using Konqueror while browsing an nfs drive. I will click on a file or move a file and it just causes an overload in famd. Any information needed, I will gladly provide.
this is not amd64 specific, happened to me on various machines (x86 and amd64), I stopped using famd for that reason
try gamin.. fam is coming to an end.
Yes, gamin looks good, but as far as I can tell, there are no stable builds for ANY arch for gamin.. that seems a little too early to jump in for me. Since it is a mature prog, fam(d) should be stable, and certainly be more stable than it is if it is marked as such in the portage tree. Something that crashes daily for a LOT of people (see forums for many topics on this) should be worked out, or fam should be marked as '~' , IMO of course.
well investigate it then, be my guest.
I've not used fam itself for quite some time, but I do know it's main problem is it using dnotify & locking, not 100% cpu usage as you report. I bet thats a problem origination somewhere else : app, kernel, etc.
Found some info here:
Don't know if this helps but this bug is getting annoying.
i have the same problem here on x86-32 (P4). It happens 2-3 times a month, and I have to restart famd...
Happening dayly here too (x86 Athlon-XP). Googleing show this happening for other dists too.
Will shut down this PITA software and try my lucks with Gamin instead. Perhaps time to make a Gamin not ~arch if it actually works and drop FAMD in general?
Havening the same problem here on a Athlon-XP.
Any news about how to solve this?
Is it possible to log some output of famd? Does anyone know about that?
>>> Any news about how to solve this?
is an stupid answer to this bug, isn't it?
(In reply to comment #11)
> "Try gamin."
> is an stupid answer to this bug, isn't it?
If you have better advice for the people experiencing this problem,
please share it with us.
(In reply to comment #12)
> If you have better advice for the people experiencing this problem,
> please share it with us.
Well, first, experience the overheating issues on a server with famd, and then,
suggest us for a production server to emerge a masked package again...
doesn't it sucks?
I don't have better advice, only suggestions... And I will shut up them.
Thank you very much for nothing at all.
upstream problem, bug already exists.
The only realistic solution is the one in comment #3 & #10; there just is zero
progress on FAM, go with gamin. The ~arch-ness of gamin has to do with the
inotify backend API changes over time, the newest version (0.1.2) is the most
likely candidate to be stabilized pretty soon now inotify has landed in the
kernel. The other backends should do just fine if you do not have inotify.