so, should this go into 3.5?
Index: serverloop.c
==================================================================RCS file:
/home/markus/cvs/ssh/serverloop.c,v
retrieving revision 1.103
diff -u -r1.103 serverloop.c
--- serverloop.c 24 Jun 2002 14:33:27 -0000 1.103
+++ serverloop.c 12 Jul 2002 16:34:20 -0000
@@ -388,6 +388,11 @@
buffer_append(&stderr_buffer, buf, len);
}
}
+ /* allow data loss on pty */
+ if (child_terminated && fderr == -1 && !fdout_eof) {
+ close(fdout);
+ fdout_eof = 1;
+ }
}
/*
Index: session.c
==================================================================RCS file:
/home/markus/cvs/ssh/session.c,v
retrieving revision 1.143
diff -u -r1.143 session.c
--- session.c 30 Jun 2002 21:54:16 -0000 1.143
+++ session.c 12 Jul 2002 16:35:32 -0000
@@ -1629,11 +1629,15 @@
/*
* emulate a write failure with 'chan_write_failed', nobody will be
* interested in data we write.
- * Note that we must not call 'chan_read_failed', since there could
+ * Note that for the non-pty case we must not call 'chan_read_failed',
+ * since there could
* be some more data waiting in the pipe.
*/
if (c->ostate != CHAN_OUTPUT_CLOSED)
chan_write_failed(c);
+ /* allow data loss on pty */
+ if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN)
+ chan_read_failed(c);
s->chanid = -1;
}
It's been working fantastically for me. /fc On Wed, Jul 31, 2002 at 06:35:47PM +0200, Markus Friedl wrote:> so, should this go into 3.5? > > Index: serverloop.c > ==================================================================> RCS file: /home/markus/cvs/ssh/serverloop.c,v > retrieving revision 1.103 > diff -u -r1.103 serverloop.c > --- serverloop.c 24 Jun 2002 14:33:27 -0000 1.103 > +++ serverloop.c 12 Jul 2002 16:34:20 -0000 > @@ -388,6 +388,11 @@ > buffer_append(&stderr_buffer, buf, len); > } > } > + /* allow data loss on pty */ > + if (child_terminated && fderr == -1 && !fdout_eof) { > + close(fdout); > + fdout_eof = 1; > + } > } > > /* > Index: session.c > ==================================================================> RCS file: /home/markus/cvs/ssh/session.c,v > retrieving revision 1.143 > diff -u -r1.143 session.c > --- session.c 30 Jun 2002 21:54:16 -0000 1.143 > +++ session.c 12 Jul 2002 16:35:32 -0000 > @@ -1629,11 +1629,15 @@ > /* > * emulate a write failure with 'chan_write_failed', nobody will be > * interested in data we write. > - * Note that we must not call 'chan_read_failed', since there could > + * Note that for the non-pty case we must not call 'chan_read_failed', > + * since there could > * be some more data waiting in the pipe. > */ > if (c->ostate != CHAN_OUTPUT_CLOSED) > chan_write_failed(c); > + /* allow data loss on pty */ > + if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) > + chan_read_failed(c); > s->chanid = -1; > } > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >
Also cures HP-UX 9.05 using OpenSSH_3.4p1 -- John H. Dunlap University of Washington Senior Electrical Engineer Applied Physics Laboratory dunlap at apl.washington.edu 1013 NE 40th Street 206-543-7207, 543-1300, FAX 543-6785 Seattle, WA 98105-6698
On Wed, 31 Jul 2002, Markus Friedl wrote:> so, should this go into 3.5?I vote no, it should not. Here is why:> + /* allow data loss on pty */And it indeed happens. After applying this patch, if I say 'ssh -t localhost pico' and then exit pico I get a garbled screen. Picos screen clearing and terminal attribute resetting escape sequences are lost because of allowing data loss on pty (pico is just an example. I guess most tty programs will behave the same.). Here is another example (my test sshd lives behind port 444): <CLIP> $ ssh -t localhost -p 444 exec echo blah blah Connection to localhost closed. $ ssh -t localhost -p 444 exec echo blah Connection to localhost closed. $ ssh -t localhost -p 444 exec echo blah blah </CLIP> So sometimes just 'echo blah' is lost. My suggestion is that instead of just closing the channel when the session process dies, sshd should effort to empty the pty buffer before closing the channel. This could be implemented so that when the session process dies, sshd should read (and buffer) the pty master data until it gets EAGAIN and then close the channel. All pending output from dead session processes should allready be in the pty buffer, so first EAGAIN means that all of it has been read processed. I guess I will attempt to implement this, but it will take some time (I will need to learn how session.c and serverloop.c work first). - Jani
So, this forcefully closes stdout when the session process leader exits and stderr is already closed? I'm not sure why that would be a good thing... What am I missing? The hang-on-exit go around has gone round so many times... - why buckle now on the position that it's the client's responsibility to decide to close the SSH connection early when the session exits, as users expect, and not sshd's? Why not have an option for the client to do this? Cheers, Nico --> -----Original Message----- > From: Markus Friedl [mailto:markus at openbsd.org] > Sent: Wednesday, July 31, 2002 12:36 PM > To: openssh-unix-dev at mindrot.org > Subject: so-called-hang-on-exit > > > so, should this go into 3.5? > > Index: serverloop.c > ==================================================================[...] > Index: session.c > ==================================================================[...]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.
I still think this sort of thing should be done by the client. The client knows everything that the server knows. So the client can choose to terminate the SSHv2 session when the PTY session process leader exits - and it can implement any other termination heuristic you wish too. Nico --> -----Original Message----- > From: Jani Jaakkola [mailto:jjaakkol at cs.helsinki.fi] > Sent: Saturday, August 03, 2002 3:02 PM > To: openssh-unix-dev at mindrot.org > Subject: Re: so-called-hang-on-exit >[...]> OK, now I have implemented it. Currently only for protocol 2, but a > similar thing can be implemented for protocol 1 (and the > protocol 1 patch > would be simpler). > > Here is what it does (or should do; I have made mistakes before): > > - Applies against openssh-3.4p1 > - This patch only changes behavior of ssh protocol 2 sessions > with a tty. > Everything else should remain as it was. > - It does its job by reading all immediately available data from the > pty when the pty session process dies. This should include all data > from the pty session foreground processes. > - It can and will lose data from pty session background processes. > - It might still hang indefinetely, if the background processes keep > producing more data than the sshd process can read and transfer to > client (so that pty buffer will never get completely > empty). I consider > this a feature of this solution, not a bug.[...] 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.
On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:> > I still think this sort of thing should be done by the client. > > The client knows everything that the server knows.Except this time is does not. If there is background processses on the tty, the client can either close the session and lose data or wait indefinetely for data from the background processes.> So the client > can choose to terminate the SSHv2 session when the PTY session > process leader exits - and it can implement any other termination > heuristic you wish too.It needs server modifications that data from the pty session process leaders is not lost. I think rlogin and all other pty using programs have allready implemented this properly; which is that the pty buffer is first emptied and the connection is closed _after_ that. - Jani
Fair enough on the flushing of the pty. But sshd should still not close the pty - it should wait for the background processes to exit and/or dissassociate from the pty. The client does know that there are background processes left still holding the pty open. How? Because the client requested and got a pty, the sshd has sent a session-exit message, and the channel is still open. Cheers, Nico --> -----Original Message----- > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI] > Sent: Monday, August 05, 2002 4:20 PM > To: Williams, Nicolas > Cc: openssh-unix-dev at mindrot.org > Subject: RE: so-called-hang-on-exit > > > On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote: > > > > > I still think this sort of thing should be done by the client. > > > > The client knows everything that the server knows. > > Except this time is does not. If there is background > processses on the > tty, the client can either close the session and lose data or wait > indefinetely for data from the background processes. > > > So the client > > can choose to terminate the SSHv2 session when the PTY session > > process leader exits - and it can implement any other termination > > heuristic you wish too. > > It needs server modifications that data from the pty session process > leaders is not lost. I think rlogin and all other pty using > programs have > allready implemented this properly; which is that the pty buffer is > first emptied and the connection is closed _after_ that. > > - Jani > >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.
>Fair enough on the flushing of the pty. But sshd should still not close >the pty - it should wait for the background processes to exit and/or >dissassociate from the pty. > >The client does know that there are background processes left still >holding the pty open. How? Because the client requested and got a pty, >the sshd has sent a session-exit message, and the channel is still open. > >Cheers, > >Nico --This is an oversimplification of the problem and what I consider to be the main reason why the problem has not been fixed. Consider the situation where a sysadm needs to log into a host, kill and restart a daemon. Naturally the daemon has not been properly written through no fault of the sysadmin who is merely and innocent victim of the ssh server. Upon logout the terminal window hangs.... duh!!!! Again I ask, why should we be held hostage to poorly written daemons just so you purists can say that not a single byte of data has been lost that might someday be attempted to be sent to pty connection that is trying desperately to disconnect??? The argument will not go away until some one fixes this BUG. Your argument that the "client knows" is simplistic. Sure, we know that people write buggy software and buggy daemons that do not properly redirect their STDOUT and STDERR. That does not meant that we should accomodate their stupidity and hang our own systems up because of it. At the very least, make it a server configuration option that connections will be closed unconditionally if requested by the client to do so. This way we can rid our systems of hung sshd processes that fill up the process table. Michael> -----Original Message----- > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI] > Sent: Monday, August 05, 2002 4:20 PM > To: Williams, Nicolas > Cc: openssh-unix-dev at mindrot.org > Subject: RE: so-called-hang-on-exit > > > On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote: > > > > > I still think this sort of thing should be done by the client. > > > > The client knows everything that the server knows. > > Except this time is does not. If there is background > processses on the > tty, the client can either close the session and lose data or wait > indefinetely for data from the background processes. > > > So the client > > can choose to terminate the SSHv2 session when the PTY session > > process leader exits - and it can implement any other termination > > heuristic you wish too. > > It needs server modifications that data from the pty session process > leaders is not lost. I think rlogin and all other pty using > programs have > allready implemented this properly; which is that the pty buffer is > first emptied and the connection is closed _after_ that. > > - Jani > >
BTW, it's not a "so-called-hang-on-exit". It DOES hang on exit, there is no question about it. The discussion is about how to fix it. Claiming that it is "proper" doesn't fix the problem or keep people for reporting it as a bug over and over again. The client user really does want the process to close when you say "exit", notwithstanding that there may be and outstanding process that could possibly return data. Such is life.>> On Mon, Aug 05, 2002 at 02:53:32PM -0700, Michael Robinton wrote: >> sysadmin who is merely and innocent victim of the ssh server. Upon >>logout the terminal window hangs.... >> >... and the admin presses ~. if he really want's to close >the connection. so what's the problem? > >-mThe problem is that it affects not only the knowledgable?? sysadmins but all users. It is a nusiance and an agravation. Some users don't know about ~ and some scripts which start remote processes via ssh get stuck with a hung connection. What's the problem with having sshd close the connects AS ASKED by sshd-config option which you can set to leave your system hanging if you wish to do so??? Please don't force the rest of us to deal with a hung script or blank window when we want to EXIT just becasue you think we should not loose the data we clearly don't want. Additionally, I really don't want my systems cluttered up with hung sshd processes started by remote users that can't figure out how to deal with a difficult implementation of ssh. I'm not bitching about ssh or the development. I think it's a fine program and you are all to be commended for it's development and improvement. But, lets get real about what users (not always so bright) and daemon developers (sometimes really dim) expect from ssh. When I log off a terminal window, I expect it to close. When I start a remote daemon, I expect to be able to disconnect from the remote host whether it is via a terminal window or a script. Michael
> So, > >You reach a certain timeout, and you get notified of something like: > >"Badly written shell processes are running, please hit ~ to force ssh >connection closure." >fat lot of good that does a script>Then every end user knows about the "way to close ssh even when shell >scripts are badly written", and they also get notified of the fact that >something they did in their session was "wrong", so they can even rectify >that problem.What about most users that didn't write the "badly written daemon". Are they suppose to learn how to maintain other people's stuff???> >The end user is not aware that the things they did were "wrong", most >probably because most other remote "shells" behave differently, so since >OpenSSHs behaviour is not "common" then the end user should be made >aware.Again, this oversimplifies the problem. We can make ssh difficult to use or easy to use -- gee why do you think Windoze is so popular -- since ~ will unconditionally close a terminal window, what's wrong with a config option to do this automagically if the sysadmin wishes to configure sshd in this fashion. Give me a good reason (other than academic) why when the user or script says "bye now" that sshd should not take them seriously. Michael> >Damien > >At 04:18 PM 5/08/2002 -0700, Michael Robinton wrote: >BTW, it's not a "so-called-hang-on-exit". It DOES hang on exit, there is >no question about it. The discussion is about how to fix it. Claiming >that >it is "proper" doesn't fix the problem or keep people for reporting it as >a bug over and over again. The client user really does want the process >to >close when you say "exit", notwithstanding that there may be and >outstanding process that could possibly return data. Such is life. > > >> On Mon, Aug 05, 2002 at 02:53:32PM -0700, Michael Robinton wrote: > >> sysadmin who is merely and innocent victim of the ssh server. Upon > >>logout the terminal window hangs.... > >> > >... and the admin presses ~. if he really want's to close > >the connection. so what's the problem? > > > >-m > >The problem is that it affects not only the knowledgable?? sysadmins but >all users. It is a nusiance and an agravation. Some users don't know >about ~ and some scripts which start remote processes via ssh get stuck >with a hung connection. What's the problem with having sshd close the >connects AS ASKED by sshd-config option which you can set to leave your >system hanging if you wish to do so??? Please don't force the rest of us >to deal with a hung script or blank window when we want to EXIT just >becasue you think we should not loose the data we clearly don't want. >Additionally, I really don't want my systems cluttered up with hung sshd >processes started by remote users that can't figure out how to deal witha>difficult implementation of ssh. > >I'm not bitching about ssh or the development. I think it's a fineprogram>and you are all to be commended for it's development and improvement.But,>lets get real about what users (not always so bright) and daemon >developers (sometimes really dim) expect from ssh. When I log off a >terminal window, I expect it to close. When I start a remote daemon, I >expect to be able to disconnect from the remote host whether it is via a >terminal window or a script. > >Michael
Michael, You misunderstood me. I stated that the so called "bug" could/should be fixed in the client, rather than the server. Nico -- 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.
Why are putting a timeout into the sshd's select() when flushing
the PTY?
I'll admit I've neither tried the patch nor really read it. But if
you'll rely on timeouts on one side, why not on the other. There's
the heuristic. I mean, if you want it to be totally correct then
sshd just has to wait for the pty to close - any other approach
has to be a heuristic and will allow for data lossage.
But then, you all seem to be happy with data lossage, whereas I'm
not happy to be forced to suffer it. So why not a client side
heuristic, like this:
if (session-exit && open_channels == 1) {
set_timeout(1); /* 1 second - or as configured */
}
...
and in the event loop add a check for (open_sessions == 0 &&
open_channels == 1 && open_channel_has_pty()) and then close the
channel and do the right thing (exit).
Forgive my pseudo-code.
I mean, if we're gonna have a heuristic, why not put it on the
client side, where all users can decide whether or not to turn
it on (whereas they can't if the heuristic is implemented on
the server side - not without adding a special channel request
for it [ick!]).
Cheers,
Nico
--
> -----Original Message-----
> From: Frank Cusack [mailto:fcusack at fcusack.com]
> Sent: Tuesday, August 06, 2002 2:21 AM
> To: Williams, Nicolas
> Cc: jjaakkol at cs.Helsinki.FI; openssh-unix-dev at mindrot.org
> Subject: Re: so-called-hang-on-exit
>
>
> How does the client know the pty has been flushed and it's
> not just that
> sshd has not set the right bit in the select mask (since it
> does or does not
> set it according to some heuristic)? ie, just b/c the client
> isn't getting
> data doesn't mean the pty has been flushed. Right?
>
> /fc
>
> On Mon, Aug 05, 2002 at 04:31:26PM -0400,
> Nicolas.Williams at ubsw.com wrote:
> >
> > Fair enough on the flushing of the pty. But sshd should still
> > not close the pty - it should wait for the background processes
> > to exit and/or dissassociate from the pty.
> >
> > The client does know that there are background processes left
> > still holding the pty open. How? Because the client requested
> > and got a pty, the sshd has sent a session-exit message, and
> > the channel is still open.
> >
> > Cheers,
> >
> > Nico
> > --
> >
> > > -----Original Message-----
> > > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> > > Sent: Monday, August 05, 2002 4:20 PM
> > > To: Williams, Nicolas
> > > Cc: openssh-unix-dev at mindrot.org
> > > Subject: RE: so-called-hang-on-exit
> > >
> > >
> > > On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:
> > >
> > > >
> > > > I still think this sort of thing should be done by the
client.
> > > >
> > > > The client knows everything that the server knows.
> > >
> > > Except this time is does not. If there is background
> > > processses on the
> > > tty, the client can either close the session and lose
> data or wait
> > > indefinetely for data from the background processes.
> > >
> > > > So the client
> > > > can choose to terminate the SSHv2 session when the PTY
session
> > > > process leader exits - and it can implement any other
> termination
> > > > heuristic you wish too.
> > >
> > > It needs server modifications that data from the pty
> session process
> > > leaders is not lost. I think rlogin and all other pty using
> > > programs have
> > > allready implemented this properly; which is that the pty
> buffer is
> > > first emptied and the connection is closed _after_ that.
> > >
> > > - Jani
>
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.
On Tuesday, August 06, Michael Robinton wrote:> Make it an option that can be set in both sshd-config and > ssh-config so > that both client and server operators have the choice to > never lose data > or to always disconnect, damn the data, full speed ahead :-)You can't make it a client-side option if it's implemented on the server side without extending the SSHv2 protocol [by adding a new channel request type]. So now you're saying you'd be happy with a client-side option (which you'd default a particular way, and I another, in ssh_config). So you've come around to my position :) Q.E.D., Nico -- 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.
> Hm, so still the only thing we could do is wait for EOF, > until someone can explain why Linux/Solaris behave different > from *BSD....What's the difference, again? Nico -- 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.
I meant, what is the difference in behaviour in technical terms. E.g., "the BSD pty master gets EOF as soon as all processes in the pty's controlling process group exit, whereas on Linux the pty master EOFs only when there are no open file descriptors for the pty." And what server-side, user-level heuristic could "correct" for this difference? Cheers, Nico --> -----Original Message----- > From: Craig J Copi [mailto:cjc5 at po.cwru.edu] > Sent: Tuesday, August 06, 2002 1:19 PM > To: Williams, Nicolas > Cc: openssh-unix-dev at mindrot.org > Subject: Re: so-called-hang-on-exit > > > Nicolas.Williams at ubsw.com writes: > > > >What's the difference, again? > > Using the following test: > #> ssh machinename > #> (sleep 10; echo hi) & > #> exit > > I get the following results. > H == Hang, wait for sleep, print hi, then exit > NH == Exit immediately (hi not printed) > > client\server | Linux | OpenBSD > --------------+---------+-------- > Linux | H | NH > OpenBSD | H | NH > > > Using the following test: > #> ssh machinename '(sleep 10; echo hi) &' > > I get the following results. > > client\server | Linux | OpenBSD > --------------+---------+-------- > Linux | H | H > OpenBSD | H | H > > Note: > Linux == RH7.3 w/updates > OpenBSD == 3.1 w/updates > OpenSSH 3.4[p1] w/privsep running on test machines. > > So why does this happen. People seem to expect the OpenBSD behavior > eventhough you don't get the "hi" printed in the first test case. > > Craig >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.
A test program *could* be written. The test should try several conditions to determine what the kernel/pty driver behaviour is: - does the pty close immediately when the session leader exits? - does the pty close immediately when the session leader is gone *and* the pty's foreground process group is orphaned (or empty?)? - does the pty driver send SIGHUP to all processes associated with the PTY when the session leader exits? Having the answers to these questions for each of the major platforms we can then think about how to emulate *BSD behaviour on Linux and Solaris (assuming that it's even desired). But then, we all pretty much suspect what the behaviour is (see previous posts in this thread). The notion of "flushing the pty" may not be so simple because the boundary between data last written by the session leader and data written by background processes may be indistiguishable (would that even be a problem?) - how does one "flush the pty" from the master side anyways? (by reading until read() returns EWOULDBLOCK? or is there some special ioctl() for emptying buffered data on the slave write side to the master read side?) And one more avenue that must be considered: why not just document the platform differences and leave it at that? Some will be inconvenienced, but the OpenSSH folks could just say "hey, take it to your OS vendor", say. Cheers, Nico --> -----Original Message----- > From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] > Sent: Tuesday, August 06, 2002 10:35 PM > To: Carl Brewer > Cc: Michael Robinton; openssh-unix-dev at mindrot.org > Subject: Re: so-called-hang-on-exit > > > > On Tue, 6 Aug 2002, Carl Brewer wrote: > > [..] > > > since ~ will unconditionally close a terminal window, > what's wrong with a > > > config option to do this automagically if the sysadmin > wishes to configure > > > sshd in this fashion. Give me a good reason (other than > academic) why when > > > the user or script says "bye now" that sshd should not take them > > > seriously. > > > > Not to mention the complexity of multiple chained ssh > connections, how > > many "~'s do I need to press? I'm chained in through how > many sessions > > again? > > > > Unfortunatly, Michael, you're wasting your time. None of the > > developers will see it from a 'real user' perspective. Purity > > vs practicality, and purity wins. > > > > Your going to have to excuse me. I just got back into town after a > wirlwind trip, but I don't think you are qualify to say that. > > The question that has yet to be answered is. > > *WHY* does it happen on some platforms and not others? You > run OpenSSH on > OpenBSD? No hang. > > No one has yet to even explain to us why. If one person > could explain why > without handwaving it would solve the problem because it more > than likely > is a mistake on TTY handling. > > - Ben > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >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.
Jani, Sshd normally doesn't use timeouts in the select() loop. That you're putting a timeout into the select() call "so that the select() call could not hang forever" indicates you fail to understand what's going on and are actually implementing a timeout heuristic. That may be a fine thing to do, but that is what you're doing. Specifically, in a plain one-channel pty ssh connection to an sshd on Solaris/Linux, after the session leader exits, if it leaves background process groups still running, but not interacting with the pty, then the sshd will sit there in select() waiting for: - client requests (as in new channel requests, channel close messages, or channel data, say) - those background process groups to write something to the pty The user considers the session to be finished and does *nothing* or does ~.. If he does nothing then neither does the sshd do anything. That's what you interpret as "hanging". You want a heuristic which "flushes" the pty and closes it as if it had produced EOF as it would on OpenBSD. Perhaps one way to do that would be to read() in a loop from the master pty until it returns EWOULDBLOCK, then close it and get the process started by which the channel is then closed. Or you can use a timeout, that is, keep select()ing on the pty master fildes for some time then close it. The fact that you're putting a timeout into the select() indicates that you're doing the latter. Once the pty master fildes is closed the select loop will only select on the SSH socket. By this time the client will know that the channel is closed, and it (the client) will then proceed to tear down the SSH connection (which is what you want and which will get sshd out of its select loop and thus get sshd to exit) because that is what ssh clients typically do when the last open channel is closed (that is what the OpenSSH client does, though clients are not obligated to do this - they can just reuse the SSH[v2] connection and open new channels). Cheers, Nico --> -----Original Message----- > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI] > Sent: Wednesday, August 07, 2002 3:53 PM > To: Williams, Nicolas > Cc: fcusack at fcusack.com; openssh-unix-dev at mindrot.org > Subject: RE: so-called-hang-on-exit > > > On Tue, 6 Aug 2002 Nicolas.Williams at ubsw.com wrote: > > > > > Why are putting a timeout into the sshd's select() when flushing > > the PTY? > > > > I'll admit I've neither tried the patch nor really read it. But if > > you'll rely on timeouts on one side, why not on the other. > > We did not rely on timeouts. The timeouts we're only made so that the > select() call could not hang forever. > > I really did want 0 second timeouts, but the way timeout handling was > implemented in serverloop.c prevented that (with a minimal > patch at least. > Personally I would have liked to clean up the timeout > handling; Eventually > I will have to, since I will port my older IdleTimeout to > newer openssh). > > - Jani > > >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.
Perfect. Good patch then. Indeed, I had not read the patch. Question: what happens to the background process groups? what should happen to them? By closing the pty master you cause them to get errors when they next try to interact with the pty slave. Shouldn't they get SIGHUP? Sshd cannot figure out what the process groups are, so it can't send them SIGHUP; but an external script could use the proc tools/ps/lsof to find all those orphaned process groups and HUP them. Traditionally you need nohup(1) to start background jobs which should survive sessions... Cheers, Nico --> -----Original Message----- > From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI] > Sent: Wednesday, August 07, 2002 4:26 PM > To: Williams, Nicolas > Cc: fcusack at fcusack.com; openssh-unix-dev at mindrot.org > Subject: RE: so-called-hang-on-exit >[...]> I did not implement any such thing. Read the patch. > > My second patch has no timeouts at all, but it provides > almost exactly the > same behaviour as the first.[...]> That was exactly what I did.[...]> You did not read the patch. I was doing the former. > > As I already said, the fact that the in the first patch was > something else > that 0ms was because I had to work around some historical code in the > openssh select loop, which was not written by me. I would be > happy to fix > it though, and probably will provide a patch for it > (IdleTimeout will need > it).[...]> I agree with all this. > > - Jani > > >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.