security/nss build failure under poudriere, "symlink creation race", head -r363590 FreeBSD and head -r543636 ports

[Mark Millard]

On 2020-Jul-30, at 23:11, Tatsuki Makino <tatsuki_makino at hotmail.com> wrote:
> 
> Hmmm, I was using 2 builders by -J 2:4. But I don't remember if there
> were other jobs available when nss was building :)
> How is your poudriere set up for NO_ZFS? I'm using it with NO_ZFS=yes.

I do not have any media with ZFS in use in any of the systems that
I have access to. I instead use UFS in all of them. So I use
NO_ZFS=yes .

> And BASEFS exists within UFS.

For my context that got the problem, there is
only UFS [ignoring the efi partition contents
and the swap partitions].


Other choices in my poudriere configuration on the
cortexA57 system that are different than in
/usr/local/etc/poudriere.conf.sample :

USE_TMPFS=no
SAVE_WRKDIR=yes
WRKDIR_ARCHIVE_FORMAT=tar
ALLOW_MAKE_JOBS=yes
ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* gcc* llvm* ghc* *webkit* *office* chromium* iridium* mongodb*"
NOHANG_TIME=14400
BUILD_AS_NON_ROOT=no

(ALLOW_MAKE_JOBS_PACKAGES is just in case I temporarily
disable ALLOW_MAKE_JOBS for some reason.)

> I'm suspicious of gmake and UFS on this issue. But I don't know the
> details of that :)

I've no clue what to blaim for the race, other than the
retry logic that will never retry. (I do not claim to
know that such a retry would be appropriate.)


I forced poudriere to rebuild the same set of ports to
try the "large load average" context again. nss built
fine. (llvm10 and llvm11 are still building.)

Even trying to establish if MAKE_JOBS_UNSAFE use made
a difference would be problematical: failure is rare
without MAKE_JOBS_UNSAFE in my context.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)