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

[William Hubbs]

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.

On Thu, Dec 04, 2014 at 07:12:58PM +0300, Andrew Savchenko wrote:
> Hello,
>
> On Thu, 4 Dec 2014 08:59:22 -0500 Rich Freeman wrote:
> > On Thu, Dec 4, 2014 at 7:54 AM, Andrew Savchenko <bircoph@g.o> wrote:
> > >
> > > 1. There are multiple services having "after $all" statement (an
> > > analog in Gentoo is "after *", which is currently used only by
> > > local init.d script).
> > >
> >
> > Seems to me that the solution to this is to ban this sort of syntax
> > entirely, and use proper deps.

I agree with this. As soon as more than one service tries to use
"before/after *", things are broken, because more than one service can't
possibly meet those dependencies.

>
> There is no serious problem in Gentoo here, because local is _the
> only_ service that uses this kind of dependency. But in Debian
> "after $all" syntax is in common use and we can't change that.

I am chatting with qnikst on irc as I write this, and he says this might
be able to be solved by stacked runlevels. I haven't looked at this
myself yet so can't verify.

> The prime cause of these patches was to bring OpenRC as usable init
> system for other distributions and not to limit its scope only to
> Gentoo. And Debian has requirement of additional features in order
> to allow OpenRC to be used as a reliable replacement of other init
> systems.

A dependency checker is something we have needed for some time,
regardless of the distro; you are talking about bug 391945 [1].

The lsb support is a temporary measure until
Debian can move away from lsb init scripts, which is their plan, so I
don't think we need to worry about it upstream.

> > WHY do we have to run local.d last?
> > Why do we have to run any of that other stuff last?
>
> I doubt this is in POSIX standard or whatever, but it is a quite
> common custom among distributions to have some rc.local service
> where admins may put their custom daemons to be started in quick and
> dirty way, so that admins without prior knowledge of how particular
> init system works may put their stuff to that rc.local script/
> service/whatever. This is mostly needed when out-of-tree packages
> are used or in-tree packages lack init script. The former is quite
> common in production, unfortunately.
 
 I am not planning on changing this; I want to keep local running last.

> > > 2. LSB dependencies are allowed to be asymmetrical relative to start
> > > and stop, while in OpenRC they are symmetrical. This yields to
> > > loops in OpenRC while in LSB the same services work fine. Example
> > > follows:
> >
> > Seems like the solution to this is to allow a different syntax for
> > start vs stop dependencies then, with the default being to keep them
> > the same if the current syntax is used.
>
> Yes, this particular case can be solved with optionally separated
> start and stop dependencies.

This is a separate thread; I would like to know more about this before I
attempt to implement it, including what the use cases are for it. Let's
table this one for now.

> What proposed solutions do?
>
> 1a. For the first issue early loop solver allows to start all
> services from a *soft* loop gracefully, so that all services should
> work, because all mandatory "need" dependencies will be satisfied.
>
> 1b. If loop is *hard*, then later loop solver will intelligently
> break loop at some point, so that as much services as possible will
> have their "need" dependencies satisfied. Of course, some services
> may fail in this case, but this is still better than fail _all_ of
> them.
>
> 2. No time will be lost in case of *soft* loop and time loss will
> be minimized in case of *hard* loop.

Later loop solver is not even under consideration. The author made it
very clear that it shouldn't be; read his comments about it not being a
good solution in the pull request [2]. In fact, I think he meant to
close it (see comment 2) so I am going to do that today.

>
> > > So it is a statement of fact that OpenRC
> > > should be compatible with LSB dependencies.
> >
> > 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.

> > 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.

> > > 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.

This output is complaining about a pretty important issue, so in my
mind, if I compare the configurability to the loop solver, the
configurability is a far lower priority.

> >
> > I'd call these situations errors - a warning should certainly be used.
>
> They are errors in Gentoo, but in some cases are normal in Debian,
> because dependencies are asymmetric there. That's why switch to
> omit them was requested.

I, too, see these as errors. Also, like I said above, a discussion about
asymmetric dependencies is a good thing, but let's put that on a
separate thread later.

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.

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=391945
[2] https://github.com/openrc/openrc/pull/13