A command equivelent to: emerge -ufD --newuse world &; emerge -uaDv --newuse world; was used (i.e. two instances of emerge were running concurrently) and the second instance of emerge gave the following error: """ These are the packages that I would merge, in order: Calculating world dependencies |waiting for lock on /var/cache/edb/dep/aux_db_key_temp.portage_lockfile waiting for lock on /var/cache/edb/dep/aux_db_key_temp.portage_lockfile Traceback (most recent call last): File "/usr/bin/emerge", line 3112, in ? if not mydepgraph.xcreate(myaction): File "/usr/bin/emerge", line 1384, in xcreate myeb=portage.portdb.xmatch("bestmatch-visible",mydep) File "/usr/lib/portage/pym/portage.py", line 5527, in xmatch myval=best(self.xmatch("match-visible",None,mydep=mydep,mykey=mykey)) File "/usr/lib/portage/pym/portage.py", line 5538, in xmatch myval=match_from_list(mydep,self.xmatch("list-visible",None,mydep=mydep,mykey=mykey)) File "/usr/lib/portage/pym/portage.py", line 5524, in xmatch myval=self.gvisible(self.visible(self.cp_list(mykey))) File "/usr/lib/portage/pym/portage.py", line 5622, in gvisible myaux=db["/"]["porttree"].dbapi.aux_get(mycpv, ["KEYWORDS"]) File "/usr/lib/portage/pym/portage.py", line 5358, in aux_get mydata[auxdbkeys[x]] = mylines[x] IndexError: list index out of range """ This is hardly a critical bug as simply rerunning emerge worked fine, but a bug is a bug. My `emerge info` : """ Portage 2.0.51.22-r1 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6 .11.12 x86_64) ================================================================= System uname: 2.6.11.12 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.12 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.9 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-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-mtune=athlon64 -march=athlon64 -O2 -frename-registers -fweb -fomit-fram e-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share /config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kd e/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/s hare/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/g eneric/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/q mail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mtune=athlon64 -march=athlon64 -O2 -frename-registers -fweb -fomit-fr ame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X aac aalib acpi alsa apache2 artworkextra avi bash-completion berkdb bitmap-fonts bzip2 cdr crypt curl dvd encode fam ffmpeg firefox flac font-serve r freetype ftp gdbm gif gimp gpm gstreamer gtk gtk2 imagemagick imlib java jp2 j peg junit kde kdeenablefinal libcaca libg++ libwww lzw lzw-tiff mad mikmod mng m otif mozilla mozsvg mp3 mpeg mpeg4 mplayer msn mysql ncurses nptl nptlonly odbc ogg oggvorbis opengl pam pdflib perl php png postgres python qt quicktime readli ne rtc ruby samba sdl slang speex spell spl ssl svg tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales videos vim vorbis w ma123 wmf wxwindows xine xml2 xmms xpm xrandr xscreensaver xv xvid zlib userland _GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS """
portage is known to not play well in parallel
Brian, I think this is a race that wasn't picked up in your lockless flat caching. P1: Write first half of cache file P2: Do mtime checks and find no problems P2: Read cache file P1: Write second half of cache file
For what it's worth: Since the stable version of portage was upgraded (can't remember exactly when, over a month at least) I've not seen this problem occur. I could of just been lucky, but it's possible that this bug isn't present in Portage-2.0.51.22-r3.
This isn't in anyway related to the cache, this is/was a failed lock on auxdbkeys (ebuild.sh generation). Note the myauxdbkeys[x] = myline[x] within portdbapi.aux_get; doesn't ever touch the actual cache, mylines is a var only used when reading in the tmp dump from ebuild.sh Points at the fs not supporting required locking offhand, since the lock/unlock code is properly placed in the doregen block.
Yep, looks like you might be right. aux_get() is definitely locking correctly, so it must be something beneath there. The lockf() code is simple for it not to be that, which leaves the hardlink_lockfile() code. Looking closely at it, there appears to be a few races there.
*** This bug has been marked as a duplicate of 121819 ***
