From owner-freebsd-doc@FreeBSD.ORG Fri Dec 28 00:18:19 2012 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC51EA00 for ; Fri, 28 Dec 2012 00:18:19 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mx1.freebsd.org (Postfix) with ESMTP id 698B98FC13 for ; Fri, 28 Dec 2012 00:18:19 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id fl11so10368663vcb.15 for ; Thu, 27 Dec 2012 16:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fHBpDyeMyBTpPvjOo9CJaUGhRvTRtMB8N2GeN0iletU=; b=wUip4rUTGn2A1Ni5qAMd6aTNou/XxEfLFoUF3bvohz23ud3DU0HOMnSzGC6fpglz6q Ers/2PYtMwQ0WiZ/d9Y8qkSn5f4x5yJYh8f+ovIC8zoH76J59xQx66rZtVx1B0bvzeGM qGOCVRrunyJU6ueBnQ+YMYH40+IZtYwaSXEII= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=fHBpDyeMyBTpPvjOo9CJaUGhRvTRtMB8N2GeN0iletU=; b=DfyaHq6sfgQIPkdx1xOB7q6pvFh9MywuLH0wh/fIF55D2St3ms1advTQFzhqgqGAoS km20ePDP9AcS0nEZRpN3j9Vhphes7wqUryfDe59Mz8u0/STOory4753zzgI+BFQ1C7Ji rcGwo0xlyO4BvBl7NCoHBB3kpF4wQA8NUxcdAboxOwYKyVLX1UPvoCP3veB83pYmrcCN +3zFOAzuwIpFj4ZcTSO++4N0uqqeA+5EDrQAt6QU3lr1VTSJOy5pP4KKJbgl5ZRrg5+x 1E484ZshgCbL3KmkiLygjflGG6tZdxDq7xdaiI/T39uG8VWTq6F+ajX/E4weqh5NKixj 3P4A== MIME-Version: 1.0 Received: by 10.52.27.138 with SMTP id t10mr43865411vdg.81.1356653898636; Thu, 27 Dec 2012 16:18:18 -0800 (PST) Received: by 10.220.205.6 with HTTP; Thu, 27 Dec 2012 16:18:18 -0800 (PST) In-Reply-To: References: <201212252241.qBPMfN9K028994@red.freebsd.org> Date: Thu, 27 Dec 2012 16:18:18 -0800 Message-ID: Subject: Re: FreeBSD web build failed on red.freebsd.org From: Peter Wemm To: "Simon L. B. Nielsen" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn2ZDV+foq240+ycU8DvgMT/UJeu61f70akgFQus7gzyoAaVUT+xH7rHnUC7icbPl9SD2Rb Cc: freebsd-doc@freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 00:18:20 -0000 On Thu, Dec 27, 2012 at 4:13 PM, Peter Wemm wrote: > On Thu, Dec 27, 2012 at 8:16 AM, Simon L. B. Nielsen wrote: >> On 25 December 2012 22:41, World Wide Web Owner 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@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