Hello, On Thu, 4 Dec 2014 12:28:59 -0500 Rich Freeman wrote: > 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?
That's a complicated issue. As far as I understand current situation, majority of Debian devs are happy with systemd and absolutely don't care about any other possible alternative. But there are a few people who do care. Under these conditions it is highly unlikely that anything in Debian dependencies approach will change for the sake of OpenRC if it works fine for them with their LBS and systemd right now irregardless of is it right or wrong way for things to be done. If we can tune OpenRC for their demands without damaging default OpenRC setup, why not? > 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. This will require every sysadmin to know well how openrc works and how to specify appropriate dependencies for custom out-of-tree daemons. While I support the idea that sysadmins should be well prepared to tweak internals of systems they are working with — and to know this internals well in order to do such tweaks —, in real life people often don't have time to dig such deep into the system and will prefer other solutions which keeping stuff simple. local.d where people can just put their scripts without handling any deps is a simple way. That's why we need it. (Of course if someone dislikes this approach, it not hard to disable local.d at all.) And if local.d needs dependencies to be specified how does it differs from just writing plain new service and putting it into init.d? Frankly, I do such things when I need custom complicated services for my needs. > >> 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. What I basically propose is to turn soft loops from errors to warnings. Behaviour will be still deterministic (because early loop solver uses deterministic and not random approach to broke loops), but more sophisticated and slightly less transparent of course. > >> 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. They may randomly broke during update and I will not know they are broken until reboot, where system will hang. > 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. I already tried this resolver on such box and I'm satisfied with result :) Though I can't recommend this kind of experiment for a unprepared user. Best regards, Andrew Savchenko
pgpJcdq2MgwnO.pgp
Description: PGP signature
