Simon Walter <simon@???> writes:
> On 05/05/2016 11:11 PM, Rainer Weikusat wrote:
>> 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".
>
> I understand your position.

Maybe, maybe not. Rather not, actually. But that's not really important.

[...]

> I am not the author of apache. So I am not going to make assumptions
> about when it can or cannot be automatically restarted safely.

Unless you modify the code, you are (as I already explained) not in the
position to decide this: Apache has 'process supervision and automatic
restarts' built in so that it can reliably provide a service despite
transient/ isolated software errors (not related to 'input handling
buffer overflows') and other, adverse events, eg, (as I already
mentioned), system temporarily running out of disk space.

The same is actually applicable to any (UNIX(*)) forking server
(include, as was mentioned, servers running from inetd). Eg, the 'Samba
Architecture' document states that

    The longer versions is that there are very good reasons for not
    making smbd multi-threaded. Multi-threading would actually make
    Samba much slower, less scalable, less portable and much less
    robust. The fact that we use a separate process for each
    connection is one of Samba's biggest advantages.

        [...]

        if one thread dies (eg. a seg fault) then all threads die. We
        can immediately throw robustness out the window.

        https://www.samba.org/samba/docs/man/Samba-Developers-Guide/architecture.html#id2556751

IOW, that's not a (somewhat suspicious) 'necessary evil in some HA
situation', as the person I was originally replying to suggested, but
rather a tried-and-trusted design principle of high-profile servers
supposed to operate reliably.

I'm intentionally quoting 'authorities' despite this doesn't really put
more weight behind anything (as mentioned in the most-recent build
system support software related thread) as this will hopefully make
circling around the technical issue in order to get to making assertions
about the deranged state of mind of people who don't agree with a
certain opinion ("Are you anxious to ... ?") somewhat more difficult.