On Thu, Dec 4, 2014 at 11:12 AM, Andrew Savchenko <birc...@gentoo.org> wrote: > 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. > > 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. >
But Debian CAN change that. Why don't they? Do they want to use OpenRC or not? > >> 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 didn't ask why we need local.d. I asked why we need to run it LAST, and why we need to run all of that other stuff LAST? Of course, the reality is that we aren't running all of that stuff last since exactly one script can REALLY be run last. If your answer is that something in local.d might need to use the network, then specify that it needs the network. If the answer is that it needs to use nfs, then specify that it needs to use nfs. If it needs to happen after a bunch of random things but you can't be sure which things they are, then just create a virtual service and make it need that. The solution is the same for both local.d and all that "other stuff" that "needs to be last." Just specify what they actually need. This is a dependency-based service manager. What would happen if we started creating ebuilds that had some kind of optional dependency on "*/* because we wanted to make sure they're always the last thing to be installed since we're too lazy to specify what the actual dependencies are? Presumably Debian has figured this out for their package manager, since they were one of the first to have a decent dependency-based package manager in the first place. >> >> 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. I think you meant to say something different. :) This honestly seems like the general trend of ignoring compiler warnings. I'm not suggesting that the solution is -Werror. However, what you propose basically makes the service startup process less deterministic, and everytime I read one of those threads on service managers it seems like everybody is railing about how that is a bad thing. > >> 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. There is a difference between tolerating a random error, and building a system that tries to do the right thing (defined as something other than "error, fix your mess") when you throw a heap of garbage at it. On the one hand you talk about error resilience, and on the other you talk about this just being the way Debian does things and there isn't any error in the first place. Just fix the dependencies. And a box with remote access only with no other provision for console access is the last place you should be trying to run stuff like this. > >> > 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'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. Then introduce an asymmetric dependency syntax. Then we can use that syntax, and there are no warnings because everything is cleanly specified. The solution to a flaw in the underlying design isn't to wallpaper over it. >> Seems like the solution to this is to let you configure the timeout >> per-service and globally, and maybe even give you the ability to >> override it at time of shutdown. During a routine shutdown you don't >> want the service manager randomly killing stuff. > > It is already configurable globally IIRC. What will be probably > more useful is to have separate start and stop timeout values and/or > maybe a way to set emergency shutdown timeout value. > No argument there. If you're short on time it is more important to cleanly unmount your filesystems than to let all those tor tunnels with 2 minute latency gracefully close down, but if you have the luxury of a clean shutdown you should be able to do that as well. -- Rich
