Joe Zeff writes:
completing when the remote server's known to have crashed. At
this point,
probably the best way to proceed is to request that whoever maintains the
programs in question modify them so that they don't enter this state when
It's not up to the app to decide that.
If you configure a hard NFS or a CIFS mount, you are explicitly telling the
kernel to put the app into uninterruptible sleep if the mount breaks, until
such time that the mount comes back. If you don't want that, don't use hard
mounts. It's a very easy problem to solve. But woe be you, if you have any
app, any app that merrily gibbers into a log file, without checking if
write() succeeds. If the soft mount goes down, the app will merrily log its
complaints into the bit bucket, even though it would've been preferrable for
the app to crash and die a very, very slow death, if its mount goes down.
And, yes, there are environments where hard mounts, and this behavior, is
explicitly required.
If the kernel puts the app into uninterruptible sleep, the app can do
jackspit about it.