hang on exit - bug or no bug?

Schieber, Dustin dschiebe at cisco.com
Fri Oct 5 02:11:18 EST 2001

Yes, I think it would be nice to have this as an option. I'm not that
concerned about the inconvenience of a hang in an interactive session.
I've very concerned about batch jobs that hang.

I agree with you that it's best to just resolve the problem with the
open fds on the server side.  But again, this is a less than ideal
solution from a sysadmin's perspective.  Several of the issues I've
heard of involve scripts included with the OS. For example, I've
verified the hang occurs when simply restarting syslog or the snmp
agents on a Sun box.  (/etc/init.d/syslog stop|start)
(/etc/rc3.d/S76snmpdx stop|start).  Of course I can modify these scripts
to utilize the workaround. But it would be nice to have another

I've also seen this problem with various 3rd party software packages.
Apparently this is a widespread problem with the open fds.  


> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
> Sent: Thursday, October 04, 2001 10:37 AM
> To: Markus Friedl
> Cc: Phil Howard; openssh-unix-dev at mindrot.org
> Subject: Re: hang on exit - bug or no bug?
> I think the requestor here wants this behaviour and wants it to be
> optional. This seems acceptable to me (not an OpenSSH 
> maintainer), but:
> I also think it's silly -- if you know you'll have children on the
> server side hanging on to the fildes and you don't want them to, then
> re-work what you're doing on the server side so that this hack is not
> necessary.
> Nico
> On Thu, Oct 04, 2001 at 04:27:02PM +0200, Markus Friedl wrote:
> > On Thu, Oct 04, 2001 at 09:01:32AM -0500, Phil Howard wrote:
> > > So is this because the patch itself is undesired (flawed, 
> incomplete,
> > > not the right solution, or not a problem to be solved), or is it
> > > because OS-specific conditional compilation is undesired?
> > 
> > it's because calling shutdown() before reading all remainig 
> data from
> > the pipe is wrong.
> > 
> > it will cause data loss like the older so called bug fixes did.
> > 
> > we will include bug fixes, but only if they don't break ssh.
> --
> 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