Re: dynamic /bin /sbin

[Richard Coleman <richardcoleman@xxxxxxxxxxxxxx>]

nflybsd.org> <200307252214.h6PME2kW053246@xxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <200307252214.h6PME2kW053246@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 36
Message-ID: <3f21b310$0$267$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 24.98.233.138
X-Trace: 1059173137 crater_reader.dragonflybsd.org 267 24.98.233.138
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.

Richard Coleman