so-called-hang-on-exit

[Carl Brewer]

Michael Robinton wrote:
>>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.

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.

My scripts mostly have to do ugly things like this :

/etc/rc.d/init.d/SNPd start < /dev/null > /dev/null 2>&1

So I can restart a badly behaved (because it writes to stdout
and stderr when it starts, and if it loses those connections it
just carries on anyway - how -evil-) daemon or two.

Nothing stopping a patch to fix the 'not-a-problem' being applied :)

Carl