hang on exit bug under Linux

[Theo Schlossnagle]

On Monday, December 10, 2001, at 02:08  PM, Dan Kaminsky wrote:
>> Hey, I have the same problem to deal with. I deal with it. I always put
>> in explicit stdio redirections to/from /dev/null. What's wrong with 
>> that?
>
> ssh is a general purpose method of running remote commands as if they 
> were
> locally.  Not "specially written remote commands", not "custom apps".  
> Just
> remote commands.

This is the point everyone is making.  If run a poorly written daemon 
"locally", it can spit error messages at me twenty minutes later.  It 
didn't close its file descriptors.  Now, consider computers for what 
they are... trusting.  It wasn't poorly written, it was _intentionally_ 
written that way because I _want_ to see those error messages (say I am 
not smart enough to close file descriptors and use syslog) -- this is 
what the OS assumes.

You want them to run just as if they were run locally.  Find. ssh 
_should_ linger (it doesn't _hang_) and wait for the program to spit 
anything out if it will.  There is no excuse for not working around the 
problem.  Simply write a daemonizing wrapper program that fork()s and 
setsid() before it runs your command and be sure to direct you file 
descriptors somewhere other than std*.

> I shouldn't have to rewrite applications, or even have to investigate 
> how
> they function in order to run them.  For the most part, ssh is excellent
> about this.  Every once in a while though...and of course, that's the
> problem.  Nothing worse than intermittent failures.

I have application I wrote that forks and expects to write to stdout, 
ssh _better_ "hang"!  That is its job.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7