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 <birc...@gentoo.org> 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
signature.asc
Description: Digital signature
