On system init schemes
I was delighted at finding Erich’s series of posts regarding init schemes - In fact, when reading the bottom of your third message I got disappointing at you stating that this concludes this series of blog posts. Maybe someone can follow up with some details on upstart (which seems to be the most promising init replacement)? - I expected you to delve a bit into other schemes, such as file-rc (which is, AFAIK, quite similar to the standard sysv-rc, but instead of having directories with symlinks has files describing each runlevel in similar terms, and I understand works in quite a similar logic to sysv-rc), runit seems to work in a way quite similar to BSD’s RC…
I was particularly interested on your point of view on something like Init NG - And, of course, Upstart sounds sexy, and besides, being Scott’s brainchild automatically stamps a must be good legend on it, at least for me. Shame that you didn’t follow on with the series - but hey, nobody’s paying you to do it ;-)
Anyway… I was thinking on a way we could get at least Debian maintainers work more easily towards having more than one init scheme for our daemons and such - or at least, shipping less cruft for derived distributions to clean up. Specifically, yes, our most notorious descendant goes Upstart, so /etc/init.d/* becomes crufty for them.
So, what if:
- All daemon-like packages (i.e. those containing a daemon, or running something at startup, i.e. setting up a service interface) will be affected. Lets call our sample daemon-bearing package example
- example will no longer ship an initscript. In fact, after some time, policy will mandate no initscripts (that is, what we today put in /etc/init.d) are included in our base packages. example will only recommend example-init. Why recommend it? Because it does not even now depend on a specific initscript - I've rolled some systems which are based on my very own init handler, for specific needs.
- The original example package maintainer will probably take his very same initscript, and package it as example-sysvinit. This script will provide the example-init virtual package. (Of course, this will mean a very real proliferation of virtual package names). example-sysvinit will depend on sysv-rc.
- The same maintainer, or a different one, will also package example-nginit, example-bsdinit, example-runitinit and/or example-upstartinit, depending on their respective infrastructures, and providing as well example-init. Ideally, they won't even have to conflict on each other.
- Maybe I'm daydreaming and this could just be a bit too much... But with all support in place, even the init system itself could be handled via /etc/alternatives ;-)
This means, yes, a serious explosion of very small packages. But it also means less dependency on a specific maintainer to be sympathetic to yet-another-init-scheme. If I’m pushing superb-init, which does preemptive reverse dependency tracking and invention and works based on the oh-so-3v1l aptsh, and I’m having a hard time convincing anybody to update their packages to support my init scheme before it matures, I can at least come up with all the needed scripts to get my system usable and considerable for the masses. Sounds decent? Did I smoke too much crack? No, I haven’t had my morning coffee yet, so I’ll go grab some while this hits the planet.
Comments
Efrain Valles 2007-04-13 04:21:42
Re: On system init schemes
Here is a video of Scott Talking Upstart in January at linux.conf.au 2007
http://lca2007.linux.org.au/talk/102
Gunnar 2007-04-17 11:35:36
Re: The link to Ubuntu
Oops! Fixed.
Helmut Grohne 2007-04-12 10:56:41
Re: On system init schemes
Actually I do think that having an example-fooinit package will pollute the package namespace and cause many files on the mirrors. Maybe we can just ship one package per initscheme containing all shell scripts. Having about 1000 available daemons (currently 817 in sid/amd64) and an overestimated amount of 4kb per script this would make a package of about 4MB (uncompressed and well compressable). Embedded systems can just remove the unneeded scripts.
Joachim Breitner 2007-04-13 04:17:20
Re: On system init schemes
I agree with Warren. It should be possible to somewhat abstract the init script thing, and create the needed files on the fly. Somehow. Maybe something for DebCamp?
Ming 2007-04-12 18:16:00
The link to Ubuntu
www.ubuntu.org is for an organization completely unrelated to Ubuntu Linux distribution.
I don’t know if it’s intentional (for sarcasm?), but think it’s worth pointing out.
Steve Kemp 2007-04-12 13:14:46
Re: On system init schemes
I can’t help thinking that this scheme will give a lot of namespace pollution and the creation of lots of little packages which will get out of sync.
I, personally, think that the solution is instead make init scripts simpler. There are five primitives we need to support (that I can think of right now!):
- Pre-start checks. (eg. is deamon installed?)
- Pre-start configuration testing (eg. sanity check config file)
- Start (start the service)
- Stop (stop the service)
- Status (running?)
- Dependencies (which deamons do we need first?)
I would like to see each package use something like “dh_installinit foo.init”. This file would contain details which could be used to actually generate the relavant startup script.
In the case of sysv.init it would create /etc/init.d/foo. For upstart it would create the appropriate symlinks, etc.
Each daemon would simply (?) read in /var/lib/dpkg/info/*.init and do the right thing. (tm).
There would be some effort involved in simplifying the init scripts, because I’m well aware that some packages are very complex - however I’m sure it could be done, and it does keep the information consistent - easy to adapt for future init systems, and within the package.
Warren Overholt 2007-04-12 14:45:49
Re: On system init schemes
We have the example of update-menus that may be a good example. As Steve Kemp posted, for the majority of init scripts, there are only a few types of action to take.
Rather than creating a huge number of packages, why not create a update-menus style structure that by generates the correct formated/organized structure. Realistically, a fair bit of abstraction should be provided by this new update-init package. We would want the average definition file to be very simple, while allowing complex scripts to be supported. This pushes the responsibility of making the new init process work back (initially) to the maintainer of the new init process (assuming a correct init config file). Friendly patches that do not change the default init behavior should be easier to get accepted than having to add/test 25 different init scripts to one package, or as you suggest having 25 different init-packages to maintain. Updating the 25 init-packages when the base package is updated could quickly turn into a nightmare.
I would envision several core variables, and a large number of optional (with pre-seeded defaults?) variables allowing unusual or init style specific behaviour. The stock sysv-rc scripts would/should ignore most of the optional values.