[squid-dev] SMP scaling in no_daemon mode?

[Andreas Weigel]

Hi again,

> It feels like you may be drifting into a dangerous territory of
> fixing/changing "everything" related to SMP.

I have to admit that I have a tendency to do so; however, I really tried 
hard to focus on the --foreground option with my new patch against 
squidv4 and trunk 
(https://code.launchpad.net/~andwei/squid/fix_option_foreground/+merge/325395).

> You may be right, but I would _not_ change that terminology now because
> all the renaming will obfuscate your true fix and make it more difficult
> to understand/review. It may also preclude v3.5 acceptance.

I have to disagree to that one. The last few days I tried to understand 
how to use the SMP feature and at the same time to not daemonize squid. 
After much reading and confusion I arrived at "ok, not possible" without 
hacking around the daemonizing or changing squid code.

Looking at the Code for 3.5 I was very confused by the combination of 
Config.workers and opt_no_daemon. The names of options and functions did 
their best to add to the confusion. I think we agreed that due to 
historical reasons, the -N option is doing something different now 
(v4/trunk) from what its description is implying. My (v4/trunk) patch 
therefore changes the names of this option and the function to retrieve 
its value to be more clear, as well as the description of the feature. I 
do think that my changes are all related to the same thing, namely 
allowing a "no daemon" mode with --foreground while retaining the old -N 
functionality, but calling the latter by a more apt name.

> You may be right, but I would _not_ change that terminology now because
> all the renaming will obfuscate your true fix and make it more difficult
> to understand/review. It may also preclude v3.5 acceptance

See above. I do not expect my patch to be applicable to v3.5. Too many 
changes there plus the --foreground option is not even available here. 
I'll try to make it work for us and locally apply a patch until moving 
to v4.

> When daemonized, Squid master process does not support reconfiguration
> at all. There are plans to change that, but those difficult changes are
> completely outside your project scope.

My impression was that the current v4/trunk branches do already allow 
exactly that: sending a SIGHUP to the master process made all children 
reconfigure themselves (wrong?) -- I didn't change anything there.

>> What I get from http://bugs.squid-cache.org/show_bug.cgi?id=3826#c40 is,
>> that the mentioned setup works because systemd broadcasts
>> (KillMode=mixed) the signals to all child processes.
>  From design point of view, Squid should not rely on 3rd party
> applications sending signals to kids. If such broadcast works today in
> some environment, great, but this is not a part of Squid interface. As
> far as signaling is concerned, Squid interface is the PID file.
I think we agree here. I just gave the example to illustrate how it 
should *not* be working.

With the --foreground option working as expected, however, a supervising 
process may send signals to its initial child process, which currently 
(v4/trunk) will always be the squid master. Thereby, the PID file (and 
all possible race conditions associated with it) are not even necessary. 
While this does not seem to be the intended interface, it IMHO is an 
improvement to determining the process ID by reading some PID file and 
works great for supervision schemes that do not like daemons.

Thanks again very much for the quick reactions and the fruitful discussions.

Kind Regards,
Andreas

PS: I do understand your reluctance to change function/variable names 
and/or description of command line options. I still think it is better 
to have those updated, even if it may slightly obfuscate the actual 
behavioral change. I also believe in the broken window theorem and try 
to at least fix some of those from time to time. As noted before, I once 
tackled a cross-compilation issue with squid and encountered diverse 
variables/macros referring to the same concept but used differently 
throughout the code (Squid_MaxFd, SQUID_MAXFD), eventually caused a 
dangerous segfault (see bugs.squid-cache.org/show_bug.cgi?id=4650 if you 
are interested -- the patch I proposed there also tried to fix the issue 
by introducing various renames, which is probably the reason that no one 
ever cared to look at it ;-/ )

-- 
Mit freundlichem Gruß / Best regards,

Andreas Weigel
UTM Backend Developer

Securepoint GmbH
Salzstrasse 1
D-21335 Lüneburg

https://www.securepoint.de

Tel.: +49(0)413124010
Fax: +49(0)4131240118

Geschäftsführer: Lutz Hausmann, Claudia Hausmann
Amtsgericht Lüneburg HRB 1776
USt.-ID-Nr.: DE 188 528 597