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
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
