Thanks for your help, everyone. I did get a few responses saying that the
process may be backgrounding itself, which it isn't -- should have included
that info in the original email.. But it does sound like init is in fact
behaving normally, according to Harlan Braude:
-->
Yes, this is normal. Init has been designed to protect the system against
processes that exit quickly enough to cause a "forkathon", which would
quickly take over the system (a race condition). The pause gives you (root)
a chance to get in and turn off the offending inittab line and enter 'init
q'.
If the program is that essential, it should be written so that it doesn't
die off quite that often (i.e., have the developers fix the bugs! :))
<--
Thanks again!
- Sean
> -----Original Message-----
> From: Sean Cummins [mailto:scummins@e-vend.net]
> Sent: Wednesday, July 19, 2000 4:00 PM
> To: 'sun-managers@sunmanagers.ececs.uc.edu'
> Subject: Solaris init/inittab
>
>
> We're trying to make init respawn a process if it ever dies, using the
> "respawn" attribute in inittab. Right now, when we put a
> program in there
> that immediately dies, init will respawn it approximately 10
> times, then
> wait 7 minutes, and respawn it 10 times again.
>
> My question is -- is this normal behavior for init, and is
> this behavior
> consistent? We're basing a pretty important piece of our
> system on this
> property of init, and I just want to verify that this is the
> case before I
> give my word to our development team.
>
> Here is the line in my inittab:
>
> pt:234:respawn:/this/is/the/program
>
> TIA, Will summarize.
>
> - Sean
>
> ______________________________________________________________________
> Sean R. Cummins e-Vend.net Corporation
> Lead Network Engineer (888) 427-8743 x209 tel
> scummins@e-vend.net http://www.e-vend.net
>
> **************************************************************
> **********
> The information in this message (including attachments) is
> confidential.
> If the reader of this message is not the intended recipient
> or an agent
> responsible for delivering it to the intended recipient, you
> are hereby
> notified that you have received this document in error and that any
> review, dissemination, distribution, or copying of this message is
> strictly prohibited. If you have received this communication
> in error,
> please notify us immediately by e-mail, and delete the
> original message.
> **************************************************************
> *********
>
>
> S
> U BEFORE POSTING please READ the FAQ located at
> N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
> . and the list POLICY statement located at
> M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
> A To submit questions/summaries to this list send your
> email message to:
> N sun-managers@ececs.uc.edu
> A To unsubscribe from this list please send an email message to:
> G majordomo@sunmanagers.ececs.uc.edu
> E and in the BODY type:
> R unsubscribe sun-managers
> S Or
> . unsubscribe sun-managers original@subscription.address
> L To view an archive of this list please visit:
> I http://www.latech.edu/sunman.html
> S
> T
>
S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:
I http://www.latech.edu/sunman.html
S
T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:12 CDT