[squid-dev] [RFC] Fix shared memory initialization, cleanup. Ensure its usability.

[Amos Jeffries]

On 10/12/2015 1:24 p.m., Alex Rousskov wrote:
> On 12/09/2015 04:24 PM, Amos Jeffries wrote:
>> On 10/12/2015 10:49 a.m., Alex Rousskov wrote:
>>>>> Questions: Should we add a configuration directive to control whether
>>>>> mlock(2) is called? If yes, should mlock(2) be called by default?
>>>>> Should mlock(2) failures be fatal?
> 
>>>> My answers are no, yes, yes. Since this is a startup thing squid.conf
>>>> post-processing is probably too late.
> 
> 
>>> Shared memory is not allocated until _after_ we parse squid.conf.
> 
> 
>> Ah. Okay.
> 
> 
> Does this understanding change your no/yes/yes answers?
> 

It makes them "maybe", no, yes.

Though I am still not convinced exactly that squid.conf is the right
place. As I said before:
"
In general if a setting is not something that can have a reasonable
temporary default for a while, then be switched around in realtime. Then
squid.conf is not a good place for it.

I would make it mandatory on "-k check" (but not -k parse). Optional
through a command line parameter on all other runs. (Remember we have
long-args possible now so no need to squeeze it into a gap.)
"

Which is *not* doing mlock by default (retaining current behaviour). The
slowdown then only happens on -k check, which is the manual test to
check for problems. If mlock has a problem, a FATAL debugs (maybe exit
too, but could keep going to find other errors) during the test run is
very appropriate.

The other (default / normal) runs having it OFF by default, since the -k
check should have confirmed already that it is going to work. Unless the
admin explicitly sets the config / command line option to ON. In which
case complaints of slowdown are unjustified, and they can be told to
disable again.


> My plan was to tell them to disable mlock() (via a new squid.conf
> directive) if all of the items below apply to them:
> 
> (a) mlock() is successful now
> (b) they are reasonably sure no environment or configuration changes
>     will make mlock() unsuccessful (if it is re-enabled) without them
>     knowing about the problem
> (c) mlock() slows things down too much in their setup
> (d) they want to trade faster startup for micro delays during runtime
> 

Which seems to me all the things a -k check execution run will be
testing for naturally. So if mlock errors are fatal on -k check, they
get alerted to fix it before the running process is signalled to restart
with the new config.

Amos