systemd is awesome.

Writing services is fun

If you want your own services, you just need to write some simple INI files. No need for bash, distro-specific frameworks and whatnot. If I have a functioning service written on Arch, I can just copy the file over to Fedora and blindly enable it — assuming I have the executables installed, it’s guaranteed to work.

And the units are tiny:

fedora$ wc -l /usr/lib/systemd/system/nginx.service
15 /usr/lib/systemd/system/nginx.service
debian$ wc -l /etc/init.d/nginx
101 /etc/init.d/nginx

And you can write a bare-minimum systemd daemon in less than that – not so easy with sysvinit (writing everything on one line doesn’t count!)

Managing personal services

systemd also features user-specific services. You can run any service as your user. I use this to run KwBot, which was previously under control of supervisord — that’s one less dependency to care about!

Runlevels do not exist

systemd does away with the standard convention of runlevels. They are replaced by human-friendly targets. Each unit defines its target: most use multi-user.target. It is much easier to manage.

No symlink mess

Just like old sysvinit-esque systems, systemd uses symlinks to manage enabled/disabled services. There is just one difference: you get just one symlink in the appropriate .wants directory. You do not have to look into all the different runlevels. graphical.target depends on multi-user.target, which in turn depends on basic.target, which depends on a few more targets required to get the system up and running.

Units can depend on each other

Do you have some units that require the network to be up? Set it to be run after and require network.target and call it a day.