1 |
Hello, |
2 |
|
3 |
On Thu, 4 Dec 2014 08:59:22 -0500 Rich Freeman wrote: |
4 |
> On Thu, Dec 4, 2014 at 7:54 AM, Andrew Savchenko <bircoph@g.o> wrote: |
5 |
> > |
6 |
> > 1. There are multiple services having "after $all" statement (an |
7 |
> > analog in Gentoo is "after *", which is currently used only by |
8 |
> > local init.d script). |
9 |
> > |
10 |
> |
11 |
> Seems to me that the solution to this is to ban this sort of syntax |
12 |
> entirely, and use proper deps. |
13 |
|
14 |
There is no serious problem in Gentoo here, because local is _the |
15 |
only_ service that uses this kind of dependency. But in Debian |
16 |
"after $all" syntax is in common use and we can't change that. |
17 |
|
18 |
The prime cause of these patches was to bring OpenRC as usable init |
19 |
system for other distributions and not to limit its scope only to |
20 |
Gentoo. And Debian has requirement of additional features in order |
21 |
to allow OpenRC to be used as a reliable replacement of other init |
22 |
systems. |
23 |
|
24 |
> WHY do we have to run local.d last? |
25 |
> Why do we have to run any of that other stuff last? |
26 |
|
27 |
I doubt this is in POSIX standard or whatever, but it is a quite |
28 |
common custom among distributions to have some rc.local service |
29 |
where admins may put their custom daemons to be started in quick and |
30 |
dirty way, so that admins without prior knowledge of how particular |
31 |
init system works may put their stuff to that rc.local script/ |
32 |
service/whatever. This is mostly needed when out-of-tree packages |
33 |
are used or in-tree packages lack init script. The former is quite |
34 |
common in production, unfortunately. |
35 |
|
36 |
> > 2. LSB dependencies are allowed to be asymmetrical relative to start |
37 |
> > and stop, while in OpenRC they are symmetrical. This yields to |
38 |
> > loops in OpenRC while in LSB the same services work fine. Example |
39 |
> > follows: |
40 |
> |
41 |
> Seems like the solution to this is to allow a different syntax for |
42 |
> start vs stop dependencies then, with the default being to keep them |
43 |
> the same if the current syntax is used. |
44 |
|
45 |
Yes, this particular case can be solved with optionally separated |
46 |
start and stop dependencies. |
47 |
|
48 |
But look at the whole picture. What happens _now_ if there is a loop |
49 |
in service dependencies? |
50 |
|
51 |
For the sake of unambiguity under "soft" loop I mean loop where |
52 |
there is at least one "after" or "use" dependency and "hard" loop |
53 |
is supposed to consist only of "need" dependencies. |
54 |
|
55 |
1. OpenRC fails to start _all_ packages in the loop (both soft and |
56 |
hard). |
57 |
2. This takes enormous amount of time: 60 seconds per loop and |
58 |
this time may be precious (e.g. system is on low battery). |
59 |
|
60 |
What proposed solutions do? |
61 |
|
62 |
1a. For the first issue early loop solver allows to start all |
63 |
services from a *soft* loop gracefully, so that all services should |
64 |
work, because all mandatory "need" dependencies will be satisfied. |
65 |
|
66 |
1b. If loop is *hard*, then later loop solver will intelligently |
67 |
break loop at some point, so that as much services as possible will |
68 |
have their "need" dependencies satisfied. Of course, some services |
69 |
may fail in this case, but this is still better than fail _all_ of |
70 |
them. |
71 |
|
72 |
2. No time will be lost in case of *soft* loop and time loss will |
73 |
be minimized in case of *hard* loop. |
74 |
|
75 |
> > So it is a statement of fact that OpenRC |
76 |
> > should be compatible with LSB dependencies. |
77 |
> |
78 |
> It seems to be a statement of fact that OpenRC ISN'T compatible with |
79 |
> LSB dependencies. What it "should" be is anything but a statement of |
80 |
> fact, which is what the word "should" means... |
81 |
|
82 |
Yes, it is not compatible now. And if OpenRC wants to step out of |
83 |
Gentoo scope to other distros, it should be. But as one can see, |
84 |
Gentoo will also benefit from proposed fixes, which will made OpenRC |
85 |
init system more robust and error-prone. |
86 |
|
87 |
> I don't get why Gentoo gets by just fine with things as they are, but |
88 |
> nobody else apparently can. Just fix your dependencies. |
89 |
|
90 |
I don't have broken dependencies on my systems right now. And this |
91 |
is not a discussion of my personal issues at all. What I'm trying |
92 |
to do is to make OpenRC robust and resilient to errors which may |
93 |
occur as well as expand its scope outside of Gentoo as a mature |
94 |
init system. |
95 |
|
96 |
> > Warnings for users about loops is a good idea for Gentoo, but will |
97 |
> > produce a lot of not always wanted output on Debian, that's why |
98 |
> > this option should be configurable. |
99 |
> |
100 |
> I'd call these situations errors - a warning should certainly be used. |
101 |
|
102 |
They are errors in Gentoo, but in some cases are normal in Debian, |
103 |
because dependencies are asymmetric there. That's why switch to |
104 |
omit them was requested. |
105 |
|
106 |
> > As for Gentoo it is desirable too, becase it is better to boot |
107 |
> > system somehow instead of not booting it at all (or with long |
108 |
> > delays due to 60-seconds timeout on service startup). This is |
109 |
> > crucial for remote servers, e.g. admin needs to reboot machine due |
110 |
> > to critical security kernel update ASAP and having it hang during |
111 |
> > boot is really a very bad idea. |
112 |
> |
113 |
> So, I'm fine with some kind of emergency mode, though expecting it to |
114 |
> work on a remote server might be asking a bit much. |
115 |
|
116 |
Why? Especially if this is doable and there is already working code |
117 |
present. |
118 |
|
119 |
> Dropping to shell is certainly preferable to just hanging. |
120 |
|
121 |
Yes. But booting as much services as possible is even more |
122 |
preferable, especially when box is remote. |
123 |
|
124 |
> You certainly couldn't |
125 |
> guarantee a successful boot, since the configuration contains errors. |
126 |
|
127 |
Nobody can. But we can raise the probability of successful boot. |
128 |
|
129 |
> > Another example from my experience |
130 |
> > is emergency shutdown due to power failure and low battery signal |
131 |
> > from sys-power/nut. I had several nasty cases when system failed to |
132 |
> > shutdown properly due to 60-second timeouts for services failed to |
133 |
> > shutdown — battery just ran out of charge while OpenRC was try to |
134 |
> > do thing "right way". |
135 |
> |
136 |
> Seems like the solution to this is to let you configure the timeout |
137 |
> per-service and globally, and maybe even give you the ability to |
138 |
> override it at time of shutdown. During a routine shutdown you don't |
139 |
> want the service manager randomly killing stuff. |
140 |
|
141 |
It is already configurable globally IIRC. What will be probably |
142 |
more useful is to have separate start and stop timeout values and/or |
143 |
maybe a way to set emergency shutdown timeout value. |
144 |
|
145 |
Best regards, |
146 |
Andrew Savchenko |