[squid-dev] SMP scaling in no_daemon mode?

Alex Rousskov rousskov at measurement-factory.com
Thu Jun 8 16:04:29 UTC 2017


On 06/08/2017 05:49 AM, Andreas Weigel wrote:

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

Hi Andreas,

    A very thoughtful first post, thank you. FYI: Many of your
background questions can be answered by carefully reading bug 3826
discussion, especially comments #16-18 and comments #40+, but it is
difficult to separate correct information from the discussion noise and
mistakes, so I will try to give short answers here as well.

  http://bugs.squid-cache.org/show_bug.cgi?id=3826


> What are the reasons to tie the SMP feature so tightly to the daemon
> mode of squid?

Before SMP, the daemonized process was the one that started the (only)
kid. When we added SMP, we naturally enhanced the very same code to
start more kids. We did not change -N behavior, did not need to change
it, and possibly did not even think about changing it!

As bug 3826 discussion reveals, the true meaning of -N is rather
illusive. The option is more complex than it often seems because it
affects two technically independent aspects of Squid work: The ability
to restart failing kids and the ability to run in the background. I bet
this complexity was not well understood when -N was first introduced and
the problems snowballed from there.


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

This is what --foreground should do. AFAICT, its current implementation
is broken. The fork-avoiding changes in the watch_child() part of your
patch might be moving in the right direction towards a fix.


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

AFAIK, the workers=0 bug exists without your changes (in v5, at least).

Technically, workers=0 should mean -N (see below for a summary).


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

The --foreground option is named correctly IMO. However, the current
--foreground implementation is wrong. The option should disable non-kid
forking of the master process so that the first Squid process started
remains the master process. AFAICT, that is what your patch correctly
does inside watch_child(), among many other changes that look wrong or
unfinished.


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

If I am right, we do need to change --foreground behavior. Whether that
will break any existing setups, I do not know, but even if it does, it
may be worth doing so for the long-term sanity sake.

The final fix might not require many changes, but getting everything
right in this area usually takes a lot of effort and the differences
between v3.5, v4, and v5 code do not help.


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

AFAICT, the behavior you want is what --foreground should do, and I
supported adding that option, so I do not think there is some
fundamental reason to avoid that behavior. Unfortunately, I did not
review the --foreground patch, so we now might have to break existing
deployments to fix that code :-(.

In summary, the things should work like this IMO:

* -N: The initial process is a master and a worker process.
      No kids.
      No daemonimization.

* --foreground: The initial process is the master process.
      One or more worker kids (depending on workers=N).
      No daemonimization.

* neither: The initial process double-forks the master process.
      One or more worker kids (depending on workers=N).
      Daemonimization.


Would you be willing to fix Squid to match the above summary?


Thank you,

Alex.


More information about the squid-dev mailing list