1 |
On Thu, Dec 4, 2014 at 7:54 AM, Andrew Savchenko <bircoph@g.o> wrote: |
2 |
> |
3 |
> 1. There are multiple services having "after $all" statement (an |
4 |
> analog in Gentoo is "after *", which is currently used only by |
5 |
> local init.d script). |
6 |
> |
7 |
|
8 |
Seems to me that the solution to this is to ban this sort of syntax |
9 |
entirely, and use proper deps. WHY do we have to run local.d last? |
10 |
Why do we have to run any of that other stuff last? |
11 |
|
12 |
> 2. LSB dependencies are allowed to be asymmetrical relative to start |
13 |
> and stop, while in OpenRC they are symmetrical. This yields to |
14 |
> loops in OpenRC while in LSB the same services work fine. Example |
15 |
> follows: |
16 |
|
17 |
Seems like the solution to this is to allow a different syntax for |
18 |
start vs stop dependencies then, with the default being to keep them |
19 |
the same if the current syntax is used. |
20 |
|
21 |
> So it is a statement of fact that OpenRC |
22 |
> should be compatible with LSB dependencies. |
23 |
|
24 |
It seems to be a statement of fact that OpenRC ISN'T compatible with |
25 |
LSB dependencies. What it "should" be is anything but a statement of |
26 |
fact, which is what the word "should" means... |
27 |
|
28 |
It should be a nice warm day today is not a statement of fact, as much |
29 |
as I'd like it to be. |
30 |
|
31 |
I don't get why Gentoo gets by just fine with things as they are, but |
32 |
nobody else apparently can. Just fix your dependencies. I also don't |
33 |
get why being as compatible as possible with LSB means that it is OK |
34 |
to specify non-nonsensical dependencies like A and B must both be last |
35 |
at the same time. |
36 |
|
37 |
> |
38 |
> Warnings for users about loops is a good idea for Gentoo, but will |
39 |
> produce a lot of not always wanted output on Debian, that's why |
40 |
> this option should be configurable. |
41 |
|
42 |
I'd call these situations errors - a warning should certainly be used. |
43 |
|
44 |
> As for Gentoo it is desirable too, becase it is better to boot |
45 |
> system somehow instead of not booting it at all (or with long |
46 |
> delays due to 60-seconds timeout on service startup). This is |
47 |
> crucial for remote servers, e.g. admin needs to reboot machine due |
48 |
> to critical security kernel update ASAP and having it hang during |
49 |
> boot is really a very bad idea. |
50 |
|
51 |
So, I'm fine with some kind of emergency mode, though expecting it to |
52 |
work on a remote server might be asking a bit much. Dropping to shell |
53 |
is certainly preferable to just hanging. You certainly couldn't |
54 |
guarantee a successful boot, since the configuration contains errors. |
55 |
|
56 |
> Another example from my experience |
57 |
> is emergency shutdown due to power failure and low battery signal |
58 |
> from sys-power/nut. I had several nasty cases when system failed to |
59 |
> shutdown properly due to 60-second timeouts for services failed to |
60 |
> shutdown — battery just ran out of charge while OpenRC was try to |
61 |
> do thing "right way". |
62 |
|
63 |
Seems like the solution to this is to let you configure the timeout |
64 |
per-service and globally, and maybe even give you the ability to |
65 |
override it at time of shutdown. During a routine shutdown you don't |
66 |
want the service manager randomly killing stuff. |
67 |
|
68 |
-- |
69 |
Rich |