Henrique de Moraes Holschuh <h...@debian.org> writes: > How much of that improvement would be realised if we added a dependable, > declarative (i.e. config-based instead of shell-script-based) service > configuration support to sysvinit ?
Some, mostly on the maintenance side. I think the major short-term win is eliminating the massive amounts of buggy shell boilerplate that make up a typical init script, most of which are only trying to do something fairly simple and easily describable in a declarative syntax. However, that doesn't help with early boot ordering (for which you need deep integration with kernel events), with boot speed and parallelization (we made a lot of improvements with the dash switch and with our current parallelization, but we can better), with tracking daemon processes and getting rid of the fragile and annoying PID file dances or process table searches, or, probably most significant in the long run, socket activation. It mostly just helps Debian maintainers write better init scripts, but it doesn't reposition us to take advantage of innovation in daemon management and control. That innovation is a big deal. The way we're handling daemons right now is awful, and I think a lot of people don't realize it just because they've never had experience with something better. For example, here at Stanford, we've been using daemontools since shortly after djb originally wrote it to manage many of the cases that init scripts do an awful job at, and that experience has taught me just how bad of a job init scripts do for a lot of common use cases. My coworkers spin up new daemontools /service scripts all the time, and grumble mightily when they have to write an init script instead because a /service script won't work for some reason. It makes a huge difference. But daemontools has a bunch of its own problems (as does runit) and are not general replacements. systemd and upstart both do everything useful that those tools do and much more. This is something that's also been independently understood by other UNIX vendors. For example, one of the major overhauls in Solaris 10 was building in this sort of management framework for daemons, and (like a lot of Solaris innovations) the idea was quite solid, even if the implementation (XML, ew) was dubious. And of course Mac OS X has had launchd for quite some time, which isn't quite as comprehensive of a solution, but tackles some of the same problems. Basically, Debian is seriously behind the curve on this, but we're so used to our familiar, comfortable problems that we don't necessarily see the amount of pain that we're enduring that we don't have to endure. As Charles noted elsewhere on this thread, once you start looking at and maintaining either systemd or upstart configurations instead of init scripts, you realize what sort of rock you were beating your head against and how nice it feels for the pain to stop. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwpnlh6z....@windlord.stanford.edu