status of the hang-on-exit-bug

[Wojtek Pilorz]

On Tue, 23 Oct 2001, Craig J Copi wrote:

> Date: Tue, 23 Oct 2001 14:06:16 -0400
> From: Craig J Copi <cjc5 at po.cwru.edu>
> To: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: status of the hang-on-exit-bug 
> 
> Lutz Jaenicke writes:
> >- Even more: on OpenBSD the connection is closed immediatly. Doesn't this
> >  mean, that output generated by the backgrounded processes after the
> >  close would be lost, thus violating the idea of keeping the channel
> >  open to prevent this data loss...
> 
> I believe it does mean that data is lost.  I did the following 
> simple test:
> #>ssh localhost
> [ Login ]
> %> sleep 10; echo hi &
> %> exit
> 
> I did this on
> (1) OpenBSD 2.9 with OpenSSH_2.9 and tcsh-6.10.00 (from ports)
> (2) Linux 2.4.6 with OpenSSH_2.9.9p2 and tcsh-6.10-5 (RH 7.1)
> 
> On the OpenBSD box (1) the exit was immediate.  "hi" WAS NOT printed.
> On the Linux box (2) the exit hung, after the delay "hi" WAS printed
>   then the exit finished.
> 
> Craig
> 
Craig made a very good point here.
I believe the user should be given a choice;

Let me explain with an example first:
Assume a user logs in to another machine interactively using ssh;
At some point (s)he runs a process in the background;
The process can issue some error messages to stdout/stderr, so redirecting
them to /dev/null is not a good idea. And the process can run for many
hours, so the user would want to be able to shut down his workstation and
accept the risk that error messages which did not show soon after start of
the process would be lost.

So I believe the current behaviour on Linux is consistent with the
requirement that data should never be lost, while behaviour on OpenBSD is
not;
Also, I believe that user should be able to conveniently request unsafe
behaviour of allowing data loss from processes run in the background which
have open std*, both for interactive and non-interactive sessions.

I think that an option allowStdxDataLoss={yes,no,ask}
would be a good idea (of course with a much shorter name);
Also, not allowing such option within ssh configuration files might be a
good idea to prevent making unsafe behaviour a silent default on any
system (and then 'my data was lost' complaints).
Also, after escape character is pressed, there might be a command to
inquiry and change state of that option in case user changes her/his mind
during the session.

Best regards,

Wojtek
--------------------
Wojtek Pilorz
Wojtek.Pilorz at bdk.pl