I have all gentoo related stuff on their own automounted volumes under /gentoo, one for distfiles, one for building and one for ccache. The automounter is started with the -g (ghost) option. When I want to emerge something, I allways get this message: # emerge kuroo Calculating dependencies ...done! >>> emerge (1 of 4) dev-perl/DateManip-5.42a-r1 to / chgrp: `/gentoo/ccache': No such file or directory When I hit CTRL-C and restart, the ccache volume is mounted and emerge works. Reproducible: Always Steps to Reproduce: 1. Setup automounted ccache volume. 2. emerge something while ccache volume is not yet mounted -> hangs. 3. Hit CTRL-C and restart emerge -> volume is now mounted -> works. Expected Results: Should emerge w/o hanging. Portage 2.0.51.21-r1 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11.8 i686) ================================================================= System uname: 2.6.11.8 i686 Intel(R) Pentium(R) M processor 1500MHz Gentoo Base System version 1.6.11 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.5-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/gentoo/distfiles" FEATURES="autoconfig ccache distlocks nosandbox sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/" LINGUAS="de" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/gentoo/build" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/gentoo/build/overlay" SYNC="rsync://louisa.europe.nokia.com/gentoo-portage" USE="x86 X Xaw3d aalib acl alsa apm arts avi bash-completion berkdb bitmap-fonts bluetooth bonobo caps cddb cdparanoia cdr chipcard crypt cups dlloader doc dv dvd emacs emboss fam font-server foomaticdb ftp gd gdbm gif gnokii gphoto2 gpm gstreamer gtk2 gtkhtml guile hardened hbci icq ieee1394 imagemagick imap imlib irda jpeg kde kdexdeltas koffice-plugin lcms ldap libg++ libwww lm_sensors mad maildir mbox mime motif mp3 mpeg mule ncurses nls no-old-linux noantlr nobcel nobeanutils nobsh nocommonslogging nocommonsnet nojdepend nojsch nojython nolog4j nooro noregexp norhino noxalan noxerces nptl nptlonly objc ofx ogg oggvorbis opengl pam pcre pdflib perl perlsuid pg-intdatetime pic pie png postgres ppds pwdb python qt quicktime rdesktop readline savedconfig slang sms spell sql sse ssl subversion svga tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts unicode usb vim-with-x vorbis wifi wxwindows xine xml2 xmms xosd xprint xscreensaver xv zlib linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, MAKEOPTS
and what would you propose be done to 'fix' this ?
This is an autofs cache issue. The first time after autofs is set up, the chgrp call works. Afterwards it fails. chown and chgrp use the fts functions to traverse a directory structure. These functions are optimizing this task by doing a chdir in every directory and then reading the entries. We can modify chown and chgrp to not do this chdir stuff, this makes the chown and chgrp call work, but this is no real solution. We're losing speed and this chown/chgrp issue is in my oppinion a minor one that does not qualify for such a change. I'm currently debugging the kernel side to see if we can fix it this way.
For reference, after a fresh autofs setup: luna ~ # stat /misc/ccache File: `/misc/ccache' Size: 149 Blocks: 0 IO Block: 4096 directory Device: 301h/769d Inode: 128 Links: 5 Access: (2775/drwxrwsr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-05-11 20:11:17.573339798 +0000 Modify: 2005-05-11 18:17:03.377099379 +0000 Change: 2005-05-11 19:57:55.832619548 +0000 luna ~ # umount /misc/ccache luna ~ # stat /misc/ccache File: `/misc/ccache' Size: 0 Blocks: 0 IO Block: 4096 directory Device: fh/15d Inode: 6779354 Links: 2 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-05-11 20:19:01.460390231 +0000 Modify: 2005-05-11 20:18:53.670480792 +0000 Change: 2005-05-11 20:18:53.670480792 +0000 luna ~ # stat /misc/ccache File: `/misc/ccache' Size: 149 Blocks: 0 IO Block: 4096 directory Device: 301h/769d Inode: 128 Links: 5 Access: (2775/drwxrwsr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-05-11 20:11:17.573339798 +0000 Modify: 2005-05-11 18:17:03.377099379 +0000 Change: 2005-05-11 19:57:55.832619548 +0000 The 301h/769d device is the correct one. As you can see the second stat call returns the virtual ccache directory that autofs created to serve as a mountpoint. And the chdir call from chgrp fails because it is doesn't really exist. No portage issue, re-assigning to kernel team.
Looks like an upstream issue, we don't modify autofs at all. If you have finished investigating the problem, the best bet would be to file a bug at http://bugzilla.kernel.org for it.
