Re: [CTTE #727708] Default init system for Debian
On 02/13/2014 11:21 PM, Francesco Chemolli wrote: > > On 14 Feb 2014, at 06:31, Alex Rousskov > wrote: > >> On 02/13/2014 03:47 PM, Amos Jeffries wrote: >>> Use of "-N" with no parameter produce an error. >> >> I do not think we have to break existing scripts (some of which may >> still be working OK!). We can issue a deprecation warning but treat bare >> -N as "-N foreground" or equivalent. >> >>> Perhapse making both -N and -X take parameters now? >>> -N for the process daemonization, and -X for the debug ones TBD. >> >> We need to preserve the "no forking" or "monolith" behavior (i.e, the >> current broken -N behavior). Please do not remove it while fixing -N. It >> cannot be TBD. Setting debug_options via -X can be postponed, of course. >> >> Whether we use -N for all three modes or -N for the first two modes and >> -X for the "no forking" debugging mode is not that important to me >> personally, so I am not going to complicate things by supporting one or >> the other :-). > > I know I'm the one who cares less about backwards compatibility among us, > but.. > what if we just deprecated -N and replaced it with something different, such > as > -m as in 'mode' > -m daemon (default) > -m foreground > -m debug > > ? No objections from me. My personal preference is not to add new command-line options unless really necessary, but I can also see the reasoning behind walking away from -N that some associate with "No". Cheers, Alex.
Re: [CTTE #727708] Default init system for Debian
On 14 Feb 2014, at 06:31, Alex Rousskov wrote: > On 02/13/2014 03:47 PM, Amos Jeffries wrote: >> Use of "-N" with no parameter produce an error. > > I do not think we have to break existing scripts (some of which may > still be working OK!). We can issue a deprecation warning but treat bare > -N as "-N foreground" or equivalent. > >> Perhapse making both -N and -X take parameters now? >> -N for the process daemonization, and -X for the debug ones TBD. > > We need to preserve the "no forking" or "monolith" behavior (i.e, the > current broken -N behavior). Please do not remove it while fixing -N. It > cannot be TBD. Setting debug_options via -X can be postponed, of course. > > Whether we use -N for all three modes or -N for the first two modes and > -X for the "no forking" debugging mode is not that important to me > personally, so I am not going to complicate things by supporting one or > the other :-). I know I'm the one who cares less about backwards compatibility among us, but.. what if we just deprecated -N and replaced it with something different, such as -m as in 'mode' -m daemon (default) -m foreground -m debug ? I agree with Alex that "no-" switches are harder to consistently understand. 2c. Kinkie
Re: Fwd: [CTTE #727708] Default init system for Debian
On 02/13/2014 03:47 PM, Amos Jeffries wrote: > Use of "-N" with no parameter produce an error. I do not think we have to break existing scripts (some of which may still be working OK!). We can issue a deprecation warning but treat bare -N as "-N foreground" or equivalent. > Perhapse making both -N and -X take parameters now? > -N for the process daemonization, and -X for the debug ones TBD. We need to preserve the "no forking" or "monolith" behavior (i.e, the current broken -N behavior). Please do not remove it while fixing -N. It cannot be TBD. Setting debug_options via -X can be postponed, of course. Whether we use -N for all three modes or -N for the first two modes and -X for the "no forking" debugging mode is not that important to me personally, so I am not going to complicate things by supporting one or the other :-). Cheers, Alex.
Re: Fwd: [CTTE #727708] Default init system for Debian
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.
Re: Fwd: [CTTE #727708] Default init system for Debian
On 2014-02-14 11:32, 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. This is "background daemon" mode, yes? ie. no use of -N or use of "-N background" "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. ... and this as the "foreground daemon" mode, yes? ie. use of "-N foreground" Both are types of daemon in the init world. Just the foreground one has access to terminal/TTY output, and the PID waiting abilities systemd etc want to use. Use of "-N" with no parameter produce an error. "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. Sounds reasonable. Perhapse making both -N and -X take parameters now? -N for the process daemonization, and -X for the debug ones TBD. BTW: I was thinking -M as shorthand for Master or Mode (longhand option: --mode=foreground|background). Amos
Re: Fwd: [CTTE #727708] Default init system for Debian
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. > "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.
Re: Fwd: [CTTE #727708] Default init system for Debian
On 02/11/2014 03:16 PM, Amos Jeffries wrote: > On 2014-02-12 11:07, Henrik Nordström wrote: >> But seriously, it's a very small change to Squid. All systemd and the >> like needs is that Squid stops all the backgrounding, setsid etc done in >> watch_child(). The rest is business as usual, including watching childs. ... >> for now probably best by using yet another command line option. The >> opt_no_daemon flag (-N) is far too overloaded and used at a bit too many >> places today and trying to sort that out is likely to give some more >> gray hairs. I agree that no single -N semantics will satisfy everybody. Please note that we can still safely and sanely use "-N with a parameter" to implement any new-and-improved semantics around the same feature area without adding new command line options if we want. In other words, we can, but do not have to add more options. This "-N with a parameter" approach is covered by item (a) from my November 1 2013 email on the "[RFC] Squid process model" thread: > a) Add an optional parameter to -N to be able to switch between >"no forking" and "no daemon" semantics. For example, if "-N" is >interpreted as "No", we can have: >-N # default (to be decided) >-N daemon # Master process runs in foreground but SMP allowed >-N fork# No forking at all and, hence, no SMP. > > b) Change -N semantics from current "no forking" to "no daemon" >and add another option to enable "no forking" semantics. > > c) Leave -N semantics as current "no forking" >and add another option to enable "no daemon" semantics. 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). "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. "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. HTH, Alex.
