stuck: mount, umount, fuser, lsof

Hi!

Suddenly several program that query resources stuck: when I run mount,
umount, fuser, or lsof, the program just stuck / hangup, no error show up,
just stuck.

Moreover, I cannot kill autofs. Even after I used SIGKILL, nothing happen.

BTW, I found out that accidentally I got to two autofs running, and both
mounted the same smb volume in a machine that was turned off. I turned
that machine back on but it was not helping.

Any idea what happen?
Any idea how to fix it without restarting the system?

Thanks!

--
Stephan Paul Arif Sahari Wibowo
_____ _____ _____ _____
/____ /____/ /____/ /____
_____/ / / / _____/ http://www.arifsaha.com/

On Tue, 16 Nov 2004 21:50:34 -0500, S P Arif Sahari Wibowo wrote:

> BTW, I found out that accidentally I got to two autofs running, and both
> mounted the same smb volume in a machine that was turned off. I turned
> that machine back on but it was not helping.

It's called a stale mount and the only recourse is reboot.

Do not automount from an unreliable remote system. Automounting from a
Windows system is particularly stupid.

On Tue, 16 Nov 2004, Dave Uhring wrote:
> It's called a stale mount and the only recourse is reboot.

Oh well. Actually now that you said it, I remember it happened before.

> Do not automount from an unreliable remote system. Automounting from a
> Windows system is particularly stupid.

Well, in fact I think I used to have more problem before I use autofs,
since I often forgot to umount. Since using autofs, it happen much rarely
(never until now) because it umount automatically.

Thanks!

--
Stephan Paul Arif Sahari Wibowo
_____ _____ _____ _____
/____ /____/ /____/ /____
_____/ / / / _____/ http://www.arifsaha.com/

In article <pan.2004.11.17.03.34.02.872997@yahoo.com>,
Dave Uhring <daveuhring@yahoo.com> wrote:

>On Tue, 16 Nov 2004 21:50:34 -0500, S P Arif Sahari Wibowo wrote:
>
>> BTW, I found out that accidentally I got to two autofs running, and both
>> mounted the same smb volume in a machine that was turned off. I turned
>> that machine back on but it was not helping.
>
>It's called a stale mount and the only recourse is reboot.

I'm surprised that's still true. I thought Linux was more robust than
that, and that the mounts should timeout and eventually unmount
themselves.

Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> writes:

]In article <pan.2004.11.17.03.34.02.872997@yahoo.com>,
] Dave Uhring <daveuhring@yahoo.com> wrote:

]>On Tue, 16 Nov 2004 21:50:34 -0500, S P Arif Sahari Wibowo wrote:
]>
]>> BTW, I found out that accidentally I got to two autofs running, and both
]>> mounted the same smb volume in a machine that was turned off. I turned
]>> that machine back on but it was not helping.
]>
]>It's called a stale mount and the only recourse is reboot.

]I'm surprised that's still true. I thought Linux was more robust than
]that, and that the mounts should timeout and eventually unmount
]themselves.

It would be nice. Also umount -f is supposed to free up such stale mounts,
but I have almost never had it work.
It is far too common to have a umount fail. umount -f should force an
unconditional unmount.

On Wed, 17 Nov 2004, Lawrence D¹Oliveiro wrote:
> I'm surprised that's still true. I thought Linux was more robust than
> that, and that the mounts should timeout and eventually unmount
> themselves.

Well, I understand why this is not implemented generally for all kind of
mount, because if the mounted volume is a hardware device, forcing umount
may cause the hardware is broken / corrupted beyond repair. Moreover
different volume may have their own "normal unresponsive time". So
timeout, if any, should be implemented in each module / daemon.

--
Stephan Paul Arif Sahari Wibowo
_____ _____ _____ _____
/____ /____/ /____/ /____
_____/ / / / _____/ http://www.arifsaha.com/

In article <Pine.LNX.4.61.0411181428560.2855@localhost.locald omain>,
S P Arif Sahari Wibowo <arifsaha@yahoo.com> wrote:

>On Wed, 17 Nov 2004, Lawrence D¹Oliveiro wrote:
>> I'm surprised that's still true. I thought Linux was more robust than
>> that, and that the mounts should timeout and eventually unmount
>> themselves.
>
>Well, I understand why this is not implemented generally for all kind of
>mount, because if the mounted volume is a hardware device, forcing umount
>may cause the hardware is broken / corrupted beyond repair.

But it's probably too late for that hardware anyway, if the machine has
to be rebooted to clear the stale mount. The mount is gone, and there's
no bringing it back. Might as well let the system recover gracefully
from it, why should it suffer from a problem caused by some other piece
of hardware?

>Moreover
>different volume may have their own "normal unresponsive time".

On old MacOS, the AppleShare file service implemented a 2-minute timeout
before deleting the stale mount. I figure that should be enough for most
purposes. Or you could even shorten it in certain cases, if you made it
a parameter of some kind.