On 02/13/2014 03:32 PM, Henrik Nordström wrote:
> tor 2014-02-13 klockan 09:43 -0700 skrev Alex Rousskov:
>
>> I am not sure which approach is the best, but I am sure we need to
>> clearly define and document the new semantics to avoid repeating -N
>> problems which were caused primarily by folks (including myself)
>> interpreting what -N means differently and changing the code according
>> to their own misguided interpretation.
>>
>> For example, we can define the following three modes:
>>
>> "daemon" -- Master process forks and uses setsid (what else?). No other
>> effects on Squid. For example, SMP works by forking kid processes as
>> needed. Meant for stand-alone execution. This is the default (enabled
>> when no related command line options are given).
>
> yes.
>
>> "no daemon" -- "Daemonization" steps listed in the above paragraph are
>> disabled. Thus, the master process does not fork and does not use setsid
>> (what else?). No other effects on Squid. For example, SMP works by
>> forking kid processes as needed. Meant for systemd and such.
>
> In my mind this is what -N is meant to be.
I agree now, but I did not realize that when the SMP code was written,
unfortunately.
>> "no forking" -- Squid runs a single Squid process, which works both as a
>> master process and the only worker process. No kid processes, no SMP.
>> Meant for debugging and triage.
>
> Exactly. "no forking" is more of a debug mode. Maybe time to add a
> --debug=... option to set various debug flags?
>
> --debug=nofork
>
> And also merge the -X flag into this.
No objections from me, especially if -X will be deprecated or removed
during this change. Alternatively, we can extend the -X option itself:
-X # just like it is now, no changes
-X nofork
-X monolith # I hate negative names like nofork :-)
-X ALL,9 # because the default ALL,7 us not always enough.
Thank you,
Alex.
Received on Thu Feb 13 2014 - 23:09:50 MST
This archive was generated by hypermail 2.2.0 : Fri Feb 14 2014 - 12:00:12 MST