Re: [PATCH] immortal helpers

On 02/20/2010 02:30 AM, Amos Jeffries wrote:
> Alex Rousskov wrote:
>> On 02/19/2010 09:12 PM, Amos Jeffries wrote:
>>> This patch adds an advanced option to the Squid helper controls which
>>> overrides Squid dying when helpers crash.
>>>
>>> It has been found necessary in certain corner cases with PHP helpers
>>> (which have system imposed limited lifetimes) where a proxy has
>>> previously been under some load and helpers started then are timed out
>>> later under low load as a bunch. Squid may die and restart.
>>>
>>> If the proxy has been started under existing high load conditions (such
>>> as a backup coming online) this case may also occur shortly after
>>> startup. Leading to a chain reaction of restarts until load drops below
>>> number of helpers needed to trigger a death.
>>>
>>> These cases depend on external forces or helper design closing the
>>> helpers outside Squid control.
>>>
>>>
>>> There is one known issue with this option:
>>>
>>> If the helpers are really dying due to some fatal issue during their
>>> startup the use of this option would result in Squid hanging while
>>> infinitely re-starting helpers and doing no request processing.
>>
>> Missing squid.conf documentation update?
>>
>> I think "immortal" is a little strange choice for helpers that die all
>> the time :-). How about "phoenix"? It is not an adjective but it fits:
>>
>>> phoenix
>>>
>>> * A phoenix is an imaginary bird which, according to ancient stories,
>>> burns itself to ashes every five hundred years and is then born again.
>>>
>>> * If you describe someone or something as a phoenix, you mean that they
>>> return again after seeming to disappear or be destroyed. N-SING literary
>>
>> Cheers,
>>
>> Alex.
>
> The dynamic helpers are already phoenix. This is about making Squid
> itself immortal to the flames as they regenerate.

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"?

> 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?

> 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).

Cheers,

Alex.
Received on Sun Feb 21 2010 - 01:26:17 MST