FreeBSD web build failed on red.freebsd.org

[Peter Wemm]

On Thu, Dec 27, 2012 at 4:13 PM, Peter Wemm <peter at wemm.org> wrote:
> On Thu, Dec 27, 2012 at 8:16 AM, Simon L. B. Nielsen <simon at freebsd.org> wrote:
>> On 25 December 2012 22:41, World Wide Web Owner <www at freebsd.org> wrote:
>>> install -C   -o www -g wwwadm -m 664 /w/www/build/head/en_US.ISO8859-1/htdocs/releases/4.8R/relnotes-i386.html /usr/local/www/www.freebsd.org/data/releases/4.8R
>>> ===> releases/4.9R
>>> install -C   -o www -g wwwadm -m 664 /w/www/build/head/en_US.ISO8859-1/htdocs/releases/4.9R/announce.html /usr/local/www/www.freebsd.org/data/releases/4.9R
>>> install -C   -o www -g wwwadm -m 664 /w/www/build/head/en_US.ISO8859-1/htdocs/releases/4.9R/hardware.html /usr/local/www/www.freebsd.org/data/releases/4.9R
>>> install: wwwadm: Invalid argument
>>> *** Error code 67
>>
>> Hey Peter,
>>
>> There have been a fair number of build failures like this recently. I
>> wonder if there could be a race in the generation of the group file
>> where it's invalid ?
>
> I don't think so.. here's what it does:
>
> if (!sysopen(MGR, "/etc/group", O_RDWR | O_EXLOCK | O_NONBLOCK)) {
> ..
> sysopen(NGR, "/etc/group.new", O_RDWR | O_CREAT | O_TRUNC, 0644) ...
> ..
> copies unmanaged things to group.new, and adds managed things to group.new
> ...
> rename("/etc/group.new", "/etc/group") || die "Could not rename
> /etc/group.new to /etc/group: $!";
> close(MGR);
> close(NGR);
>
> So at no point should there ever be an invalid /etc/group file.  The
> lockf on group is what happens when you vi it.
>
> The libc code only seems to be able to throw an EINVAL if something
> like strtoul(3) can't parse an integer in a numeric base it
> recognizes.  I've been scratching my head trying to guess where an
> EINVAL might come from but I don't see it..  There should never ever
> be a case where the groups file is partially complete.

The only remaining thought that occurred to me (just moments after I
hit send) is that the updater always updates the file even when there
are no changes.  It should actually compare for changes and abandon
the new one if there's nothing different.  But that doesn't seem like
it could cause this unless there's a race in UFS or something.

After rename, the old group file would get unlinked, then unlocked. it
shouldn't be possible for any changes to happen on a persistent open
fd on the old group file after unlock.

But, copy-rename shouldn't cause this sort of thing.

Oh the other thing that occurred to me.. I wonder if there's a NIS
relic on that network or machine.. perhaps the groups stuff is finding
a fragment of the old NIS and blowing up?
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE