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

[Bob Proulx]

Chris Pickett wrote:
> Yes I can reproduce this, and it happens with a fresh version of the 
> automake-1.10.1 distribution.

If you can deduce what process is hanging that would be useful
information.  ps *should* show you what processes are running and one
of those would be the culprit.

> On the other hand, when I try to run autoreconf --install on my actual 
> project, it hangs running aclocal and autom4te, although aclocal does 
> respond to SIGINT.

You might also try a job control sigstop with ^Z.  I have experienced
times when jobs could not be interrupted but could be stopped.  (shrug)

> Note that I've had autoconf working on this system for about a year, 
> this only started happening recently... something changed, somewhere.
> 
> If you tell me how to turn on verbose logging I can find the exact part 
> where it's hung.

If ./configure hangs then trace through it with 'sh -x ./configure'
and also look in the config.log file.

Unfortunately if autoreconf hangs I don't know how to suggest an easy
way to track down what happens there.  I would start by running
'autoreconf --verbose'.

  autoreconf --verbose

Then depending upon the results there I would reach in deeper and turn
on perl debugging.  Try this and see if this helps.

  PERLDB_OPTS="NonStop=1 AutoTrace=1 frame=2" perl -dS autoreconf --verbose

That will produce a *lot* of output.  Hopefully the output near the
hang will be useful information.  It would be useful to see the last
part of that output if it shows something useful about what is
hanging.

Note that I haven't actually tried that on autoreconf before but it is
one way how I debug other perl programs.

> >>-rw-r--r-- 1 pickett xxx 0 Feb 23 00:27 .nfsCC131
> Ralf suggests:
> >I suppose you can rename the directory (and delete it as soon as you've
> >reset the NFS connection).
> 
> It doesn't work.  I have a ~/deleteme directory where I dump stale NFS 
> things and periodically attempt to rm -rf, but it can take days for 
> things to get released.

Well, That is basically what Ralf suggested.  Moving the file to
another place such as your deleteme frees up the auto4te.cache.  So
actually the workaround does work.  In this context "reseting the nfs
connection" I read as "rebooting the system".

On NFS systems there is usually a nightly or weekly cron that looks
for old .nfs* files and attempts to remove them.  That reaps in
orphaned files that have eventually gotten freed up.  It ignores
errors from files that can't yet be removed.  That is an additional
workaround for this nfs last close problem.

> I don't have anything more than user priviledges, and I don't think
> the sysadmins have a mandate to work on fixing this as long as I
> have a workaround.

You would need to find a way to make it their problem. :-)  But even
then I doubt they could fix it.  This is usually a deeper problem in
the system code itself.

Bob