Init followup
First of all, sorry for the delay. Leaving just as the discussion gets started is bad, yes… But I’m only now reading Erich’s and Sven’s follow-ups. Both (as well as some comments in my blog) ask why not integrating the startup links in each of the packages - Well, basically because I don’t think that most maintainers will take care to do this, and we will end up having a situation very close to what we have today: If I’m not interested in supporting your favorite init system in my packages, I just won’t bother to make the scripts.
Note: I’m going into braindump mode. Verbose blabber and some stupidity might follow ;-)
Think on the webapp scene - Most webapps ship with an Apache-like snippet so that http://yourserver/thisapp just works(tm). I love that, and it’s one of the little details that make Debian shine - Things usually work with the least administrator burden possible. But it happens that there are other web servers around there - They just become somehow second class citizens (I happen to sponsor/comaintain Cherokee, for instance), as nobody cares to include the equivalent snippets for them. Apache is the standard, and is good enough.
The same goes for sysv-rc: It just rules the world. Who will work all the needed patches to support all the different init systems? As the maintainer for a simple package which requires to be started up, I probably won’t care to even understand all the intimacies of every init system, at least until they all have a decent user base. But by having one package per (server,init-scheme) pair, any maintainer can come up with the needed initialization.
Of course, this degrades quickly. First of all, as a user: if mydaemon is not correctly starting up, I will probably file bugs at mydaemon, not at mydaemon-initscheme. If mydaemon changes its parameters, we will witness transition of mydaemon-*.
Further, remember this is Debian, and volunteer-work has its downsides. If the mydaemon maintainer is a primadonna (or just does not give a flying crap about the runit init scheme), he will just trash reports regarding a nonimportant init scheme. Bad. And, as Erich points out, we have ~1000 packages including /etc/init.d/something - It will mean 3000 or so packages for a decent (not complete!) coverage of the different schemes. And, of course, a very uncoordinated way of working.
But back to my line of thought: If I’m promoting an init scheme, I cannot just push it down each maintainer’s throat. I must include at least the most important init scripts somewhere. Maybe we could just group daemons by task, and then have -say- a webservers-runit package providing the init scripts for each webserver for runit? This could cut down from 3000 to some 100 packages, most probably team-maintained… But it still faces many scalability problems, and the bug-filled-somewhere-else problem seems unavoidable.
I think something interesting could come off Sven’s idea of providing several independent scripts instead of today’s complete init scripts - This would make it easier to adapt startup/shutdown and similar events to different world views, and if not specifically needed, most init scripts could even be autogenerated calling the right bits here and there. That would rock - except in the corner cases (I predict no less than 10% of the packages will become corner cases ;-) ) where it will crumble apart. But maybe if a package declares it should be autostarted and provides the separate bits, the sysv-rc, upstart or runit helper can come up with an autobuilt initscript (or equivalent) - And if it does not work, it can always be overriden by a maintainer- (or user-) supplied, explicitly built script. Humh…
The topic surely calls for a Debcamp session, as Joachim says in comments in two of our posts and Erich acknowledges. Erich, as the main instigator of this blog series, I hope you can at least join via Ekiga or such, as it can be quite interesting - But, yes, none of the people involved so far participates in any of the inits’ maintenance… Anyway, please keep the ideas flowing. I want to sketch something up, as I feel this can be useful - and not only for initscripts, but for many of the areas where Debian provides several ways to do the same thing. And, once again, that’s one of the best points of Debian for me.
Comments
Adam 2007-04-17 12:55:20
Re: Init followup
You could try to write a completely declarative init system. Has things like “Depends”, “Provides” a la debian packages. Also have things like “Keep-Running” that tell init if it is supposed to monitor the process and restart it if it dies, in fact - most of the stuff that upstart is defining.
From this, you should be able to write a program (call it “inittool”, similar to libtool) that will output LSB/sysv init-scripts from the definition automatically. It ought to be able to syntax-check the definition as well.
If “inittool” gets written and touted as a way to automate init-script generation, as part of a program’s normal “make” process for daemons (or one-shot programs that just run on startup), it might help with some of the awfulness that goes into some init scripts. Init scripts are a bit of a black art, and everyone I’ve ever talked to just copies existing ones and hacks around a bit until it seems to work. Simplify it, and people might well use it.
Once this is in place, “inittool” should be able to be modified such that it generates not just LSB/sysv init scripts, but upstart files, file-rc files, etc…
The clever part is that we ship the original “inittool” definition file in the debian package, and then run “inittool” as a post-install step, with the output set to whatever init system the user has installed.
Might that work?
Adam 2007-04-17 12:59:18
Re: Init followup
Oh, er, hang on. You do go on to mention that. Sorry, as your post is half-obscured by the fact it’s in a frame with a scrollbar on that’s independent of the page, I didn’t notice the second half of it ‘til after I posted my comment.
Ignore me…
Jamie 2007-05-26 15:06:03
Re: Re: Init followup
Have you ever looked at upstart? It’s about as declarative as these things can get:
description “mydaemon” author “Jamie “ start on runlevel-2 stop on shutdown exec /usr/bin/mydaemon respawn
That’s it for most of the Yet Another Daemon software around. You can even add event handlers for things like reload and pause.
And frankly, sysv init is nothing more than a collection of shell scripts, symlinks, and a daemon to run them.
(Disclaimer: Ubuntu fanboy)
Joachim Breitner 2007-04-17 12:26:23
Re: Init followup
If anyone thinks that generating the init scripts will not work, then just tell them that the idea to create debian/rules by just one line (cdbs).
And you are right, probably more than 80% of daemons can have good init scripts providing just this information:
- binary to run in foreground And the rest is handled start-stop-daemon for sys-v-init or the alternative init system.
Complicated cases (which will be few) can just ship the various init scripts, just like some package don't even use debhelper in debian/rules.
(Disclamer: This was a quick post that I didn't even read twice)
Joachim Breitner 2007-04-17 13:28:04
Re: Init followup
Ok, we have plenty of people having thought of the same thing. Let's do it during DebCamp! :-)