rc and smf

[Dan Melomedman]

Matthew Dillon wrote:
>     Hmm.  Well, I have to say that in my opinion a service failure is a 
>     critical bug in the application.   I usually go in and fix the application

Nobody argues this. Again, this is one of the reasons why people
supervise in the first place. There's nothing stopping you to add
an alert feature to a supervisor.

>     software rather then write monitoring programs for it (other then to 
>     tell me if it has failed).   Most service oriented applications fork()
>     on connect (a DNS cache being an exception), and those that have the

Nothing stops the parent process of your forked children to be killed or
crashed, obviously for some reasons already discussed.

>     The only time a service has failed on crater.dragonflybsd.org has been
>     when I screwed it up myself, accidently, or when the hard drive physically
>     crashed.  That's it.  I certainly don't spend my time worrying at night
>     that random services might not be working!

That's your personal experience with service faults. Others may not
have been so fortunate.

>     of reliability from a pot-luck dinner as you can from a carefully
>     prepared meal.

I am not trying to compare Unix to RTOSes. For example, Erlang is written
for Unix, and it's naive to think that people run some mission critical
software on RTOSes only. Ericsson AXD301 ATM switch runs Erlang, presumably
under a flavor of Unix, but I haven't verified this.

What I can do is try and make a more reliable and fault-tolerant use of
the existing generic OSes such as *BSD or Linux, that's why people write
syslog and init replacements. Too bad people that build these OSes often
ignore issues that are so obvious to some of their users. Please don't
take it as an insult, just an observation.