From owner-freebsd-doc@FreeBSD.ORG Fri Dec 28 00:39:59 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 2D58BC9E for ; Fri, 28 Dec 2012 00:39:59 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx1.freebsd.org (Postfix) with ESMTP id C27318FC0A for ; Fri, 28 Dec 2012 00:39:58 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id gb23so10464930vcb.28 for ; Thu, 27 Dec 2012 16:39:57 -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=C51JFh226mXMA3+JJEFhTezROifDxaL/OZUlOtpGcmQ=; b=K/pJtHOrlV9FTAfqZIhgpo5bmgG8jrXskLFzPbwgMer6/fvhRwcr2d4/Kn9XLBqWyG E75ZDe67sCQ29DsTydtyDEJ6zDay4zIEFgMi1u2p06W585X1qUi+0vdzauAQPluRiyGs vSxoD1LDK8uEhSbQe7CspLk13klE5WIYwu8W4= 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=C51JFh226mXMA3+JJEFhTezROifDxaL/OZUlOtpGcmQ=; b=LTc38ivvmXnkopzetRo416g7eaz8gYhxcvX9KMeKr2AeWVfwW+EMRc7vdhGlYQ33QK ARDtnjB6wcWtx37zWxCJmRMc2d12CawchYmZPDSF5UEy/zbaXpLs0AEEjIoJNv/hjwNr Y5oSdAFFQB5kpqvRmWkiilNd2qAZWSDC/KSzJ6O3yGZdw5OEIwMDTRjMMsIipo+iWbB1 aaGpSXubRwdfS7E67F/kdVkLbKK97dJzERwsuKXpVNFhIBk660K+OjaORxgGlnEsZeN1 lPfZznM29DWKnGN+qJKasH57WoGT6gI52rvJu+6yr+EyXa6kIU3NFSKwT/pQDqemTtTU 85Iw== MIME-Version: 1.0 Received: by 10.52.17.208 with SMTP id q16mr42922803vdd.46.1356654800817; Thu, 27 Dec 2012 16:33:20 -0800 (PST) Received: by 10.220.205.6 with HTTP; Thu, 27 Dec 2012 16:33:20 -0800 (PST) In-Reply-To: References: <201212252241.qBPMfN9K028994@red.freebsd.org> Date: Thu, 27 Dec 2012 16:33:20 -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: ALoCoQmQRpEqiKlGFOtk7INkG4qcnNqNLzcrovlkiy8Ygg1L52kpfcaBkwSETCWREpF3u+Hq5r4K 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:39:59 -0000 On Thu, Dec 27, 2012 at 4:18 PM, Peter Wemm wrote: > 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? 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