I have a few processes that were started in a smb mount directory. Due
to server reboot the connection broke. The processes are now in an
uninterruptable state, waiting for IO, so, they cannot be killed nor the
smbfs unmounted.
Obviously, the only thing I can do is to reboot my computer.
Any suggestions?
Linux ara 2.4.14 #2 Fri Nov 9 03:03:03 CET 2001 i686 unknown
Cheers.
--
Juergen Sawinski
Max-Planck Institute for Medical Research
Dept. of Biomedical Optics
Jahnstr. 29
D-69120 Heidelberg
Germany
Phone: +49-6221-486-308
Fax: +49-6221-486-325
priv.
Phone: +49-6221-418 858
Mobile: +49-171-532 5302
On Wednesday 05 December 2001 14:15, Juergen Sawinski wrote:
> I have a few processes that were started in a smb mount directory. Due
> to server reboot the connection broke. The processes are now in an
> uninterruptable state, waiting for IO, so, they cannot be killed nor the
> smbfs unmounted.
>
> Obviously, the only thing I can do is to reboot my computer.
> Any suggestions?
Well, technically speaking it's a bug, but this kind of bug
is not going to be fixed. Why?
Imagine that a page from text segment of one of those apps was discarded
due to VM pressure, and now it is needed again. Kernel tries to read it back
from SMB mounted fs which is no longer there. What kernel can do?
It can't signal app (what if signal handler isn't in RAM too?),
it can only kill this process. But the code to do it is not implemented.
(AFAIK. I may be wrong). Kernel is just not prepared for swap or text pages
to become suddenly unavailable. It is hard to handle that too given VM
complexity.
Typically swap is on a local hard disk and apps are started from there too
and it is not expected to fail, so nobody seriously care.
Even NFS folks made hard,nointr mount options the default, which means you'll
never ever will be able to kill your app if server crashed and not rebooted.
To this day I have no explanation why hard,intr isn't a default (it allows me
to kill processes hung in NFS read()/write() syscall).
--
vda