sshd hangs on logout -- is this a bug?

Nicolas Williams Nicolas.Williams at ubsw.com
Fri Sep 7 01:00:28 EST 2001


This is normal behaviour for RSH and is natural behaviour anyways.

For example: when should "ssh somehost somecommand" exit? When
'somecommand' exits? or when it *and* all it's children have exited? And
what if you were starting a daemon?

But daemons *detach* from their current TTY, and *that* is key here. If
'somecommand' in the above example leaves background children processes
when it exist and those children still have the ssh tty open then they
may want to read/write from/to that tty -- and the ssh user might well
expect to be able to interact with such background children processes.

Thus this is normal behaviour.

Just remember, when you don't want hanging rsh/ssh's do this:

ssh -n somehost somecommand \> /dev/null 2\>\&1

It might be nice to have an option like -n but for stdout/stderr to
avoid the need for quoting (and to be more portable, after all, that "\>
/dev/null 2\>\&1" bit is Bourne Shell specific and can't be guaranteed
to work with all ssh daemons (think Windows).

Nico


On Wed, Sep 05, 2001 at 04:57:51PM -0700, Adam McKenna wrote:
> In the changelog, there is an entry:
> 
> 20001129
>  - (djm) Back out all the serverloop.c hacks. sshd will now hang again
>    if there are background children with open fds.
> 
> Does this mean that this is regarded as expected (and correct) behavior, that
> should not change in the future, or does it mean that this behavior is a
> known problem that someone will eventually fix?
> 
> --Adam
> 
> -- 
> Adam McKenna <adam at flounder.net>   | GPG: 17A4 11F7 5E7E C2E7 08AA
> http://flounder.net/publickey.html |      38B0 05D0 8BF7 2C6D 110A


--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list