Solaris SMF on linux with systemd

One of the nicer things on Solaris is SMF, the service management facility. It is a replacement for the SysV init system. It’s major features were parallel starting of services, built in service dependencies and pretty good reporting functionality. It also could pretty exactly report, which service failed and what other services were failing over that one. So the dependencies worked in starting and stopping direction. One of the worst parts of it was the horrible XML file you had to write for a service to work. I never found them very intuitive and too complex to “just” start and stop a service.

It was a pretty good experience and I found it confusing on linux, that no init system was the same. On gentoo all init scripts have a status, only some have on debian. One has to take care of logging yourself and dependencies were either managed through a start order (in archlinux in /etc/rc.conf), by alphabetical order and runlevels (in gentoo) or they built their own system into the init scripts as comments (the debian way).

Then came ubuntu und built their own init system named upstart. It is a bit between the old SysV init system as it uses init like script files but extended them for some further information, like when to start a service. But most of the file still is mostly script code and gets executed by a shell. One of the largest change for old users is, that this system can’t make use of /etc/init.d/scriptname start anymore. Instead you use start service or stop service. I think, this is a pretty good API and much better for new users to learn. It can react on events to start and stop services and also can try to restart failed services. Services can also communicate with upstart over dbus.

Systemd on the other hand is a very different to SysV. At first I was a bit skeptical because of all the negativity. But now I run 3 systems with systemd and till now, it feels good. These three systems are all archlinux boxes and there the migrations is very easy. You can take a look at the wiki page. You can run systemd parallel to SysV init and start it with a parameter in grub. If you feel confident enough you can uninstall the old system and use only systemd in the future.

So what exactly has systemd, what SysV is missing?

It uses udev (or udev systemd?) pretty intensive, so that it can show you information about your hardware. Another thing is, that it can start the daemons in parallel. This alone cut my boot time in half. But it is not that important to me. It was just a wow effect. Next is the management of the service themselves. The command systemctl is the API to everything in systemd, so not as nice as upstart. But with just systemctl you already get an overview which services are currently loaded, running and which failed (here is a gist of what it looks like). You can start and stop services with systemctl start or systemctl stop but this will make it not permanent. If you come from solaris and SMF you will find it confusing, as an enable or disable will activate and start the service, or disable and stop the service. But I found it pretty helpful when switchting from one thing to another and I just don’t want to stop the service. Think about switching the login manager. You may have installed the new one, enable it to start at boot time and disable the old one. Now you can still do other things and wait with the restart or you switch to the terminal and stop the old one and start the new one. I waited and did some configuration and afterwards, restarted the hole machine. Did not take me any longer than switching to the console. Another feature is, that systemd has an included logger. For some it may be not a feature as they already use a configured syslog-ng and don’t worry, you can still use it. The program is called journalctl and is bundled with systemd. Systemd starts every deamon within the logger context, so that every program does not have to worry about logging anymore but can just spout it onto STDOUT and systemd takes care of the rest. Yes, it sounds pretty retarded, but with it comes a pretty neat feature. If you now call systemctl status service you get an overview of the status of the service including the last couple log entries! As systemd builds automatic cgroups it can also show our the daemon dependencies. You can see how it looks like for net-auto-wireless on my laptop.

And I would say, that this is by far the best systemd could give me. If a service dies, I need to know all these things and this is the first system, which can show me. Not even SMF could do that. It would just tell me that my service died and others died of it as well, but it could not tell me exactly why or show me the logs.

Yes, my machines all boot faster and I profit from it. I shut down my pcs now. But that is nothing in comparison to the context I get when looking at a service. I can only recommend for everyone to try systemd and look for yourself, if it may help you get your work done faster.

At the moment fedora, Suse and Mandriva seem to be only one using systemd by default. There are other distributions having packages for them. From debian I know, that you can’t replace the SysV as easy as on archlinux. But it seems to work. There are already many service files out there for various daemons so it seems to get moving pretty fast. It will be interesting how fast it will be adopted by various distributions.