hang on exit - bug or no bug?

Nicolas Williams Nicolas.Williams at ubsw.com
Sat Oct 6 04:01:42 EST 2001


On Fri, Oct 05, 2001 at 12:45:48PM -0500, Phil Howard wrote:
> 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).

Don't forget to ALWAYS, ALWAYS open() something appropriate for stdio
after closing stdio; /dev/null if nothing else.

...
close(0);
close(1);
close(2);
open("/dev/null", O_RDONLY);
open("/dev/console", O_RDONLY); /* or /dev/null */
open("/dev/console", O_RDONLY); /* or /dev/null */
...

Just in case any stupid library function you might use assumes that
stdio is a place to write error messages, or read from.

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

Right. That's not always an option though... :)

> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
> | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
> -----------------------------------------------------------------


Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

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