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. WHY do we have to run local.d last? Why do we have to run any of that other stuff 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. > 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... It should be a nice warm day today is not a statement of fact, as much as I'd like it to be. 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 also don't get why being as compatible as possible with LSB means that it is OK to specify non-nonsensical dependencies like A and B must both be last at the same time. > > 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. > As for Gentoo it is desirable too, becase it is better to boot > system somehow instead of not booting it at all (or with long > delays due to 60-seconds timeout on service startup). This is > crucial for remote servers, e.g. admin needs to reboot machine due > to critical security kernel update ASAP and having it hang during > boot is really a very bad idea. So, I'm fine with some kind of emergency mode, though expecting it to work on a remote server might be asking a bit much. Dropping to shell is certainly preferable to just hanging. You certainly couldn't guarantee a successful boot, since the configuration contains errors. > Another example from my experience > is emergency shutdown due to power failure and low battery signal > from sys-power/nut. I had several nasty cases when system failed to > shutdown properly due to 60-second timeouts for services failed to > shutdown — battery just ran out of charge while OpenRC was try to > do thing "right way". 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. -- Rich
