Hi all,
As some of you are no doubt aware that one of the design issues we
are facing with Squid these days is the process model. The current model
has a very init.d centric design and shoots itself in the foot when
encoutering third-party daemon management systems such as upstart,
systemd, and a few other less popular ones. Not that it supports many
uses of init.d very well either.
I have been thinking of updating the -N, -n -z, -k command line options
behaviour very slightly to make things a bit more flexible in a backward
compatible way.
-N - no-daemon mode
Today -N takes no parameters and disables all forking. This is great for
debugging a worker, but not much else.
If we add an optional parameter that takes the process kind name
(worker, coordinator, disker, etc.) and starts a process with that type
this will allow us to debug individual process types and allow
third-party daemon manager to kick off specific processes by type (if
they know how).
To integrate with upstart/systemd cleanly we would need a mode which
starts a process instance without forking the main processinto the
background. We could make this a special case when process kind is set
to "coordinator" - since a coordinator without other kids is kind of
useless. Or we could assign a special-case parameter specifically for
this, asterix (*) would seem to be appropriate.
-n - Windows service name
The Windows build of Squid requires a -n option to point at the
particular named service which is running in the background. Which
defaults to the name "squid" when omitted.
Making this option available outside Windows shows some promise. With
the service name being used as prefix for shm_*() paths, default pid
file name and similar things which are required to be identical between
all processes in a Squid instance this will restore the ability to run
multiple independent Squid services on the same machine regardless of
whether SMP support is used or not.
-z - store initialization mode
The -z execution is currently able to interfere with other executions
and instances of Squid set running at the same time or shortly after it
exits while the sub-processes it forks off are still running.
Due to what it is currently scoped to do (simply and specifically to
initialize and repair structural damage to a cache_dir) there is no
reason for -z to interact with any other Squid instance or even to block
on a previously existing instance already running. Although later
instances may want to block on the -z execution.
We could make two changes here to improve the situation:
1) make it support the -n mode change above, with a different default
service name "squidZ" to distinguish from other non-z instances.
Allowing an overlap of execution with an already running or later
started process.
2) make the main executed process default to either having -N properties
when SMP is disabled, or to being the coordinator when SMP is enabled.
The key criteria here is that the foreground process should never exit
until the -z processing by each forked sub-process is completed.
Preventing existing init scripts which execute -z sequentially from
breaking the main instance being started shortly after.
-k - signalling a running instance
At present this is just a command line tool to generate signals for a
running instance. If the above changes are made it will require a small
behavioural change to support the -n option and operate for all OS as it
does in Windows. By taking a targeted instance/service name and sending
the signal specifically to the main signal handling process of that
instance.
Anything I've missed? other ideas?
Amos
