[gentoo-dev] Re: rfc: openrc use flag

[Duncan <1i5t5.duncan@cox.net>]

Michał Górny posted on Wed, 20 Apr 2011 20:33:27 +0200 as excerpted:

> On Wed, 20 Apr 2011 13:22:53 -0500 William Hubbs <williamh@gentoo.org>
> wrote:
> 
>> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
>> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
>> > > The author of the bug feels that the way to fix this is for us to
>> > > put a check in openrc that makes it refuse to run services if it
>> > > was not used in the boot process.
>> > 
>> > This is good idea to have in any case since I remember my system went
>> > crazy after I've tried to start some service inside chroot.
>> 
>> My concern about it though is prefix installs.
> 
> [The attached patch] is based on the assumption that in order to run
> cleanly, OpenRC needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark
> all services stopped). It assumes that the basic effect of a running
> OpenRC is a determined runlevel stored in ${RC_SVCDIR}/softlevel file.
> 
> I tested that approach with clean OpenRC and systemd installs, and it
> doesn't create any issues. I'd appreciate if someone with Prefix system
> could test it as well.

> http://bugs.gentoo.org/show_bug.cgi?id=364159.

The patch seems reasonable, but I can't but think that there's likely 
corner-cases that may be unknown ATM that could complicate things.  If we 
establish a slightly broader base now, it can be reasonably expanded in 
the future.

What about handling this much the same as subsystem-type auto-detection 
was ultimately handled, but controlling how much of openrc should run:

1) Auto: (like rc_sys being commented out).  This would do the auto-detect 
thing using something like the suggested softlevel file detection patch.

2) On:  Openrc is locked ON, and will try to handle everything.  This 
could be the default (much like rc_sys="").

3) Off: Openrc is locked OFF, and will immediately terminate as soon as it 
loads the config far enough to see that it is OFF, if anything attempts to 
run it.

4) Later? Nodep:  (Target stable-next?)  If the setting is "nodep", openrc 
should assume all deps are met and simply run the script it is asked to 
run, only.

5) Optionally, service.allowed: (Target bluesky?)  Another setting could 
list specific services that openrc should be allowed to run.  If 
service.allowed isn't empty/unset, anything not listed would not be run.  
Nodep mode would be altered slightly by this, in that any listed service 
could be depended normally, while anything not listed would be assumed to 
be dependency-met.  Normal (auto/on) mode would work in the reverse for 
anything not listed.  Since openrc isn't allowed to touch those services 
but is operating in normal dependency mode, to openrc they'd not exist and 
therefore block the start of any depending services as well.

6) Optionally, service.provided: To go along with #5, for openrc in normal 
mode, it could borrow the "package.provided" concept from portage, making 
it "service.provided".  For normal mode, services listed in this third 
setting, but ONLY these services, would be assumed to be met much as if 
openrc was operating in nodeps mode.  Services not in this list would be 
treated as above.  (This would allow openrc to nodep on services in 
service.provided, while failing OTHER deps not found in service.allowed, 
if service.allowed isn't empty/unset.

7) Optionally, service.blacklisted.  This would be the negative version of 
#5.  Presumably, if both service.allowed AND service.blacklisted are set 
and non-empty, one would take precedence and the other would be ignored 
(with documentation as to which was which).

Obviously #5-7 are wish-list, not really appropriate for our current 
target-stable.  However, *if* they were thought sufficiently useful to 
code up, these features could appear with a later version.

At least #1-3 should be quite easy to code and appropriate for stable, 
since the config concept and implementation has already been tested to 
some degree with the current but quite new subsystem-type implementation.

#4 falls in the middle.  I threw it in based on jer's suggestion, which 
I'd like to see even if #5-7 aren't implemented, but it's a big enough 
feature-add that it really should have additional testing. As such I don't 
see it for current-stable-target, but perhaps stable-next?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman