Re: autoconf hangs due to autom4te.cache and NFS problem on AIX

[Bob Proulx]

Chris Pickett wrote:
> >You would need to find the process that has the file open and deal
> >with it (probably by killing it) first.  Using tools such as 'fuser'
> >and 'lsof' or their equivalents on your system can be useful here.
> 
> ~/test $ rm -rf autom4te.cache
> rm: cannot remove directory `autom4te.cache': File exists
> ~/test $ ll autom4te.cache/
> total 12K
> -rw-r--r-- 1 pickett xxx 12K Feb 23 10:39 .nfsD1831
> ~/test $ rm autom4te.cache/.nfsD1831
> ~/test $ ll autom4te.cache/
> total 12K
> -rw-r--r-- 1 pickett xxx 12K Feb 23 10:39 .nfsE1831

Right.  Exactly as desribed.  The nfs client believes there is an open
file descriptor to that file and therefore renames it instead of
removing it.  You can move it elsewhere, such as out of that
directory, and then the directory will be empty and can be removed.
If the directory itself is busy such as with the current working
directory of a process then repeat with the directory itself.

> ~/test $ fuser autom4te.cache/.nfsE1831
> autom4te.cache/.nfsE1831:
> ~/test $ fuser autom4te.cache/
> autom4te.cache/:
> ~/test $ fuser -d -u -V autom4te.cache/.nfsE1831
> autom4te.cache/.nfsE1831:

I have seen that too.  I don't know why one behavior indicates an open
file with an active process and another one refuses to show anything
for it showing that there aren't any.

I didn't say that the system would help you out and tell you good
information.  All NFS users have a rich environment to whine about
problems.  It is a target rich environment.

> ~/test $ fuser -d -u -V autom4te.cache/
> autom4te.cache/:
> 
> ~/test $ lsof
> -bash: lsof: command not found

Well, I did say "or equivalents".  I think lsof is more closely
associated with systems supporting /proc but don't really know the
history of it.  Using fuser is probably your only choice.  I don't
know if that needs root access on your system to provide meanful
information or not.  Also, I seem to recall needing the -m option on
other systems.

> I have nothing else besides login processes running.  It is possible 
> that root has something, but I don't know what it is.
> 
> ~/test $ ps auxww | grep root | grep nfs

I doubt the process would be named "*nfs*" anything.  It is more
likely to be one of the tools called by scripts such as grep, sed,
awk, and so forth.  Since you ran the autotools scripts the process
should be owned by you.  (The security model of the system will
prevent you from escalating your privilege to a root process.)

> >As a first pass I would try using a local directory instead of over
> 
> Yes, building in /tmp works,

A good data point.  Since the local disk works it definitely confirms
nfs as being involved with the problem.

> but since I need NFS access the .autom4te.cfg trick is better for me.

Sure.  I understand.  But unfortunately it does tie in the vendor nfs
of the system into the problem.  That is an "immovable object".  Can
you provide an "irresistible force" to oppose it?  :-)

More seriously if this can be narrowed down to the exact details that
trigger this problem then workarounds might be applied.  But this is
probably going to need to be left in your hands to do debug since you
have the test case for it.  Any help you can provide to expose details
is appreciated.

Bob