Marc Fournier wrote: > On 2013-02-14, at 08:41 , Rick Macklem <rmack...@uoguelph.ca> wrote: > > > > > Btw Marc, if you just want this problem to go away, I suspect > > getting rid > > of the "intr" mount option would do that. > > Am more interested in fixing the problem (if possible) then just > masking it, but ... > > Based on the man page for mount_nfs, wouldn't that have the opposite > effect: > > intr Make the mount interruptible, which implies that file > system calls that are delayed due to an unresponsive > server will fail with EINTR when a termination signal is > posted for the process. > > I may be mis-reading, but from the above it sounds like a -9 *should* > terminate the process if intr is enabled, while with it disabled, it > would ignore it … ? > Yes, you have misread it (or english is a wonderfully ambiguous thing, if you prefer;-).
For hard mounts (which is what you get if you don't specify either "soft" nor "intr"), the RPCs behave like other I/O subsystems, which means they do non-interruptible sleeps ("D" stat in ps) waiting for server replies and continue to try and complete the RPC "forever". You can't kill off the process/thread with any signal. If "umount -f" of the filesystem works, that terminates the thread(s). Unfortunately, "umount -f" is quite broken again. I have an idea on how to resolve this, but I haven't coded it yet. (The problem is that the process doing "umount -f" gets stuck before it does the VFS_UNMOUNT(), so the NFS client doesn't see it.) rick > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"