[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unmount a busy NFS share

On Sun, Jun 18, 2006 at 08:23:57PM +0200, Bernd Schubert wrote:
> > No, it's definitely neither in my $PATH nor in my $LD_LIBRARY_PATH.
> ld.so.conf?

No. I would have known if I put it there. It was a share exclusively for
data, no programs, no libraries.

> > So there are some system calls with /mothermole as argument, and then it
> Where does /mothermole come from? Did you grep for mothermole
> or /mothermole?

Nope. Those were the last lines of lsof's output before it hang.

> > hangs, as expected. Can I still somehow find out, which processes are
> > waiting?
> Usually lsof does the trick, something very odd is going on on this system.
> You could still write your own script reading all the
> links /proc/{proc_ids}/fd. Actually I thought lsof would do the same.

I guess lsof does something like, but I'm not sure. Maybe I'll actually
try grep-ing through /proc/*/fd/, good idea.

> > It is really annoying that a NFS client can be brought into such
> > troubles and there is no sensible way to resolve it.
> Well, with recent kernels this shouldn't happen.

I'm running 2.6.16-2 here (on the NFS client).

> Being in a theoretical chemistry group and due to long term
> calculations we often also can't simply reboot a system. In the past 2
> years a reboot of linux clients was usually only required when our
> failover server didn't taker over properly (actually it didn't mount
> properly and then exported the wrong directory, for the clients with
> their / from this server this caused some problems, especially since
> we also enforce the fsid)

It's not really a productive system here, but it just annoys me like
hell. I wouldn't kill me to reboot, but I won't until I am really sure
there is no other way.


Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A

Attachment: signature.asc
Description: Digital signature

Reply to: