hang on exit - bug or no bug?

[Schieber, Dustin]

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
option...

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

Thanks! 
-das





> -----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.
>