Bugzilla Bug 186610

Anytime I emerge --sync, emerge --metadata, emerge any package, or run
etc-update, the emerge process goes out to lunch.

CPU usage is not unusually high, but a process does appear in the list 

find . -iname ._cfg????_* ! -iname .*~ ! -iname .*.bak 

This appears as if it's searching the whole hard drive every time. 

I've tried wiping out the /var/portage/edb cache and then emerge --metadata but
that did not help.



Reproducible: Always

Steps to Reproduce:
1.emerge --anything
2.run etc-update will also duplicate

ark ~ # emerge --info
Portage 2.1.2.9 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r4,
2.6.21-gentoo-r4 i686)
=================================================================
System uname: 2.6.21-gentoo-r4 i686 Intel(R) Xeon(TM) CPU 3.00GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Wed, 25 Jul 2007 09:00:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.3 [disabled]
dev-java/java-config: 1.3.7, 2.0.30
dev-lang/python:     2.3.5-r3, 2.4.4-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.3
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.23b
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -mtune=prescott -march=prescott -pipe -fomit-frame-pointer -msse3"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/bind /var/qmail/alias
/var/qmail/control /var/vpopmail/domains /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -mtune=prescott -march=prescott -pipe -fomit-frame-pointer
-msse3"
DISTDIR="/usr/portage/distfiles"
FEATURES="candy distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/
ftp://ftplib.cc.gatech.edu/pub/gentoo"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl berkdb bitmap-fonts cli cracklib crypt curl dri fortran gd gdbm gocr
gpm iconv imap ipv6 isdnlog libg++ midi mmx mudflap mysql ncurses nls nptl
nptlonly objc openmp pam pcre perl pppd python readline reflection session spl
sse ssl tcpd truetype-fonts type1-fonts unicode x86 xorg zlib"
ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1
emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m
maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="r128"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Created an attachment (id=126019) [details]
use find <path> instead of find .

It should only be running the command on the ones listed in CONFIG_PROTECT. 
Maybe of those paths doesn't exist and causes the cd command to fail.  If
that's the problem, then this patch should fix it.  If you save it as
/tmp/find.patch then it can be applied like this:

patch /usr/lib/portage/bin/emerge < /tmp/find.patch

After patching the file as you recommended, (thanks for the quick response
btw), I did an emerge --sync just to test.

After I received the Updating Portage Cache: 100% ... it hung there again.

The process in use right now is:

find /var/vpopmail/domains -iname ._cfg????_* ! -iname .*~ ! -iname .*.

I did update my qmail/vpopmail setup recently, but I am not sure how it
relates..

Problem is still occurring.

Apparently there's something different about /var/vpopmail/domains.  You can
add CONFIG_PROTECT="-/var/vpopmail/domains" to make.conf in order to negate
that one.

awesome. that did the trick.

How would I back trace the problem and find out what the cause was?

I don't mind the config_protect workaround, it's quite handy thanks :)

See Bug 118410 + Bug 162348, sticking a dir where all mail is kept to
CONFIG_PROTECT is just completely whacky, it kills any usage of
etc-update/dispatch-conf as well.

Could you expound a little on your statement?

I thought I was putting /var/vpopmail/domains into CONFIG_PROTECT ... not
taking it out??

Also, the ebuild itself adds 99vpopmail to /etc/env.d which also has the
CONFIG_PROTECT value set. For some reason it was not being sourced in.

After hard-setting it in /etc/make.conf the problem is solved. Are you saying
that there is a better way?

(In reply to comment #7)
> Could you expound a little on your statement?

vpopmail ebuild is broken, not portage.

You can say that again. Ok I'm going to close then since nothing more
productive here. 

Bottom line was that portage was scanning a huge directory that it should not
have been scanning and the fix was to hard-set that directory in /etc/make.conf

Reopen to dupe.

*** This bug has been marked as a duplicate of bug 162348 ***