DragonFly kernel List (threaded) for 2003-07
Re: dynamic /bin /sbin
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1059173137 crater_reader.dragonflybsd.org 267 184.108.40.206
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:347
Matthew Dillon wrote:
> One thing that comes to mind is the standard server fork model. For
> example, sendmail and apache use this model and while individual children
> might die occassionally I've never seen the *service* go poof.
I worked for a large web hosting company (Interland) for many years.
I've seen apache and sendmail die plenty of times. If you beat anything
hard enough, it will die ocassionally.
> We could do something similar. Perhaps we wouldn't fork for each
> connection but the main server could certainly fork off a child and then
> monitor it, or fork off a child based on the originator of the message
> as a means of securing the interaction.
> I really dislike service monitors, because it implies that a lack of
> reliability exists which requires the monitor for robustness. I also
> reject the idea that a service monitor improves robustness. In all
> the embedded projects I had ever done all the service monitor does is
> act like a watch dog. If something goes wrong it screams merry hell
> but it doesn't try to fix it.
I don't know much about embedded systems, since I've always worked for
service providers. But where I come from, we always assume that things
will hiccup ocassionally. So, you might as well prepare for it and
handle the situation in a systematic fashion. Usually, the breakage is
due to to migrations, upgrades, security patching, whatever. Even with
properly run servers, someone will ocassionally bump into something and
break it in subtle ways. Of course, this would always show up by things
dieing in the middle of the night.
Now, I agree you should fix the base problem. But, it doesn't hurt to
prepare for the worst.