lockf in installworld -- not a good idea

[Robert Watson]

> 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

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?

Robert N M Watson
Computer Laboratory
University of Cambridge