Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 293139 - sys-apps/openrc: start one implicit provider, and allow weighting of providers
Summary: sys-apps/openrc: start one implicit provider, and allow weighting of providers
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on: 291894
Blocks:
  Show dependency tree
 
Reported: 2009-11-14 02:55 UTC by SpanKY
Modified: 2012-08-24 21:37 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
0001-Require-providers-to-be-in-runlevels.patch (0001-Require-providers-to-be-in-runlevels.patch,1005 bytes, patch)
2012-02-26 22:53 UTC, William Hubbs
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2009-11-14 02:55:16 UTC
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...)
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-11-14 06:56:01 UTC
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
Comment 2 Roy Marples 2009-11-14 07:59:16 UTC
(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?
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-11-14 08:11:14 UTC
(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.

Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-11-14 08:50:48 UTC
err, that commit is about kbd?
Comment 6 Roy Marples 2009-11-14 08:59:34 UTC
Meh, wrong link. Try this one :)

http://roy.marples.name/projects/openrc/changeset/509e34d425d28998ca8f6f230cadc05bc89d2731
Comment 7 William Hubbs gentoo-dev 2009-11-17 21:00:05 UTC
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?

Comment 8 Roy Marples 2009-11-18 22:41:11 UTC
Correct
Comment 9 William Hubbs gentoo-dev 2009-11-18 23:22:32 UTC
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?

Comment 10 SpanKY gentoo-dev 2009-11-18 23:58:43 UTC
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}=... ?
Comment 11 William Hubbs gentoo-dev 2009-11-19 00:20:01 UTC
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?

Comment 12 SpanKY gentoo-dev 2009-11-19 00:26:31 UTC
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=...
Comment 13 William Hubbs gentoo-dev 2009-11-19 01:05:50 UTC
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?



Comment 14 SpanKY gentoo-dev 2009-11-19 02:30:52 UTC
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.
Comment 15 William Hubbs gentoo-dev 2009-11-19 03:08:59 UTC
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.
Comment 16 SpanKY gentoo-dev 2009-11-19 04:01:55 UTC
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.
Comment 17 William Hubbs gentoo-dev 2009-11-20 20:14:33 UTC
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"

Comment 18 SpanKY gentoo-dev 2009-11-21 00:43:00 UTC
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.
Comment 19 William Hubbs gentoo-dev 2012-02-26 22:35:23 UTC
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.
Comment 20 William Hubbs gentoo-dev 2012-02-26 22:53:03 UTC
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 21 William Hubbs gentoo-dev 2012-02-27 22:59:27 UTC
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.