Re: FreeBSD, autom4te and locking on NFS

[Noah Misch]

Hi,

This patch revamps {Autom4te,Automake}::XFile::lock.

On Thu, Apr 27, 2006 at 06:46:54PM +0200, Ralf Wildenhues wrote:
> Invocation of autom4te fails currently on FreeBSD with NFS-mounted
> directories:
> | ../build-alpha-unknown-freebsd6.0/tests/autoconf
> | autom4te: cannot lock autom4te.cache/requests with mode 2 (perhaps you are 
> running make -j on a lame NFS client?): Operation not supported

Your report illustrates three problems in the existing code:

1) flock(2) of FreeBSD 5 and newer fail with EOPNOTSUPP when the file is on an
   NFS mount and `rpc.lockd' is not running locally.  We should ignore
   EOPNOTSUPP whenever we would ignore ENOLCK.

2) Locking problems do not deserve the status of fatal errors in tools like
   Autoconf and Automake.

3) The error message may note `make -j' when that plays no part.

I believe I lack an Automake copyright assignment; is an Autoconf assignment
sufficient, given that this file is present in both projects?  The patch applies
to Autoconf with `patch -p1' or to Automake with `patch -p3 -d lib/Automake'.

Is this suitable?


2006-04-27  Noah Misch  <address@hidden>

        * lib/Autom4te/XFile.pm (lock): Allow EOPNOTSUPP, besides ENOLCK.  Do
        not raise fatal errors.  Only mention `make -j' when applicable.

diff -Nurp -X dontdiff ac-clean/lib/Autom4te/XFile.pm 
ac-xfile_lock/lib/Autom4te/XFile.pm
--- ac-clean/lib/Autom4te/XFile.pm      2005-05-14 03:00:39.000000000 -0400
+++ ac-xfile_lock/lib/Autom4te/XFile.pm 2006-04-27 23:52:33.000000000 -0400
@@ -218,22 +218,27 @@ sub lock
   my ($fh, $mode) = @_;
   # Cannot use @_ here.
 
-  # On some systems (e.g. GNU/Linux with NFSv2), flock(2) does not work over
-  # NFS, but Perl prefers that over fcntl(2) if it exists and if
-  # perl was not built with -Ud_flock.  Normally, this problem is harmless,
-  # so ignore the ENOLCK errors that are reported in that situation,
-  # However, if the invoker is using "make -j", the problem is not harmless,
-  # so report it in that case, by inspecting MAKEFLAGS and looking for
-  # any arguments indicating that the invoker used -j.
-  # Admittedly this is a bit of a hack.
-  if (!flock ($fh, $mode)
-      && (!$!{ENOLCK}
-         || (exists $ENV{'MAKEFLAGS'}
-             && " -$ENV{'MAKEFLAGS'}" =~ / (-[BdeikrRsSw]*j|---?jobs)/)))
+  # Unless explicitly configured otherwise, Perl implements its `flock' with 
the
+  # first of flock(2), fcntl(2), or lockf(3) that works.  On some systems
+  # (e.g. GNU/Linux with NFSv2), flock(2) fails with ENOLCK when used on a file
+  # located on a NFS mount.  On FreeBSD 5 and later, flock(2) and fcntl(2)
+  # locking over NFS fail with EOPNOTSUPP if `rpc.lockd' is not running.  We
+  # only report these errors if $ENV{MAKEFLAGS} suggests that a parallel
+  # invocation of GNU `make' has invoked the tool we serve.
+  #
+  # On Unicos, flock(2) and fcntl(2) over NFS hang indefinitely when `lockd' is
+  # not running.  We do not attempt to work around this problem.
+  if (!flock ($fh, $mode))
     {
+      my $nfs_note = "";
       my $file = $fh->name;
-      fatal ("cannot lock $file with mode $mode "
-            . "(perhaps you are running make -j on a lame NFS client?): $!");
+
+      $nfs_note = " (perhaps you are running make -j on a lame NFS client?)"
+       if (exists $ENV{'MAKEFLAGS'}
+           && " -$ENV{'MAKEFLAGS'}" =~ / (-[BdeikrRsSw]*j|---?jobs)/);
+
+      error ("cannot lock $file with mode $mode" . $nfs_note . ": $!")
+       if $nfs_note or not $!{ENOLCK} || $!{EOPNOTSUPP};
     }
 }