Re: lockf in installworld -- not a good idea

On Fri, Sep 29, 2006 at 02:20:06PM +0100, Robert Watson wrote:
> 
> >revision 1.72
> >date: 2005/11/03 08:56:39;  author: ru;  state: Exp;  lines: +1 -0
> >Serialize access to the info/dir file; needed for parallel installs.
> >
> >Reported by:    scottl
> >
> >I'm not very fond of using the non-standard lockf(1) here, but I
> >have no better idea at the moment.  NetBSD uses ln(1) to create a
> >lock file, but this approach can result in a deadlock if make is
> >interrupted, leaving an orphaned lock file.
> 
> I'm not sure why this suddenly showed up in my configuration, but this is 
> preventing me from installing world on an NFS mounted file system without 
> rpc.lockd running.  I get the following:
> 
> ===> lib/libcom_err/doc (install)
> lockf -k /usr/share/info/dir  install-info --quiet  
> --defsection="Programming &
> development tools."  --defentry="* libcom_err: (com_err).        A Common 
> Error
> Description Library for UNIX."  com_err.info /usr/share/info/dir
> lockf: cannot open /usr/share/info/dir: Operation not supported
> *** Error code 73
> 
> Stop in /zoo/rwatson/netperf/RELENG_6/src/lib/libcom_err/doc.
> *** Error code 1
> 
> Stop in /zoo/rwatson/netperf/RELENG_6/src/lib/libcom_err.
> *** Error code 1
> 
The necessity to run rpc.lockd is documented in the build(7)
manpage.  Quote:

: 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.


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer