Simon Walter <simon@???> writes:

[...]

> On 05/05/2016 05:45 AM, Rainer Weikusat wrote:
>> It greatly reduces the number of "low-quality" (or rather, "no quality")
>> bug reports I receive as I don't (usually) get frantic phone calls at
>> 3am UK time because a server in Texas terminated itself for some
>> reason. Instead, I can collect the core file as soon as I get around to
>> that and fix the bug.
>>
>> NB: I deal with appliances (as developer) and not with servers (as
>> sysadmin).
>
> So, for example, would something like daemontools be what you use with
> your field deployed software?

I certainly wouldn't use "something like daemontools" for anything but
that's a completely different conversation (my present idea for 'server
management' is to implement whatever I need in form of relatively simple
'do one thing and do it well' C programs which can be combined freely to
create complex program invocation commands).

OTOH, I am convinced that 'automatic restarts' is a sensible policy,
especially for background infrastructure servers, as these are usually
invisible to users unless they manifest themselves in form of "the
internet doesn't work".

This is also somewhat dependent on the code and common error scenarios,
eg, 'automatically restart whatever crashed this time' is certainly not
a sensible way to handle problems which ultimatively come from
processing input from untrusted source without prior validation. But
"doesn't do input validation" is not an inherent property of code, just
something people from academistan tend to 'overlook/ implement this when
have time after kingdom came' because it's not useful for any kind of
'positive demonstration': It's neither needed for publishing a thesis
about SSL extensions nor will it get the boss off your back more
quickly.

[...]

> I would not like to, for example, install apache and mod php and have
> it restart after it has crashed due to a crappy PHP application. I am
> of the opinion that is a big security risk.

But that's exactly what you get with apache (and mod_php) when running
it as UNIX(*) server: There'll be a number of pre-forked processes for
handling client requests and a built-in supervisor daemon for managing
'handler processes': Assuming one of these crashes, this will only
affect the client connection handled by this server process at this
time. Other processes will continue to handle requests unaffected. And
the supervisor process will fork a new handler process in case the crash
cause the number of idle server to drop below the configured minimum
(MinSpareServers).

This may not work as nicely on Windows but then, electric typewriters
with mp3 playback don't make good server platforms :->>.