On Tue, Apr 24, 2001 at 03:29:42PM -0700, Kevin O'Brien wrote:
> We've noticed the problem since 2.3 came out. I've sent in a couple
> messages and no one seems to acknowledge it's existence.
> -----Original Message-----
> From: David Cress [mailto:[EMAIL PROTECTED]]
> If I ssh to a system, start a job that forks off, and try and exit, my
> connection hangs, i.e.
Oh, this problem is definitely real, at least on some platforms. I
get it with HP-UX 10.20 as well. (With HP-UX 9.05, there are much
worse problems, but fortunately I won't be running 9.05 much longer.)
The only workaround I've found for it is to launch your background
jobs with stdout and stderr redirected. A simple jobs hangs:
imadev:~$ ssh vandev 'sleep 60 &'
wooledg@vandev's password:
Killed by signal 15.
imadev:~$
But if I run it with redirection, it returns control to the local system
before the sleep finishes:
imadev:~$ ssh vandev 'sleep 60 >/dev/null 2>&1 &'
wooledg@vandev's password:
imadev:~$ ssh vandev 'ps -fu wooledg | grep sleep'
wooledg@vandev's password:
wooledg 16061 1 0 07:57:59 ? 0:00 sleep 60
wooledg 16064 16062 12 07:58:30 ? 0:00 grep sleep
imadev:~$
And in fact, I don't even need to redirect stderr; stdout alone is OK:
imadev:~$ ssh vandev 'sleep 60 >/dev/null &'
wooledg@vandev's password:
imadev:~$
But if I just redirect stderr and not stdout, it hangs:
imadev:~$ ssh vandev 'sleep 60 2>/dev/null &'
wooledg@vandev's password:
Killed by signal 15.
imadev:~$
I've tried with nohup as well, and that appears to make no difference
either way -- "nohup sleep 60 &" hangs, while "nohup sleep 60 >/dev/null
2>&1 &" does not.
So, it would seem that if the process that's launched on the remote
system holds stdout open, the sshd child won't close the connection.