Gentoo Archives: gentoo-dev

From: Dmitry Yu Okunev <dyokunev@××××××××.ru>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: openrc service script dependency checker
Date: Thu, 04 Dec 2014 17:13:47
In Reply to: Re: [gentoo-dev] rfc: openrc service script dependency checker by Rich Freeman
1 Hello, everybody!
3 I'm the author of discussed patches and let me put my 2¢. I want to
4 clarify some things and explain my position… Right away sorry for my
5 English skills. Also I wrote the patches year ago and may remember
6 something incorrectly.
9 1. The Later Loop Detector
11 There are really two approaches which can complement each other. But
12 personally I as the author recommend only the "early loop detector"
13 (below - ELD) to be approved into the upstream. This is due to next facts:
14 - I'm not sure in correctness of the "later loop detector" (below — LLD).
15 - LLD can be easily replaced in most of cases by modifying 2 lines in
16 the ELD. So it's just an extra code.
18 However I can imagine few situations where ELD will be unable to handle
19 a loop situation, while the LLD will be able to. Nevertheless even if
20 this situations really exists, they should appears only in quite exotic
21 conditions (like read-only dependencies cache file). Some time is
22 required to make tests in order to verify this aspect, which can be done
23 if somebody here thinks that this is really important.
25 So I recommend to discuss only the ELD.
28 2. The Early Loop Detector, summary
30 As Andrew Savchenko already mentioned the algorithm is represented in
31 PDF-presentation [1], and ELD works while building dep tree cache.
33 [1]
36 Actually ELD is not only a detector but also a solver, so it can be
37 considered as two separate components:
38 - Loop detector (below — Detector). It detects a dependency loop chains.
39 - Loop solver (below — Solver). Analyzes different variants of loops
40 solutions and solves them (if possible).
42 I think almost everybody here agree that Detector is really required in
43 OpenRC. It's quite definitely that sysadmin should be able to see any
44 error situation on his/her machine. So let's talk only about the Solver.
45 And I think the Solver should be enabled by default. But I even don't
46 hope that somebody will support this position in this mail-list and IMHO
47 it's quite useless to argue on this issue. But I'm very sure that the
48 Solver should be saved at least as an option.
51 3. Using ELD Solver as an option
53 Sorry if I remember something wrong. I need time I don't have right now
54 to recheck and refresh my memory. But IIRC currently without the Solver,
55 OpenRC in parallel:
56 - Hangs with timeout (and can hang multiple times, as it was in may
57 case with ~60 services the same time).
58 - Just doesn't run all looped services.
60 So any extra "use" dependency can break startup of great lot of
61 services. As it already happened on Debian. Here's a quote from Gentoo
62 Handbook [2]:
64 > The *use* settings informs the init system that this script uses
65 > functionality offered by the selected script, but does not directly
66 > depend on it. A good example would be *use logger* or *use dns*. If
67 > those services are available, they will be put in good use, but if
68 > you do not have a logger or DNS server the services will still work.
69 > If the services exist, then they are started before the script that
70 > *use*'s them.
72 [2]
75 Moreover the system boot can be delayed for few minutes or even for few
76 hours (as in my case, IIRC).
78 Almost anyone tells me that the Solver is even not an option for OpenRC.
79 But I disagree. It has heuristic algorithm to minimize the detriment. If
80 you boot looping system without the Solver the detriment will be much
81 more significant. For example network and sshd wouldn't start due to one
82 extra "use" dependency and system will boot a long time. IIRC, in case
83 of Debian the whole system is not running (inc. mounting, network and so
84 on) due to extra "use" dependencies only. I can understand that you
85 don't care about Debian and I'm prepared to the
86 unfortunate fact that we will have to maintain extra patch for OpenRC
87 package in Debian. So returning to Gentoo.
89 Let's just compare behavior in loop situation with the Solver and without.
91 Without the Solver (sorry for repeating this):
92 - System will hang until timeout will be reached and so for each loop.
93 - All looping services won't start. Likely enough, system will be
94 unreachable.
96 With the Solver:
97 - System won't hang, of course.
98 - Some low-cost dependency will be removed and likely all looping
99 services will start.
102 Also what sysadmin should do to make the Solver harm him/her. He should:
103 - Enable the Solver manually in /etc/rc.conf (if it's not enabled by
104 default).
105 - Use "need" instead of "use" and "use" instead of "need" (or something
106 like this).
107 - Create the loop situation.
108 - Ignore warnings and reboot.
110 I can imagine this only if this is done willfully.
113 I very need this option in Debian and I'd prefer to use it on Gentoo. So
114 I recommend to save the Solver at least as an option.
117 4. Few comments
119 > My opinion is the less automatic adjustment we do the better.
121 Don't enable the option. :)
123 On 12/04/2014 04:59 PM, Rich Freeman wrote:
124 > I think that on a boot phase in case of parallel boot rc should try
125 > to check if loop exists and it is then print a warning and switch to
126 > a sequential boot.
128 It:
129 - breaks dependencies by guess without any heuristic;
130 - boots system non-parallel.
132 Once again let's compare with the Solver:
133 - solves with detriment minimizing heuristic (based on dependencies types);
134 - still boots system parallel.
136 > Just fix your dependencies.
138 There's no dependencies to fix. They are already right. But OpenRC
139 couldn't interpret them right. And I think Debian team won't "fix" their
140 dependencies tree through all packages with init-scripts forcing
141 themselves into scopes of every existing init/rc. Using other words,
142 you're suggesting impossible thing. Sorry, but it sounds just like "get
143 out of here" without any explanation. =\
145 > I also don't get why being as compatible as
146 > possible with LSB means that it is OK to specify non-nonsensical
147 > dependencies like A and B must both be last at the same time.
149 It's _not_ OK. But _there is_ a way to bypass extra problems. And this
150 is really very essential.
152 > You certainly couldn' guarantee a successful boot, since the
153 > configuration contains errors.
155 No one's program cannot guarantee anything (IMHO even GNU hello world
156 may be interrupted by kernel panic or may segfault in very exotic
157 environment). I think we shouldn't use this term (the same as with
158 "fact+should").
160 But the Solver can essentially increase probability of reachability of a
161 server. We should think only about should it be better or worse with the
162 Solver support. And I repeat that the Solver can be disabled by default.
163 Just it's desirable to save it as an option.
166 I'll respect whatever you all will decide here. Best regards, Dmitry.


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] rfc: openrc service script dependency checker Rich Freeman <rich0@g.o>