Hello
When I connect to my server over ssh and want to logout it dosen’t close. this is the result when running ssh with parameter ‘-v’ for verbose and try to exit. I was logged in as root (first exit) This is what can be seen from client computer.
**quinness:/ #** exit
logout
quinness@quinness:~> **exit**debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
utloggning
debug1: channel 0: free: client-session, nchannels 7
^Cdebug1: channel 2: free: x11, nchannels 6
debug1: channel 3: free: x11, nchannels 5
debug1: channel 4: free: x11, nchannels 4
debug1: channel 5: free: x11, nchannels 3
debug1: channel 6: free: x11, nchannels 2
debug1: channel 8: free: x11, nchannels 1
Killed by signal 2.
quinness@linux-sk28:~>
When I waited for 5 minutes I pressed CTRL-C at ‘debug1: channel 0: free: client-session, nchannels 7’
Is there some security issue? Faulty setup? Crappy network?
/Johan
This happens when there are still processes linked, perhaps loosely, to the file descriptor which is the ssh connection socket.
You connect with ssh. At the server, sshd opens a pty (pseudo-terminal) which maps back to the network socket. Then you start some server processes that have some relation to the pty.
You can sometimes avoid the problem with redirection:
( command < /dev/null > /dev/null 2>&1 ) &
though that might not always do the trick.
Back when I was administering some servers, I wrote a little program that I called “daemonize”. I would use it in the form:
daemonize command options
What this did was fork() a child to run the command. Then it did whatever was the magic to put that into a distinct process group. Then it closed all file descriptors >2. Then it check whether file descriptors 0, 1, 2 were terminals, and if they were it used “dup2” to change them to “/dev/null”. Then it did an execv() to the command. This completely separated the started command from the ssh session.
So much specific information. Thanks
Just to understand all…
It is on the server that
( command < /dev/null > /dev/null 2>&1 ) &
should be run, and not
( ssh < /dev/null > /dev/null 2>&1 ) &
Thnaks for the information!!!
Yes, that’s to do on the server when you start a long running command over your ssh connection.