On 06/08/2015 11:45, tilt! wrote:
Thing is, init scripts tend to have problems managing services that do not offer sufficient commandline interfaces as described above
There's a simple reason for that: "init scripts" aren't "managing services". They can more or less start and stop them, that's about it - and they're not even doing the starting and the stopping right. - Starting ? Sure, it's easy to start a service: run the stuff, and if it's a daemon, just fork it. Right ? Wrong. When you just spawn the stuff from your shell, it runs with your shell's environment (open fds, variables, terminals, so many parameters that are *difficult* to clean up and really harden). But when you spawn the stuff at boot time, it runs with the very different environment provided by init. I can't count how many problem reports I've read in support mailing-lists that were really hard to track down, but in the end it was just a config issue because the daemon launching script did not properly sanitize all its environment, so it didn't give the same results when run by the admin or when auto-run at boot time. - Stopping ? Sure, just find a daemon's pid... oh wait, we need to have it stored somewhere. Hence, .pid files. If you don't know why .pid files are evil, look it up. And then you have the other functionality. Restarting, sometimes, can be lighter than stop + start: maybe there's a whole lot of config you don't have to do when you're just restarting a daemon - for instance, if "restart" means "read your config file again", some daemons support the convention that receiving a SIGHUP should make them do just that. So "restart" should simply send a SIGHUP to those, but do stop + start on the others. That's confusing. There's the "reload" keyword sometimes, but are there any precise semantics ? And "status". This is very service-dependent: since there is no global API, no service manager, scripts will query the daemon's status in a daemon-specific way. More vagueness again, because "status" doesn't define exactly what you should say, and the lowest common denominator is "is it alive?" but even for this basic check, daemon-specific interfaces are used. Init scripts just don't cut it, no matter where they come from, no matter how simple they are or how complex they are. OpenRC is a step in the right direction, because it provides real support for more things than sysv-rc, but even it doesn't address all the issues of init scripts. What is needed is a *service manager*, a real, full-fledged thing that doesn't only start and stop services, but does it properly, without hacks, with the same environment every time, and can tell you whether a service is alive or not, ready or not, and gives you a unified interface to interact with it in a simple way. (You still have to use daemon-specific interfaces for the more complex ways, because no service manager can unify that.)
what does SystemD do to address this problem?
It does exactly that. Among the myriad of useless things that systemd does, it does at least one useful thing: it's a proper *service manager*. I'm not saying it's correctly designed - it's not: see for instance http://ewontfix.com/15/ - but it's definitely one of the real, serious advantages that systemd has over its current alternatives, and it is important to acknowledge it. Winning against systemd involves providing better designed alternatives to the useful parts of what it does, and service management is one of those: there is a qualitative jump to do here, and messing around with init scripts is only a quantitative jump and unfortunately isn't going to accomplish anything if not paired with a serious redesign of how booting a machine should be done. That's why I'm currently writing a service manager, and will keep you guys informed when it's out. -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng