Re: [gentoo-dev] rfc: openrc service script dependency checker

[Andrew Savchenko]

On Thu, 4 Dec 2014 12:55:44 -0600 William Hubbs wrote:
> Several issues not related to the original have been brought up, which I
> will briefly respond to, but let's try to move back to the original
> issue I brought up, which is whether the early loop solver should break
> loops or just output messages about them.

Just make it configurable and let users to decide what they want.
People who want their loops to be broken will use it. Algorithm
itself looks quite reasonable and safe. If someone hesitates and
prefers handle such cases manually, loop breaker may be disabled.
 
> > > It seems to be a statement of fact that OpenRC ISN'T compatible with
> > > LSB dependencies.  What it "should" be is anything but a statement of
> > > fact, which is what the word "should" means...
> >
> > Yes, it is not compatible now. And if OpenRC wants to step out of
> > Gentoo scope to other distros, it should be. But as one can see,
> > Gentoo will also benefit from proposed fixes, which will made OpenRC
> > init system more robust and error-prone.
>
> We are talking about two issues; I did not mean for the lsb support to
> get into this thread. I was just wanting to discuss the early loop solver.

Issues are connected, that's why there were put into consideration
also. Anyway discussion seems to be quite productive :)
 
> > > I don't get why Gentoo gets by just fine with things as they are, but
> > > nobody else apparently can. Just fix your dependencies.
> >
> > I don't have broken dependencies on my systems right now. And this
> > is not a discussion of my personal issues at all. What I'm trying
> > to do is to make OpenRC robust and resilient to errors which may
> > occur as well as expand its scope outside of Gentoo as a mature
> > init system.
>
> Being error-resistant is a good thing, but the issue with breaking
> dependency loops without human intervention is we can't be sure we are
> breaking them in a sane way.

We can discuss early loop solver algorithm then.

1. It respects need > after > use priority and never breaks need
deps. "After" deps will be broken only if there is no "use" deps to
broke.

2. In case we have not a simple loop but branches, inner loops and
so on algorithm uses heuristics to break as little dependencies as
possible, keeping "after" upon "use".

On algorithm details you should talk directly to xai (dyokunev),
since he wrote them. But from my analysis they look safe, though
some details may be optimized in future.

> > > > Warnings for users about loops is a good idea for Gentoo, but will
> > > > produce a lot of not always wanted output on Debian, that's why
> > > > this option should be configurable.
>
> I'm not completely opposed to it being configurable. However, I am
> opposed to the configurability being implemented the way it is in the
> patch, because it breaks the public API for what I see as a minor gain,
> if it is a gain at all.

Then we should either look for a way to add it without API breaking
or update the public API, if current version doesn't allow required
features to be implemented.

> For more ways to control how services stop/start/deal with the timeout
> issue, you might want to look up the -stop and -timeout keywords in man
> openrc-run.

I'm aware of this option, but this is not exactly what I need. I'm
interested in some kind of trigger which can change global timeout
value to something like 1 second, so that a wrapper may be put into
SHUDOWNCMD of upsmon.conf or OpenRC should support some hook to
check for /etc/killpower and adjust timeout accordingly. Maybe I'm
asking too much...

Best regards,
Andrew Savchenko