Re: rc and smf
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
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
option of forking or running threaded I usually tell to fork. This
greatly narrows the amount of code that actually has to run in the
parent's connection-accepting loop and works as well as or better then a
service monitor. The proxies I wrote at BEST Internet a long time ago
all did that, and those applications never failed. Not once. Ever.
They handled millions of emails a day.
Insofar as the remaining applications go, I have seen occassional
failures and certainly failures can occur, but it isn't a 'random'
occurance. Some applications are prone to problems, some never die.
I have lost older BIND demons to corruption (not actual segfaults),
but I don't think I've had a dns failure for over two years now, and
that is plenty long enough for me to prefer having the system yell and
scream at me if it dies rather then restart and forget.
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!
But anyhow, back to service failures... service failures do not always
end in a crash. Take BIND for example. It is far more likely that
BIND's cache will become corrupted then for BIND to actually crash. A
simple 'detect that it died and restart' monitor doesn't help you there.
What you have to do is have a program which actually goes in and uses
the service for real. e.g. for a web server a program which connects
to it every minute and retrieves the most complex CGI'd page it
serves out. That's the sort of monitoring we need... not this simple
it-dies-and-we-restart stuff. Service corruption is the far more likely
scenario these days.
And please, Dan, stop trying to compare generic UNIX systems to RTOSes
and dedicated custom turnkey systems. Those systems run dedicated,
heavily maintained software, whereas you are running run-of-the-mill
third party software (as are we). You can hardly expect the same level
of reliability from a pot-luck dinner as you can from a carefully
prepared meal.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 28 之 53 篇)：