Re: [PATCH] immortal helpers

On Sun, Feb 21, 2010 at 2:25 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> When Squid dies due to frequent helper failures so do helpers. Thus,
> strictly speaking, a current helper is not a true "phoenix". Also, the
> option is applied to the helper, so it should focus on what happens to
> the helper and not Squid itself.
>
> Perhaps we should use something more direct and less allegorical like
> "keep_restarting", "ignore_frequent_failures", or
> "restart_on_frequent_failures"?

melikes.

>> I've left the doc out for now since I'm not sure I really want this to
>> be widely used until we can get rid of the fork bomb as Kinkie named it.
>
> The reasons you mention seem like a good justification for this option
> official existence. I do not quite get the "fork bomb" analogy because
> we are not creating more than a configured number of concurrent forks,
> are we? We may create processes at a high rate but there is nothing
> exploding here, is there?

Fork is expensive and is a kernel op. Fork too muck (as in, as fast as
a process can), and the system will grind to a halt, including for
most purposes the ability for the admin to troubleshoot.

>> If anyone can think of a reliable way to detect broken helper crashes
>> while also permittig 100% of the helpers to exist at any given time
>> (real closure exit, not a crash). I'd really like to be able to do that
>> instead of all this close-per-time fudging.
>
> The forking/waitpid code in main.cc analyses the exit status of a kid.
> Can we rely on that to cover your use case? I think we can ignore the
> fact that some helpers are poorly written because we are not making
> things worse for them (but may be making things better for well-written
> ones).

I agree

-- 
    /kinkie