Apparently, a new project (to replace init, inetd, and cron) named systemd is nearing release and will be used to replace upstart in Fedora 14 (to be released in November – with Alpha Release due today!).
There is a healthy crop of init replacements out there, and the field is still shaking out. Replacing init – or specifically, System V init and init scripts – seems to be one of those never-ending projects: everyone has an idea on how to do it, no one can agree on how.
Let’s recap the current crop (excluding BSD rc scripts and System V init):
- Upstart
- Apple’s launchd
- Solaris’s System Management Facility (SMF)
- runit
- Richard Gooch’s simpleinit (and introduced in a paper at the 2002 Ottawa Linux Symposium)
- initng
- daemontools
- NetBSD and rc.d
- Make
I am still waiting for the shakeout – it bugs me that there are dozens of different ways to start a system, and that none of them have taken over as the leader. For years, BSD rc scripts and System V init have been the standard – and both have stood the test of time.
My personal bias is towards SMF (OReilly had a nice article on it) and towards simpleinit – but neither has expanded like upstart has.
So where’s the replacement? Which is The One? It appears that no one is willing to work within a promising project, but rather starts over and creates yet another replacement for init, fragmenting the market further.
Lastly, if the current init scheme is so bad, why hasn’t anything taken over? Commercial UNIX environments continue to use the System V scheme, with the sole exception of Solaris which made the break to System Management Facility (or SMF). Why doesn’t HP-UX or AIX use SMF or Upstart if the current environment is horrible?
Sigh. It’s not that the current choices of replacement are bad – it’s just that there are so many – and more keep coming up every day. Perhaps we can learn something about the causes of this fragmentation from a quote from a paper written about the NetBSD rc.d startup scripts and their design:
The change [in init] has been one of the most contentious in the history of the [NetBSD] project.
UNIX Administratosphere 
As someone who has to work with SMF service definitions – the xml file that you craft to define start/stop commands and dependencies – I gotta say I hate SMF. It’s overcomplicated for what needs to be done.
My preference would be for whatever gives you the ability to modify the configuration without having to use commands like svcprop etc. Just edit an init script that has the dependencies etc inside it (defined using magic comments or whatever), inside a service script directory. In fact, keep the scripts in /etc/init.d and just have the dependencies in the init script themselves.
I loathe complicated service management initd replacements because they force you to do everything using their CLI. If you have a broken service, you can’t just go look at the logs, you need to do svcs -l , check why it’s in maintenance, maybe a dependency failed, or whatever, then you go check the dependent services, then you check logs … then you discover what is wrong.
I agree with some of your statements, but there are other things. Firstly, SMF, whatever its faults, is in Solaris and thus has a huge user base. In theory, others could use it as it is open source (though I’m not sure the license is compatible with a commercial UNIX). Consider HP-UX and Veritas: HP has used LVM for a very long time (and still does). Also, pretty much every UNIX on the planet uses sendmail. Why not use SMF too?
However, I hate “magic comments” – this breaks the entire “comment” model and makes the comment serve a purpose it was not designed to. It does seem to be the way of many things, though.
Also, many things that are called “overcomplicated” are merely too powerful for the job at hand – and just right for a different case or a different job.
My biggest complaint is that 99% of daemons out there have an init script but no service definition xml file to go with it. If SMF gave you an easy way to SMFify existing old sysv init scripts, then I wouldn’t care so much.
The reality is that when I hit one of these things that I need to convert from a sysv init script, I grab an xml file I created for something else, edit it until I think its about right, then drop it in the right places and off we go. Its not *that* terrible, I just think XML isn’t fit for human consumption. Make it a YAML config or something more sane, and I’ll grumble less.
One of these days I’ll write a script that can SMFify anything and just ask questions like “what services does this depend on” and it’ll output the XML for you. Meh, tomorrow.
> Why doesn’t HP-UX or AIX use SMF or Upstart if the current environment is horrible?
They are server systems. The traditional init is not horrible for them, it was designed for that use case. Linux is being used on the desktop and all kinds of other gadgets. The requirements there are different from large, always-on, multiuser systems with static network connections.
I don’t see the proliferation of init systems as a much of a problem, except possibly in the sense of duplicated effort. The init scripts never were all that portable even between systems that had Sys V init.
The traditional SysV init is terrible in some ways – including being complicated, and most of all, being slow. Some servers can take 5, 10, or even 15 minutes to fully start.
A parallelized startup process could cut the time down dramatically, and raise uptime correspondingly.
As far as portable goes for SysV init – I know you’re right. HP-UX and Solaris are prime examples.
SMF is useful on Solaris because it remembers state across reboots, very useful for server systems. svcadm enable blah, and assuming it successfully starts, next time you boot you know that the service will be started then. Bringing things under SMF control is painful, as there is simple way to do it, but once you have done it, its very convenient.
I would say HP-UX and AIX don’t use SMF because they are outdated. 🙂
I still dislike SMF for other reasons, though.
Hi,
I enjoy your blog very much. Keep it up!
Well, this adds to my todo list of things that have changed recently or some time ago and I need to learn their new replacements:
sys-v init ——-> systemd
old syslog —> rsyslog (or syslog-ng)
GRUB ——–> GRUB2 (which is wayyyy different)
Regards,
Craconia