1 |
Hello, |
2 |
|
3 |
On Thu, 4 Dec 2014 12:28:59 -0500 Rich Freeman wrote: |
4 |
> On Thu, Dec 4, 2014 at 11:12 AM, Andrew Savchenko <bircoph@g.o> wrote: |
5 |
> > On Thu, 4 Dec 2014 08:59:22 -0500 Rich Freeman wrote: |
6 |
> >> On Thu, Dec 4, 2014 at 7:54 AM, Andrew Savchenko <bircoph@g.o> wrote: |
7 |
> >> > |
8 |
> >> > 1. There are multiple services having "after $all" statement (an |
9 |
> >> > analog in Gentoo is "after *", which is currently used only by |
10 |
> >> > local init.d script). |
11 |
> >> > |
12 |
> >> |
13 |
> >> Seems to me that the solution to this is to ban this sort of syntax |
14 |
> >> entirely, and use proper deps. |
15 |
> > |
16 |
> > There is no serious problem in Gentoo here, because local is _the |
17 |
> > only_ service that uses this kind of dependency. But in Debian |
18 |
> > "after $all" syntax is in common use and we can't change that. |
19 |
> > |
20 |
> |
21 |
> But Debian CAN change that. Why don't they? Do they want to use OpenRC or not? |
22 |
|
23 |
That's a complicated issue. As far as I understand current |
24 |
situation, majority of Debian devs are happy with systemd and |
25 |
absolutely don't care about any other possible alternative. But |
26 |
there are a few people who do care. |
27 |
|
28 |
Under these conditions it is highly unlikely that anything in |
29 |
Debian dependencies approach will change for the sake of OpenRC if |
30 |
it works fine for them with their LBS and systemd right now |
31 |
irregardless of is it right or wrong way for things to be done. |
32 |
|
33 |
If we can tune OpenRC for their demands without damaging default |
34 |
OpenRC setup, why not? |
35 |
|
36 |
> I didn't ask why we need local.d. I asked why we need to run it LAST, |
37 |
> and why we need to run all of that other stuff LAST? Of course, the |
38 |
> reality is that we aren't running all of that stuff last since exactly |
39 |
> one script can REALLY be run last. |
40 |
> |
41 |
> If your answer is that something in local.d might need to use the |
42 |
> network, then specify that it needs the network. If the answer is |
43 |
> that it needs to use nfs, then specify that it needs to use nfs. If |
44 |
> it needs to happen after a bunch of random things but you can't be |
45 |
> sure which things they are, then just create a virtual service and |
46 |
> make it need that. |
47 |
> |
48 |
> The solution is the same for both local.d and all that "other stuff" |
49 |
> that "needs to be last." Just specify what they actually need. This |
50 |
> is a dependency-based service manager. |
51 |
|
52 |
This will require every sysadmin to know well how openrc works and |
53 |
how to specify appropriate dependencies for custom out-of-tree |
54 |
daemons. While I support the idea that sysadmins should be well |
55 |
prepared to tweak internals of systems they are working with — and |
56 |
to know this internals well in order to do such tweaks —, in real |
57 |
life people often don't have time to dig such deep into the system |
58 |
and will prefer other solutions which keeping stuff simple. |
59 |
|
60 |
local.d where people can just put their scripts without handling |
61 |
any deps is a simple way. That's why we need it. (Of course if |
62 |
someone dislikes this approach, it not hard to disable local.d |
63 |
at all.) |
64 |
|
65 |
And if local.d needs dependencies to be specified how does it |
66 |
differs from just writing plain new service and putting it into |
67 |
init.d? Frankly, I do such things when I need custom complicated |
68 |
services for my needs. |
69 |
|
70 |
> >> It seems to be a statement of fact that OpenRC ISN'T compatible with |
71 |
> >> LSB dependencies. What it "should" be is anything but a statement of |
72 |
> >> fact, which is what the word "should" means... |
73 |
> > |
74 |
> > Yes, it is not compatible now. And if OpenRC wants to step out of |
75 |
> > Gentoo scope to other distros, it should be. But as one can see, |
76 |
> > Gentoo will also benefit from proposed fixes, which will made OpenRC |
77 |
> > init system more robust and error-prone. |
78 |
> |
79 |
> I think you meant to say something different. :) |
80 |
> |
81 |
> This honestly seems like the general trend of ignoring compiler |
82 |
> warnings. I'm not suggesting that the solution is -Werror. However, |
83 |
> what you propose basically makes the service startup process less |
84 |
> deterministic, and everytime I read one of those threads on service |
85 |
> managers it seems like everybody is railing about how that is a bad |
86 |
> thing. |
87 |
|
88 |
What I basically propose is to turn soft loops from errors to |
89 |
warnings. Behaviour will be still deterministic (because early loop |
90 |
solver uses deterministic and not random approach to broke loops), |
91 |
but more sophisticated and slightly less transparent of course. |
92 |
|
93 |
> >> I don't get why Gentoo gets by just fine with things as they are, but |
94 |
> >> nobody else apparently can. Just fix your dependencies. |
95 |
> > |
96 |
> > I don't have broken dependencies on my systems right now. And this |
97 |
> > is not a discussion of my personal issues at all. What I'm trying |
98 |
> > to do is to make OpenRC robust and resilient to errors which may |
99 |
> > occur as well as expand its scope outside of Gentoo as a mature |
100 |
> > init system. |
101 |
> |
102 |
> There is a difference between tolerating a random error, and building |
103 |
> a system that tries to do the right thing (defined as something other |
104 |
> than "error, fix your mess") when you throw a heap of garbage at it. |
105 |
> On the one hand you talk about error resilience, and on the other you |
106 |
> talk about this just being the way Debian does things and there isn't |
107 |
> any error in the first place. |
108 |
> |
109 |
> Just fix the dependencies. |
110 |
|
111 |
They may randomly broke during update and I will not know they are |
112 |
broken until reboot, where system will hang. |
113 |
|
114 |
> And a box with remote access only with no other provision for console |
115 |
> access is the last place you should be trying to run stuff like this. |
116 |
|
117 |
I already tried this resolver on such box and I'm satisfied with |
118 |
result :) Though I can't recommend this kind of experiment for a |
119 |
unprepared user. |
120 |
|
121 |
Best regards, |
122 |
Andrew Savchenko |