1 |
On Thu, Dec 4, 2014 at 11:12 AM, Andrew Savchenko <bircoph@g.o> wrote: |
2 |
> On Thu, 4 Dec 2014 08:59:22 -0500 Rich Freeman wrote: |
3 |
>> On Thu, Dec 4, 2014 at 7:54 AM, Andrew Savchenko <bircoph@g.o> wrote: |
4 |
>> > |
5 |
>> > 1. There are multiple services having "after $all" statement (an |
6 |
>> > analog in Gentoo is "after *", which is currently used only by |
7 |
>> > local init.d script). |
8 |
>> > |
9 |
>> |
10 |
>> Seems to me that the solution to this is to ban this sort of syntax |
11 |
>> entirely, and use proper deps. |
12 |
> |
13 |
> There is no serious problem in Gentoo here, because local is _the |
14 |
> only_ service that uses this kind of dependency. But in Debian |
15 |
> "after $all" syntax is in common use and we can't change that. |
16 |
> |
17 |
|
18 |
But Debian CAN change that. Why don't they? Do they want to use OpenRC or not? |
19 |
|
20 |
> |
21 |
>> WHY do we have to run local.d last? |
22 |
>> Why do we have to run any of that other stuff last? |
23 |
> |
24 |
> I doubt this is in POSIX standard or whatever, but it is a quite |
25 |
> common custom among distributions to have some rc.local service |
26 |
> where admins may put their custom daemons to be started in quick and |
27 |
> dirty way, so that admins without prior knowledge of how particular |
28 |
> init system works may put their stuff to that rc.local script/ |
29 |
> service/whatever. This is mostly needed when out-of-tree packages |
30 |
> are used or in-tree packages lack init script. The former is quite |
31 |
> common in production, unfortunately. |
32 |
|
33 |
I didn't ask why we need local.d. I asked why we need to run it LAST, |
34 |
and why we need to run all of that other stuff LAST? Of course, the |
35 |
reality is that we aren't running all of that stuff last since exactly |
36 |
one script can REALLY be run last. |
37 |
|
38 |
If your answer is that something in local.d might need to use the |
39 |
network, then specify that it needs the network. If the answer is |
40 |
that it needs to use nfs, then specify that it needs to use nfs. If |
41 |
it needs to happen after a bunch of random things but you can't be |
42 |
sure which things they are, then just create a virtual service and |
43 |
make it need that. |
44 |
|
45 |
The solution is the same for both local.d and all that "other stuff" |
46 |
that "needs to be last." Just specify what they actually need. This |
47 |
is a dependency-based service manager. |
48 |
|
49 |
What would happen if we started creating ebuilds that had some kind of |
50 |
optional dependency on "*/* because we wanted to make sure they're |
51 |
always the last thing to be installed since we're too lazy to specify |
52 |
what the actual dependencies are? Presumably Debian has figured this |
53 |
out for their package manager, since they were one of the first to |
54 |
have a decent dependency-based package manager in the first place. |
55 |
|
56 |
>> |
57 |
>> It seems to be a statement of fact that OpenRC ISN'T compatible with |
58 |
>> LSB dependencies. What it "should" be is anything but a statement of |
59 |
>> fact, which is what the word "should" means... |
60 |
> |
61 |
> Yes, it is not compatible now. And if OpenRC wants to step out of |
62 |
> Gentoo scope to other distros, it should be. But as one can see, |
63 |
> Gentoo will also benefit from proposed fixes, which will made OpenRC |
64 |
> init system more robust and error-prone. |
65 |
|
66 |
I think you meant to say something different. :) |
67 |
|
68 |
This honestly seems like the general trend of ignoring compiler |
69 |
warnings. I'm not suggesting that the solution is -Werror. However, |
70 |
what you propose basically makes the service startup process less |
71 |
deterministic, and everytime I read one of those threads on service |
72 |
managers it seems like everybody is railing about how that is a bad |
73 |
thing. |
74 |
|
75 |
> |
76 |
>> I don't get why Gentoo gets by just fine with things as they are, but |
77 |
>> nobody else apparently can. Just fix your dependencies. |
78 |
> |
79 |
> I don't have broken dependencies on my systems right now. And this |
80 |
> is not a discussion of my personal issues at all. What I'm trying |
81 |
> to do is to make OpenRC robust and resilient to errors which may |
82 |
> occur as well as expand its scope outside of Gentoo as a mature |
83 |
> init system. |
84 |
|
85 |
There is a difference between tolerating a random error, and building |
86 |
a system that tries to do the right thing (defined as something other |
87 |
than "error, fix your mess") when you throw a heap of garbage at it. |
88 |
On the one hand you talk about error resilience, and on the other you |
89 |
talk about this just being the way Debian does things and there isn't |
90 |
any error in the first place. |
91 |
|
92 |
Just fix the dependencies. |
93 |
|
94 |
And a box with remote access only with no other provision for console |
95 |
access is the last place you should be trying to run stuff like this. |
96 |
|
97 |
> |
98 |
>> > Warnings for users about loops is a good idea for Gentoo, but will |
99 |
>> > produce a lot of not always wanted output on Debian, that's why |
100 |
>> > this option should be configurable. |
101 |
>> |
102 |
>> I'd call these situations errors - a warning should certainly be used. |
103 |
> |
104 |
> They are errors in Gentoo, but in some cases are normal in Debian, |
105 |
> because dependencies are asymmetric there. That's why switch to |
106 |
> omit them was requested. |
107 |
|
108 |
Then introduce an asymmetric dependency syntax. Then we can use that |
109 |
syntax, and there are no warnings because everything is cleanly |
110 |
specified. |
111 |
|
112 |
The solution to a flaw in the underlying design isn't to wallpaper over it. |
113 |
|
114 |
>> Seems like the solution to this is to let you configure the timeout |
115 |
>> per-service and globally, and maybe even give you the ability to |
116 |
>> override it at time of shutdown. During a routine shutdown you don't |
117 |
>> want the service manager randomly killing stuff. |
118 |
> |
119 |
> It is already configurable globally IIRC. What will be probably |
120 |
> more useful is to have separate start and stop timeout values and/or |
121 |
> maybe a way to set emergency shutdown timeout value. |
122 |
> |
123 |
|
124 |
No argument there. If you're short on time it is more important to |
125 |
cleanly unmount your filesystems than to let all those tor tunnels |
126 |
with 2 minute latency gracefully close down, but if you have the |
127 |
luxury of a clean shutdown you should be able to do that as well. |
128 |
|
129 |
-- |
130 |
Rich |