hang on exit - bug or no bug?
Phil Howard
phil-openssh-unix-dev at ipal.net
Sat Oct 6 03:45:48 EST 2001
Nicolas Williams wrote:
> No, don't modify your OS' startup scripts, just run them differently.
>
> Look, the fds are left open, so you potentially lose data, but you don't
> care, right? So why not run those scripts like so:
>
> ssh -n root at somehost /etc/init.d/syslog stop
> ssh -n root at somehost /etc/init.d/syslog start \>/dev/null 2\>\&1
I want to see the messages at startup that indicate why it didn't
start, if that happens. Of course the blame is that many daemons
are not designed to do ths properly. But the two that I am now
designing/coding will be. The servers will close the standard
descriptors once it has determined the startup conditions are fine
(of course later failures will have to go to syslog).
> You have this issue with RSH too you know. I long ago learned to deal
> with this by manually redirecting stdio to /dev/null. And yes, sometimes
> you care about some bit of command's output, because you may want to see
> error msgs from /etc/init.d/syslog, say. There's a few solutions:
>
> - write a separate script for checking that the batch job is doing ok
> - use intr (yes, Solaris doesn't have one -- write one yourself) on the
> client side to set a timeout after which to kill ssh
> - write an intr-like command for the remote side that closes the fds
> after a timeout and which might be used like so:
>
> ssh -n somehost somecommand 2\>\&1 \| iointr -t 30
> - fix the scripts
- fix the daemons
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
More information about the openssh-unix-dev
mailing list