Date: Mon, 1 Mar 2010 06:31:18 -0800 From: David Wolfskill <david@catwhisker.org> To: xorquewasp@googlemail.com Cc: freebsd-hackers@freebsd.org Subject: Re: package building failure irritation Message-ID: <20100301143118.GL22824@bunrab.catwhisker.org> In-Reply-To: <20100301135829.GB2219@logik.internal.network> References: <20100226163227.GA15162@logik.internal.network> <4B88074E.7050007@FreeBSD.org> <20100226222113.GA14592@logik.internal.network> <4B884D48.90509@FreeBSD.org> <20100227093409.GA40858@logik.internal.network> <864ol0w4g5.fsf@ds4.des.no> <20100301135829.GB2219@logik.internal.network>
next in thread | previous in thread | raw e-mail | index | archive | help
--HTLCc13+3hfAZ6SL Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 01, 2010 at 01:58:29PM +0000, xorquewasp@googlemail.com wrote: > On 2010-03-01 14:34:50, Dag-Erling Sm=F8rgrav wrote: > > % fgrep 'Directory not empty' inkscape.txt=20 > > rmdir: /work/ports/devel/boost-libs/work: Directory not empty > > ... > > rmdir: /work/ports/x11-toolkits/pangomm/work: Directory not empty > >=20 > > This tells me that either there is another build running in parallel, or > > /work is mounted from a dodgy NFS server. >=20 > 'Lo, >=20 > There's certainly no parallel building going on, but /work is nullfs > mounted (from ZFS). Could this cause the above? Caveat: this may be a "red herring." But please note that for stable/7 prior to r190970 (2009-04-12 10:43:41 -0700) or head prior to r189287 (2009-03-02 12:51:39 -0800; prior to stable/8 branch, so it's part of stable/8 already), there was a rather nasty (IMO, as I spent a fair amount of time trying to figure out what was going on) such that a FreeBSD NFS client would see precisely the above symptoms if: * A process on the FreEBSD NFS client performed a chdir() to a directory that was NFS-mounted, then started a "recursive descent" (e.g., "tar c ..." or "rm -fr") from that directory and * Some other process on the same FreeBSD NFS client attempted to perform an unmount() of the NFS-mounted file system referenced above. Note that the unmount() is doomed, as the file system is active -- a directory in it is the $cwd for the first process, after all. This may seem an unlikely -- possibly even perverse -- combination of events. However, it is actually SOP for amd(8): the master amd process periodically forks a child to perform an attempted unmount of auto-mounted NFS file systems periodically, and the way amd realizes that the file system is not eligible for unmounting is if the attempted unmount() gets EBUSY. It is *possible* that something akin to this mechanism *might* be affecting the OP. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --HTLCc13+3hfAZ6SL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkuLz7UACgkQmprOCmdXAD3jywCdFY72Z4zTwLYcF0pb07700V0B WlcAn3Aaq4sK5vN7zq36ONOoIvooUGxG =9orG -----END PGP SIGNATURE----- --HTLCc13+3hfAZ6SL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100301143118.GL22824>