Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Dec 2012 16:33:20 -0800
From:      Peter Wemm <peter@wemm.org>
To:        "Simon L. B. Nielsen" <simon@freebsd.org>
Cc:        freebsd-doc@freebsd.org
Subject:   Re: FreeBSD web build failed on red.freebsd.org
Message-ID:  <CAGE5yCoKwKOkA7iZuUiaZ-y1TrYP6tft%2BsVhPjAZFe=7OpHZrg@mail.gmail.com>
In-Reply-To: <CAGE5yCoRi17E%2BuqTqxYbt=PvDhp1Q95N6BEnzBvmamFh=QvpdQ@mail.gmail.com>
References:  <201212252241.qBPMfN9K028994@red.freebsd.org> <CAC8HS2GXUGfeNhf3eO_hNg5hx04YFF2Kq7cHE0wxd0MkDy1qxw@mail.gmail.com> <CAGE5yCot44-6xWT3AYTO_Zmcth7rtRmo=CjnMD5MVrXfAnOD=g@mail.gmail.com> <CAGE5yCoRi17E%2BuqTqxYbt=PvDhp1Q95N6BEnzBvmamFh=QvpdQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 27, 2012 at 4:18 PM, Peter Wemm <peter@wemm.org> wrote:
> On Thu, Dec 27, 2012 at 4:13 PM, Peter Wemm <peter@wemm.org> wrote:
>> On Thu, Dec 27, 2012 at 8:16 AM, Simon L. B. Nielsen <simon@freebsd.org> wrote:
>>> On 25 December 2012 22:41, World Wide Web Owner <www@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?

Hmm. A YP/NIS operation fails with EINVAL.  rpcbind was running on the machine.

I changed:

rc.conf:
 turned off rpcbind (and killed it)
 turned off nfs_client_enable (it wasn't running anyway)

nsswitch.conf:
 removed groups_compat: nis (and services_compat and passwd_compat)
 replaced "compat" in groups/services/passwd with "files".

There should be no opportunity for accidental NIS exposure now unless
there's a chroot involved.

peter@red:/home/peter % cat /etc/nsswitch.conf
group: files
hosts: files dns
networks: files
passwd: files
shells: files
services: files
protocols: files
rpc: files

Hmmmmm. I wonder if there's a partial write buffered before that
rename.. I will check.


-- 
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGE5yCoKwKOkA7iZuUiaZ-y1TrYP6tft%2BsVhPjAZFe=7OpHZrg>