Matt, > > This is an older Heartbeat haresources-based cluster. Would your > > suggestion work even when kill -9 won't kill the nfs, nfsd, or > > mfsd4 processes? They simply would not die. I suspect this > is because > > they are in use by another process. > > If so, then kill *that* process. lsof and/or fuser can help > a lot with determining what's using things and killing those things. >
Couldn't it be someone sitting in the mounted directory on an NFS client computer? Getting to that might be hard. Is there some way to get a hung nfsd to quit waiting for whatever it is waiting for? > > Under Linux, a process in state D (waiting for a syscall to > return) *cannot* be killed, even with SIGKILL. The kernel > programmers found a number of circumstances where terminating > a process in state D could lead to Undefined Behavior, as I > understand it. The example I remember was a process doing a > read() syscall on a dodgy disk. Kernel code says, "When the > read from the disk completes, I'll use DMA to shove the > result into page 0x131072." Disk can't deliver immediately > because it's flaky. User kill -9s the process. > Kernel MM code releases page 0x131072, some other process > grabs hold of that page. Disk eventually gets its act > together, uses DMA to write data to that page, other process > gets its data corrupted. How embarrassing. > Thanks for the explanation. I figured it was something like that. It's way too frustrating a problem for someone not to have fixed it otherwise. --Eric Disclaimer - February 17, 2011 This email and any files transmitted with it are confidential and intended solely for Matt Graham,drbd-user@lists.linbit.com. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ _______________________________________________ drbd-user mailing list drbd-user@lists.linbit.com http://lists.linbit.com/mailman/listinfo/drbd-user
