1 |
Michał Górny posted on Wed, 20 Apr 2011 20:33:27 +0200 as excerpted: |
2 |
|
3 |
> On Wed, 20 Apr 2011 13:22:53 -0500 William Hubbs <williamh@g.o> |
4 |
> wrote: |
5 |
> |
6 |
>> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote: |
7 |
>> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: |
8 |
>> > > The author of the bug feels that the way to fix this is for us to |
9 |
>> > > put a check in openrc that makes it refuse to run services if it |
10 |
>> > > was not used in the boot process. |
11 |
>> > |
12 |
>> > This is good idea to have in any case since I remember my system went |
13 |
>> > crazy after I've tried to start some service inside chroot. |
14 |
>> |
15 |
>> My concern about it though is prefix installs. |
16 |
> |
17 |
> [The attached patch] is based on the assumption that in order to run |
18 |
> cleanly, OpenRC needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark |
19 |
> all services stopped). It assumes that the basic effect of a running |
20 |
> OpenRC is a determined runlevel stored in ${RC_SVCDIR}/softlevel file. |
21 |
> |
22 |
> I tested that approach with clean OpenRC and systemd installs, and it |
23 |
> doesn't create any issues. I'd appreciate if someone with Prefix system |
24 |
> could test it as well. |
25 |
|
26 |
> http://bugs.gentoo.org/show_bug.cgi?id=364159. |
27 |
|
28 |
The patch seems reasonable, but I can't but think that there's likely |
29 |
corner-cases that may be unknown ATM that could complicate things. If we |
30 |
establish a slightly broader base now, it can be reasonably expanded in |
31 |
the future. |
32 |
|
33 |
What about handling this much the same as subsystem-type auto-detection |
34 |
was ultimately handled, but controlling how much of openrc should run: |
35 |
|
36 |
1) Auto: (like rc_sys being commented out). This would do the auto-detect |
37 |
thing using something like the suggested softlevel file detection patch. |
38 |
|
39 |
2) On: Openrc is locked ON, and will try to handle everything. This |
40 |
could be the default (much like rc_sys=""). |
41 |
|
42 |
3) Off: Openrc is locked OFF, and will immediately terminate as soon as it |
43 |
loads the config far enough to see that it is OFF, if anything attempts to |
44 |
run it. |
45 |
|
46 |
4) Later? Nodep: (Target stable-next?) If the setting is "nodep", openrc |
47 |
should assume all deps are met and simply run the script it is asked to |
48 |
run, only. |
49 |
|
50 |
5) Optionally, service.allowed: (Target bluesky?) Another setting could |
51 |
list specific services that openrc should be allowed to run. If |
52 |
service.allowed isn't empty/unset, anything not listed would not be run. |
53 |
Nodep mode would be altered slightly by this, in that any listed service |
54 |
could be depended normally, while anything not listed would be assumed to |
55 |
be dependency-met. Normal (auto/on) mode would work in the reverse for |
56 |
anything not listed. Since openrc isn't allowed to touch those services |
57 |
but is operating in normal dependency mode, to openrc they'd not exist and |
58 |
therefore block the start of any depending services as well. |
59 |
|
60 |
6) Optionally, service.provided: To go along with #5, for openrc in normal |
61 |
mode, it could borrow the "package.provided" concept from portage, making |
62 |
it "service.provided". For normal mode, services listed in this third |
63 |
setting, but ONLY these services, would be assumed to be met much as if |
64 |
openrc was operating in nodeps mode. Services not in this list would be |
65 |
treated as above. (This would allow openrc to nodep on services in |
66 |
service.provided, while failing OTHER deps not found in service.allowed, |
67 |
if service.allowed isn't empty/unset. |
68 |
|
69 |
7) Optionally, service.blacklisted. This would be the negative version of |
70 |
#5. Presumably, if both service.allowed AND service.blacklisted are set |
71 |
and non-empty, one would take precedence and the other would be ignored |
72 |
(with documentation as to which was which). |
73 |
|
74 |
Obviously #5-7 are wish-list, not really appropriate for our current |
75 |
target-stable. However, *if* they were thought sufficiently useful to |
76 |
code up, these features could appear with a later version. |
77 |
|
78 |
At least #1-3 should be quite easy to code and appropriate for stable, |
79 |
since the config concept and implementation has already been tested to |
80 |
some degree with the current but quite new subsystem-type implementation. |
81 |
|
82 |
#4 falls in the middle. I threw it in based on jer's suggestion, which |
83 |
I'd like to see even if #5-7 aren't implemented, but it's a big enough |
84 |
feature-add that it really should have additional testing. As such I don't |
85 |
see it for current-stable-target, but perhaps stable-next? |
86 |
|
87 |
-- |
88 |
Duncan - List replies preferred. No HTML msgs. |
89 |
"Every nonfree program has a lord, a master -- |
90 |
and if you use the program, he is your master." Richard Stallman |