[squid-dev] SMP scaling in no_daemon mode?

Andreas Weigel andreas.weigel at securepoint.de
Thu Jun 8 11:49:47 UTC 2017


Hi everybody,

Short introduction:

We are a small company using Squid in our Unified Threat Management 
(UTM) series of products. I am working as a Backend developer and have 
tackled some problems with cross-compiling Squid in the past (see the 
unfortunately unanswered bug report at 
http://bugs.squid-cache.org/show_bug.cgi?id=4650).

The Problem:

We're using runit (http://smarden.org/runit/) to supervise squid 3.5.21 
in "no_daemon"-mode (-N option).

Being interested in the SMP feature of squid we face the problem that it 
only works in daemon mode, which is inherently incompatible with runit 
supervising the service (would notice the process exiting and start it 
over and over again).

What are the reasons to tie the SMP feature so tightly to the daemon 
mode of squid? I played with the code and was able to alter the behavior 
and allow staying in foreground AND forking children that take the role 
of workers and coordinators etc.. I also managed to make the "master" 
process (the one staying in foreground) to react on a SIGTERM by 
signalling its children to shutdown. See the attached patch against the 
3.5 branch of squid, which is not meant as a real contribution but just 
to show what I did.

I do acknowledge that I do not understand all implications of the 
changes I made, but in general, the program behaves as expected, with 
the slight exception that it runs into an exception if the configuration 
directive "workers 0" is given.

I noticed that in the squid 4 branch, the behavior again has slightly 
changed. What I get from the code in main.cc:watch_child is, that the 
"daemon" process stays alive until all its children terminate if the 
rather strangely named "opt_foreground" option is set. Additionally, the 
"master" process (the one created by the daemon's fork) processes 
signals and broadcasts those to its children.

Isn't it a rather small step from here to just prevent daemonizing and 
let the master process run in "real foreground"? That way, it seems to 
me that runit would not have any problems managing squid with standard 
signals and without changing the behavior of squid?

Am I missing something completely here? Is there some hidden problem 
that would break everything if instead of the "daemon-forking"-process, 
the master process itself would stay in the foreground? Or would it be 
possible?

Kind Regards,

Adnreas Weigel

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: squid_smp_nodaemon.patch
Type: text/x-patch
Size: 3066 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20170608/3f6999d8/attachment.bin>


More information about the squid-dev mailing list