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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
