I'm using sshfs through forward ssh tunnel connection and got disconnected unexpectly.
Note: Using sshfs through ssh tunneling connection is such a way to wasting computer power because it encrypts data double times. First, the tunnel connection, Second, sshfs connection itself. However if you're using encfs, there's not much of an options are available. I think this is the easy and best way to mount a encrypted directory point made by encfs(other users can't even access the encrypted directory. not even root.) other options like NFS requires root access with some tricks.
The problem was:
- I couldn't see my home directory(ls -al command hangs) - where the sshfs mounting point directory was located.
- command df -sh hangs too.
My home directory is /home/myhome/(for example.) and the mounting point was /home/myhome/sshfsdir. It seemed like every I/O processes that access my home directory(which is /home/myhome/) hangs due to unable to read the one of child nodes. mounting point directory /home/myhome/sshfsdir/ was one of them.
However I was able to access the / directory as root user(probably any user too), I was able to un-mount sshfs mounting point using fusermount command with the lazy option -z.
# fusermount -uz /home/myhome/sshfsdir/
Then I checked sshfs process(ps -ef | grep sshfs). there was still one sshfs process hangs under the background. I couldn't kill it by kill PID command. so I googled.
If a sshfs process keep hangs under the background on your system or any other processes that you can't kill, try to use the option -KILL for kill command.
# kill -KILL PID
I've seen this when I drop a connection to an active screen then reconnect. The linked bug describes the problem as I see it. What appears to happen is that screen is trying to notify the tty that holds it that it is about to leave, but since the tty is hung due to a dropped connection it has to wait for the timeout to happen (which is upwards of five minutes in some cases).
To fix it, I do this:
figure out which tty is holding on to the screen session ps -ef | grep screen | grep pty
find the login bash that is associated with that tty ps -ef | grep bash | grep $PTY
kill that bash kill -KILL $PID
This causes screen to complete its disconnect correctly, and lets you reconnect normally.
See here for an example script automating this somewhat.
I found a wiki article that explains this problem softly:
killing me softly
or, how to be as gentle as possible when killing a Linux/Unix process
I recommend kills in this order, with a short delay between each:
- kill -TERM (same as kill without an argument)
- kill -HUP (same as closing the window)
- kill -INT (same as Ctrl-C)
- kill -QUIT (same as Ctrl-\)
- kill -PIPE (same as quitting the program you've piped it into, e.g. less)
- kill -KILL (a.k.a. -9)
The only thing that can ignore a KILL signal is I/O. If your process still won't die when you use KILL, there is often no option but to reboot the system. This is one of my pet peeves about Linux.
Template
Here's a bash function to do the job:
kill_softly()
{
for sig in TERM HUP INT QUIT PIPE KILL; do
echo "kill -$sig $@"
if ! kill -$sig "$@"; then
# the kill command failed - this usually means that the process is now dead
break
fi
sleep 2
done
}