The systemd projecct is an interesting concept for replacing init and related code [1]. There have been a few attempts to replace the old init system, upstart is getting some market share in Linux distributions and Solaris has made some interesting changes too.
But systemd is more radical and offers more benefits. While it’s nice to be able to start multiple daemons at the same time with dependencies and doing so offers improvements to the boot times on some systems that really doesn’t lead to optimal boot times or necessarily correct behavior.
Systemd is designed around a similar concept to the wait option in inetd where the service manager (formerly inetd and now the init that comes with systemd) binds to the TCP, UDP, and Unix sockets and then starts daemons when needed. It apparently can start the daemons as needed which means you don’t have a daemon running for months without serving a single request. It also implements some functionality similar to automount which means you can start a daemon before a filesystem that it might need has been fscked.
This means that a large part of the boot process could be performed in reverse. The current process is to run fsck on all filesystems, mount them, run back-end server processes such as database servers and then run servers that need back-end services (EG a web server using a database server). The systemd way would be for process 1 to listen on port 80 and it could then start the web server when a connection is established to port 80, start the database server when a connection is made to the Unix domain socket, and then mount the filesystem when the database server tries to access it’s files.
Now it wouldn’t be a good idea to start all services on demand. Fsck can take hours on some filesystems and is never quick at the best of times. Starting a major daemon such as a database server can also take some time. So a daemon that is known to be necessary for normal functionality and which takes some time to start could be started before a request comes in. As fsck is not only slow but usually has little scope for parallelisation (EG there’s no point running two instances of fsck when you only have one hard disk), so hints as to which filesystem to be checked first would need to be used.
Systemd will require more SE Linux integration than any current init system. There is ongoing debate about whether init should load the SE Linux policy, Debian has init loading the policy while Fedora and Ubuntu have the initramfs do it. Systemd will have to assign the correct SE Linux context to Unix domain socket files and listening sockets for all the daemons that support it (which means that the policy will have to be changed to allow all domains to talk to init). It will also have to manage dbus communication in an appropriate way which includes SE Linux access controls on messages. These features mean that the amount of SE Linux specific code in systemd will dwarf that in sysvinit or Upstart – which among other things means that it really wouldn’t make sense to have an initramfs load the policy.
They have a qemu image prepared to demonstrate what systemd can do. I was disappointed that they prepared the image with SE Linux disabled. All I had to do to get it working correctly was to run the command “chcon -t init_exec_t /usr/local/sbin/systemd” and then configure GRUB to not use “selinux=0” on the kernel command line.
Another idea is to have systemd start up background processes for GUI systems such as KDE and GNOME. Faster startup for KDE and GNOME is a good thing, but I really hope that no-one wants to have process 1 manage this! Having one copy of systemd run as root with PID 1 to start daemons and another copy of the same executable run as non-root with a PID other than 1 to start user background processes is the current design which makes a lot of sense. But I expect that some misguided person will try to save some memory by combining two significantly different uses for process management.
Having used SMF, “interesting” is not the adjective I would use to describe it.
http://en.wikipedia.org/wiki/Service_Management_Facility
Emil: They claim to have learned from other systems. What exactly didn’t you like about SMF? For other readers the above URL has background information on SMF.
SMF is incredibly slow, especially on first boot. This makes debugging/building a jumpstart config really painful. It’s also a mishmash of XML, SQLite, and crazy in-database snapshots of prior configurations which just rub me wrong as a UNIX minimalist. (this may be a failing on my part rather than SMF’s)
For the record, I’m a huge fan of Luke Mewburn’s rc.d design, which is what FreeBSD has used since 5.x (imported from NetBSD?)
SMF imports all manifests on first boot, so this takes some time, yes.
For me SMF is the only usable init system today with nicely integrated config management and forward/backward dependencies.
Especially the state of current init systems on linux is a joke, though not a really good one (not counting systemd here)!
It seems odd not to mention launchd in this article, as Lennart does in introducing systemd. It’s certainly an interesting comparison point with SMF, but as Lennart notes, it’s perhaps insufficiently flexible and backwards compatible for use in Linux distributions.
Emil: Complexity really isn’t what you want in the most important process on your system!
Adam: Anyone who follows the link to the systemd post will see the references to launchd. Personally I don’t like Apples, don’t want to use them, and as their code isn’t under the GPL it’s of little interest to me. Systemd is the Linux program inspired by launchd and is the one for us to consider. If I had mentioned launchd then I would have had to mention the Solaris thing, etc. This is one of my shorter posts, I’m just covering the basic issue with a focus on Linux specific stuff and more importantly stuff that I will end up personally working on.
But please feel free to write a detailed post about launchd on your own blog and put the link in a comment here. I’m sure that some readers will be interested. If you don’t have a blog then I might publish a guest post you write about this topic – NB I’m not going to promise anything at this time, I’d have to see what you write first.
Yes, systemd currently does not fiddle with SELinux at all. However we are very interested to add support for it (after all I am a RH guy), including in the initrd-less mode that Debian currently uses. In fact I’d appreciate a patch adding Debian-style SELinux support via some selinux-setup.c code in systemd, given that my own SELinux-fu right now is rather limited. This should be similar to how we alreay have infrastructure that sets up other basic facilities during bootup from within systemd, such as hostname, loopback, api mounts. (tbh though I wished we could do without the self-execution that is in the sysvinit patch Debian uses. Not sure though if that is possible in SELinux).
Do you win anything by mixing inetd into init? Otherwise, what’s the benefit compared to simply using inetd to reduce the number of daemons to launch?
http://marc.info/?l=selinux&m=127688991821846&w=1
systemd has been discussed on the SE Linux list. It seems that systemd will be used in Fedora soon.
It seems that I won’t need to do any coding for this either, they already have a design and some sample code.