| Summary: | sys-apps/openrc: start one implicit provider, and allow weighting of providers | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | SpanKY <vapier> |
| Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | robbat2, tetromino |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 291894 | ||
| Bug Blocks: | |||
| Attachments: | 0001-Require-providers-to-be-in-runlevels.patch | ||
Not sure about that syntax for provide. Don't we already allow multiple entries in the provide line output? So that would mean doing something like: provide clock:50 (In reply to comment #0) > if you have scripts that have multiple providers (like hwclock or swclock), > only one should be started implicitly. Now that the upstream default is one network script that favours entire IPv4 config via dhcpcd we can do this. (In reply to comment #1) > Not sure about that syntax for provide. Don't we already allow multiple entries > in the provide line output? So that would mean doing something like: > provide clock:50 Yes, we would have to do something like that. Another option would be swclock:depend() { provide clock; provide_after hwclock; } Thoughts? (In reply to comment #2) > (In reply to comment #1) > > Not sure about that syntax for provide. Don't we already allow multiple entries > > in the provide line output? So that would mean doing something like: > > provide clock:50 > > Yes, we would have to do something like that. > > Another option would be > swclock:depend() { provide clock; provide_after hwclock; } > > Thoughts? The latter implies that we might also have provide_before, along with the danger of circular references or invalid deps (which do happen already). No preference between them, but the explicit numeric version would allow a single array for compuation, while the _(before|after) needs graph theory. err, that commit is about kbd? Meh, wrong link. Try this one :) http://roy.marples.name/projects/openrc/changeset/509e34d425d28998ca8f6f230cadc05bc89d2731 All, what is the status of this bug? I am running openrc from git, and I believe what the last change did was to make it so that only one provider runs if none are in the runlevels. Is this correct? Correct All, I tested this and confirmed with Roy that with his change, if there are multiple providers and none are in the runlevels, the first one in lexical order is the one which will be run. Here is another question about assigning weights to the providers, if we still want to do that. I'm thinking this might be something we should come up with a syntax for in the conf.d files instead of in the scripts, something like this where the provided service is part of the variable name. In /etc/conf.d/hwclock: rc_clock_weight=20 and in /etc/conf.d/swclock: rc_clock_weight=10 What are your thoughts? that would probably be a smoother path as it wouldnt introduce backwards incompatible changes, and the weights could be overridden like any normal rc value in a site-specific config.
the naming seems like it could be a little cluttering though. perhaps rc_provide_weight_${provide}=... ?
I like the idea, but can we switch it to
rc_provide_${provide}_weight=...
I think it is more clear what is being set that way.
What do you think?
that makes even more sense as it allows for grouping of other settings down the line
rc_provide_${provide}_weight=...
rc_provide_${provide}_mom=...
rc_provide_${provide}_dad=...
rc_provide_${provide}_fattyfatfat=...
I'm thinking we also need to define a couple of things before weights can work. What should the default weight be if none is assigned? I'm thinking the lowest (0). What should the highest possible weight be? What should happen if more than one service has been assigned the same weight? Is this an error, or should we then fall back to lexical order for that weight? How do we want to use this facility -- do we want to set weights, or do we want these to be determined by end users? Also, I can see the possibility of someone attempting to remove all providers of a service from their runlevels and attempting to allow weights to control which one gets started instead. I think this could lead to madness for troubleshooting systems. What are your thoughts on these? if the weight is unspecified, we can pick something arbitrary like 50. so people can easily set preference as higher or lower than default. i dont see any point at adding artificial numerical limits. if it's a number, compare it. sticking to unsigned integers makes parsing simple (and stays with the normal behavior as seen in env.d/etc...). using lexical order for same weights keeps things simple and expected -- and the current code doesnt need changing. letting maintainers set default weights in their conf.d files is fine. we should do it for swclock (set it to like 70) so hwclock is always preferred. hwclock is before swclock in lexical order, so it will always be preferred unless you add swclock to a runlevel or set the weight of swclock higher than the default, so I don't think we need swclock to have a weight other than the default. i know it is, but i thought it'd be nice to be explicit. doesnt matter that much to me though as the end result is the same. Mike, what do you think about Roy's suggestion in comment #2, using provide_before/after in the scripts instead of weights? if we did that we could also allow setting this to be handled the same way other settings for each service are handled in /etc/rc.conf: rc_provide_before="something" rc_provide_after="something_else" or, for service foo, rc_foo_provide_before="something" rc_foo_provide_after="something_else" that introduces a fragile network of scripts that are provided before some, but not others, and would require people to specify a lot more changes than simply lowering the weight of the one init.d script they actually want. Would anyone be opposed to requiring that providers be in a runlevel? In my opinion, if we do not allow implicit providers but require a user to add providers to runlevels, things are much cleaner than the original proposal on this bug -- adding a weighting system to implicit providers. I'll attach a patch shortly that seems to work here and do this. Created attachment 303423 [details, diff]
0001-Require-providers-to-be-in-runlevels.patch
This patch makes it a requirement that a provider be in a runlevel.
Comment on attachment 303423 [details, diff]
0001-Require-providers-to-be-in-runlevels.patch
This patch doesn't quite work; it allows services that need virtuals to start even though a provider may not be started.
We discussed this on #openrc and William wants to take a look at it again. |
if you have scripts that have multiple providers (like hwclock or swclock), only one should be started implicitly. further, we should have a way of preferring one over the other. i guess by default it would be an alphabetical issue, but if extended the "provide" syntax, we should be able to do this easily. hwclock:depend() { provide clock 50; } swclock:depend() { provide clock 100; } lower means higher preference to match all our existing weight systems (files are alphabetically ordered -- env.d, udev/rules.d, etc...)