Date: Fri, 29 Sep 2006 18:08:02 +0400 From: Ruslan Ermilov <ru@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea Message-ID: <20060929140802.GH4776@rambler-co.ru> In-Reply-To: <20060929144738.W70454@fledge.watson.org> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--+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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060929140802.GH4776>