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: http://forums.gentoo.org/viewtopic.php?t=257289 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. Reproducible: Sometimes Steps to Reproduce: 1. open Krusader or Konqueror 2. go to /usr/doc 3. start emerge world Actual Results: Frequently famd starts using 100% CPU Expected Results: famd should never use 100% CPU emerge info Portage 2.0.51-r8 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-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] dev-lang/python: 2.3.4 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 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -frename-registers" CHOST="x86_64-pc-linux-gnu" 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 /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -frename-registers" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" 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 linguas_en linguas_sl"
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: http://oss.sgi.com/bugzilla/show_bug.cgi?id=158 http://oss.sgi.com/projects/fam/mail_archive/200301/msg00011.html 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? Try gamin.
"Try gamin." 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.