Theodore Ts'o <ty...@mit.edu> writes: > On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
>> Well, I've said this before, but I think it's worth reiterating. >> Either upstart or systemd configurations are *radically better* than >> init scripts on basically every axis. They're more robust, more >> maintainable, easier for the local administrator to fix and revise, >> better on package upgrades, support new capabilities, etc. > Can you please go in to more detail why you believe this was true? I think it's painfully obvious if you compare an init script to an upstart or systemd configuration file for a simple daemon like, say, my lbcd package. For those who don't agree, please try the exercise of writing systemd and upstart configuration files for some typical daemon package and look at the number of lines of code in both and the behavior in edge cases (daemon already running, daemon running but with no PID file because something else deleted it, daemon part of a dependency chain that shouldn't fire until the daemon is actually listening to the network, correct exit status for various failure conditions, stopping the daemon when there is a user process with the same name as the daemon also running, and the other cases Policy says one must handle). Now compare the length of time it took you to make an init script correctly handle all those cases versus how long it took to write the upstart or systemd configuration. (Note that I have found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while working on Debian, so even if you start from that file, which is only applicable to a relatively narrow range of circumstances, you can still fail edge cases.) I have prior experience here both as Policy editor dealing with the Policy sections related to init scripts and as a Lintian maintainer dealing with Lintian checks for init scripts. Both of those experiences were, shall we say, convincing. Another way to look at this is that both upstart and systemd provide a high-level programming language for writing init scripts. Not only does it implement a higher level of abstraction, it's also better-suited to the problem space because it's declarative rather than imperative. (systemd somewhat more so than upstart, although that makes it somewhat more awkward to use in cases where you really need to run some shell script on various actions.) As with any move to a higher-level programming interface, there are drawbacks; if you really want to do your own memory management, you don't get to any more. And as with most moves to a higher-level programming interface well-suited to the task at hand, the advantages outweigh the drawbacks. (And in this case, I'd go a step farther and say that I think most of the drawbacks people cite around loss of flexibility are at least arguably benefits. The world would be a better place with fewer init scripts doing weird and unexpected things to paper over bugs better fixed somewhere else.) This really shouldn't be a particularly controversial stance. Ever since Solaris SMF, various UNIX implementations have been abandoning traditional init scripts for exactly these reasons. I really don't think that all those completely independent technical teams, which at this point include most major Linux distributions (counting OpenRC as another higher-level implementation), are all wrong. This is an area of personal interest of mine. I followed daemontools development back when Dan Bernstein was tackling this same basic problem in his distinctively radical way, and have subsequently been paying at least casual attention to various different daemon management facilities ever since. A lot of people have tried to solve various aspects of the problem that init scripts are actually horrible at what they do, and the solutions have been slowly improving and becoming more and more robust. AFS attempted to solve this problem all the way back in the 1980s. Even back then, it was obvious that init scripts were insufficiently powerful to manage production services properly, hence the whole bosserver system that persists in OpenAFS to this day and which, coming from MIT, you may be familiar with. Not that I would advocate use of bosserver for anything other than AFS these days, as there are now lots of newer technologies that have surpassed it, although (relatively) secure network management of services is still an interesting feature. > The lsat time I played with Upstart, I saw a lot of policy moved from > shell scripts into C code (which I would have to edit and recompile) if > I wanted to change things. I also was extremely frustrated with a > massive lack of documentation, where at least with shell scripts I could > read the scripts to understand what was going on. I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. Note that *Debian*, as a distribution, has a significant interest in standardizing policy around how daemons are managed. It's therefore not a bad thing for the distribution if we have an init system that handles that policy, provided that it encodes the policy that we want. I realize that the local administrator may have other goals, and they should have ways of achieving them, but both systemd and upstart support running SysV init scripts for those cases. -- 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/87li1aqlui....@windlord.stanford.edu
