Hide Forgot
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 filesystem. 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): How reproducible: Sometimes 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) :-) Additional info:
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 patch.