From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 14:08:06 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0425916A47C; Fri, 29 Sep 2006 14:08:06 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A20B43D6E; Fri, 29 Sep 2006 14:08:03 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id B042B5F4A; Fri, 29 Sep 2006 18:08:01 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 76C585F29; Fri, 29 Sep 2006 18:08:01 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8TE82Sv005624; Fri, 29 Sep 2006 18:08:02 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 18:08:02 +0400 From: Ruslan Ermilov To: Robert Watson Message-ID: <20060929140802.GH4776@rambler-co.ru> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QwZB9vYiNIzNXIj" Content-Disposition: inline In-Reply-To: <20060929144738.W70454@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 14:08:06 -0000 --+QwZB9vYiNIzNXIj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 02:49:36PM +0100, Robert Watson wrote: >=20 > On Fri, 29 Sep 2006, Ruslan Ermilov wrote: >=20 > >The necessity to run rpc.lockd is documented in the build(7) manpage.=20 > >Quote: >=20 > I think this is a bad idea. rpc.lockd is one of the most fragile and=20 > largely broken pieces of the operating system. Arguably we shouldn't eve= n=20 > be shipping it. Making it required for installworld is asking for troubl= e. >=20 > >: installworld Install everything built by a preceding buildworld st= ep > >: into the directory hierarchy pointed to by make(1) va= ri- > >: able DESTDIR. > >: > >: If installing onto an NFS file system, make sure that > >: rpc.lockd(8) is running on both client and server. S= ee > >: rc.conf(5) on how to make it start at boot time. > > > >>I've noticed an increasing intolerance in our tools for system install= =20 > >>and maintenance to locking not being implemented over the past few year= s.=20 > >>I no longer get working cron on boxes with neither rpc.lockd nor local= =20 > >>locking enabled, for example. Installworld represents a bigger problem= ,=20 > >>since I don't want to have to depend on a completely working rpc chain = in=20 > >>order to installworld, nor depend on running in what would effectively = be=20 > >>multiuser mode. Surely there's a better fix for this than adding lockf= =20 > >>use? > >> > >I don't know of a better fix. Another approach is that mentioned in the= =20 > >commit log and used by NetBSD. I tried it, and it was very fragile -- i= t=20 > >could easily leave the temporary file around, and that would stuck forev= er=20 > >another instances. > > > >The problem at hand is that multiple instances of install-info(1) are=20 > >attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you ha= ve=20 > >a better idea, don't hesitate to let me know. I'd very much like to get= =20 > >rid of that as well. >=20 > The basic problem here is that install-info doesn't support parallelism.= =20 > Sounds like we just need to accept that and therefore accept that we don'= t=20 > support doing installworld with the -j argument. A middle-ground solutio= n=20 > would be to only use lockf if -j is used. >=20 How could it support parallelism without using lockf(3) or equivalent? I'd be happy to hack install-info(1) if there's a way. A middle-ground solution was easy to implement, and I have a patch for it if a more clean solution couldn't be found. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --+QwZB9vYiNIzNXIj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHSjCqRfpzJluFF4RAvHtAKCV/esGthroxAdAt9Kkw68xpodkHgCdE1hi jOvAVArmctu87803OL5j6no= =TuK/ -----END PGP SIGNATURE----- --+QwZB9vYiNIzNXIj--