Re: nfs unmount: can it be done from (to) a croaked system?

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

On 5/22/2017 7:49 PM, Mike Riechers wrote:
> Hello, all.
>
> A few weeks ago one of our computers bit the big one: the root disc
> drive croaked (bad).  One of these days I'll get to replacing the
> drive, but I'm not shedding too many tears, for 1)it's a little used
> system, and 2) the important data was on other drives.
>
> What is annoying is, however, the fact that we had files nfs mounted
> on our network that were serviced from this computer.  Now any time we
> do a "df", an unmount, or any operation that references the nfs from
> that computer, the program "locks up," and ps shows:
>
>               D       Marks a process in device or other short term,
>                       uninterruptible wait.
>
> I did a "df" on one of our computers a couple of weeks ago, and ps
> still shows the process in device or other short term, uninterruptible
> wait.  So much for short term.
>
> I believe that the df inquiry is going to wait forever, demanding to
> palaver with the nfs that isn't there anymore.  (It's inconvenient to
> try to remember to do a "df -l," and of course, there goes info
> concerning my other nfs mounts.)
>
> I tried a "umount -fh mydeadcomputer.com" on the nfs mount, but all
> that got me was a locked-up "umount."
>
> I've rebooted one computer, and of course that worked, but I'd rather
> not do the same thing to all the rest.  Is there a more elegant
> solution I'm missing?

Here's a bit of a hack that might help:

$ cat recover_nfs_gdb.sh
#!/bin/sh
cat <<EOF | gdb -write netbsd.gdb
target kcore /dev/mem
set $p = nfs_reqq.tqh_first
if ($p != 0)
        # 4 is R_SOFTTERM
        printf "Changing flags on %lx from %d to %d", $p, $p->r_flags, 
($p->r_flags | 4)
        set $p->r_flags |= 4
end
set write off
quit

EOF


I have no idea whether it still works in current versions of NetBSD, but 
years ago when I wrote it it would cause any stuck process to get an I/O 
error and give up.

Eric