On 2/11/2013 2:11 a.m., Amos Jeffries wrote: > 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 - 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.
The opening up of -n is now done in trunk. Anything which needs to be unique for the instance/service should begin to make use of the global char* service_name as part of its uniqueness. I am working now on updating the foo.ipc socket paths. That is tracked in http://bugs.squid-cache.org/show_bug.cgi?id=3608 with a patch available shortly. PID file is the trickiest piece. I am thinking we will need to convert the squid.conf string directive from file+path into just path, and generate the filename from the service_name instead of allowing manual configuration of it. Amos
