lockf in installworld -- not a good idea

[Ruslan Ermilov]

On Fri, Sep 29, 2006 at 02:49:36PM +0100, Robert Watson wrote:
> 
> On Fri, 29 Sep 2006, Ruslan Ermilov wrote:
> 
> >The necessity to run rpc.lockd is documented in the build(7) manpage. 
> >Quote:
> 
> I think this is a bad idea.  rpc.lockd is one of the most fragile and 
> largely broken pieces of the operating system.  Arguably we shouldn't even 
> be shipping it.  Making it required for installworld is asking for trouble.
> 
> >: installworld     Install everything built by a preceding buildworld step
> >:                  into the directory hierarchy pointed to by make(1) vari-
> >:                  able DESTDIR.
> >:
> >:                  If installing onto an NFS file system, make sure that
> >:                  rpc.lockd(8) is running on both client and server.  See
> >:                  rc.conf(5) on how to make it start at boot time.
> >
> >>I've noticed an increasing intolerance in our tools for system install 
> >>and maintenance to locking not being implemented over the past few years. 
> >>I no longer get working cron on boxes with neither rpc.lockd nor local 
> >>locking enabled, for example.  Installworld represents a bigger problem, 
> >>since I don't want to have to depend on a completely working rpc chain in 
> >>order to installworld, nor depend on running in what would effectively be 
> >>multiuser mode.  Surely there's a better fix for this than adding lockf 
> >>use?
> >>
> >I don't know of a better fix.  Another approach is that mentioned in the 
> >commit log and used by NetBSD.  I tried it, and it was very fragile -- it 
> >could easily leave the temporary file around, and that would stuck forever 
> >another instances.
> >
> >The problem at hand is that multiple instances of install-info(1) are 
> >attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you have 
> >a better idea, don't hesitate to let me know.  I'd very much like to get 
> >rid of that as well.
> 
> The basic problem here is that install-info doesn't support parallelism. 
> Sounds like we just need to accept that and therefore accept that we don't 
> support doing installworld with the -j argument.  A middle-ground solution 
> would be to only use lockf if -j is used.
> 
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,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20060929/47e47ee4/attachment.pgp