From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206
Description of problem:
This may look similar to bug 82984, but I don't think it's the same problem.
Here's what happened:
The NFS server is my desktop, running under very light load.
I was doing an NFS install to my wife's desktop, mouting the ISOs from my desktop.
Another machine had another filesystem mounted from my desktop, and was doing
some relatively light access to files in my desktop, converting avi files from
one format to another.
Just as I heard the beep from my wife's machine, saying the install had
completed and it was now rebooting, I noticed that the avi compressor had hung.
The window of the application wouldn't refresh any longer, and I couldn't put
it in background any more.
On the local machine (the NFS server), I tried to access the directory the media
converter was accessing. ls hang. Other directories in the same filesystem
appeared to be ok. Hmm, now I realize I may not have actually tried anything on
this filesystem, as the shell blocked and other shells I had were on another
Oops, this may turn out to be the same problem as 82984, even though it's a
different kernel version (running 2.4.20-2.48 now) and I haven't run into the
bug with a local nfs mount despite some heavy loads I put on it.
I've had at least one other hang similar to this the other day, but I couldn't
correlate it with an NFS unmount at that time. Not that I'm sure it's related,
but it may be, since I had just started the conversion of one file, so it was
working just a few seconds before the other NFS client rebooted.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Start one NFS client creating directories and, say, copying not-very-large
files in one filesystem mounted from the server
2.Start an NFS install on another machine mounting from the same NFS server, but
from another filesystem
3.Wait for the install to complete, and let it reboot.
Actual Results: If you're lucky (or not :-) the other NFS client will hang, and
so will the NFS server, as far as access to the affected directory (or maybe the
filesystem containing it) is concerned. Unfortunately, it didn't generate a
kernel oops, AFAICT.
Expected Results: This Shouldn't Happen (TM) :-)
Could this be part of the following: If you connect to a remote NFS server and
mount an NFS drive and then the remote NFS server goes away you will not be able
to do a clean power down or unmount the drive? This condition showed up in the
lab but I wasn't sure it was a bug so didn't report it. This condition has
existed since at least ver 5.
I don't see how these conditions could be related. One thing is the server
hanging when accessing a filesystem that was NFS-exported, the other is the
client hanging because the server is not there. The latter is bug 63602.
Never got this with Shrike. Presumably fixed with the removal of the buggy ACL