Understanding systemd

Like it or not (unfortunately), systemd is here to stay, so we might know what to do with it. My first …encounter with systemd was in a Fedora system. I tried to ignore it as I long as I could. But unfortunately here comes the first server that I administer with RHEL 7. And then another one with CentOS 7. An now, a third one with a beta of CloudLinux.. Sh*t I wondered. Now what ?

So I am introducing a new category, a systemd dedicated category (sic) and I will try to explain whatever I learn from it, categorize it and make it a cheat-sheet why not..

Let’s begin.

systemd is controversial for several reasons: It’s a replacement for something that a lot of Linux users don’t think needs to be replaced, and the antics of the systemd developers have not won hearts and minds. But rather the opposite, as evidenced in this famous LKML thread where Linus Torvalds banned systemd dev Kay Sievers from the Linux kernel.

It’s tempting to let personalities get in the way. As fun as it is to rant and rail and emit colorful epithets, it’s beside the point. For lo so many years Linux was content with SysVInit and BSD init. Then came add-on service managers like the service and chkconfig commands. Which were supposed to make service management easier, but for me were just more things to learn that didn’t make the tasks any easier, but rather more cluttery.

Then came Upstart and systemd, with all kinds of convoluted addons to maintain SysVInit compatibility. Which is a nice thing to do, but good luck understanding it. Now Upstart is being retired in favor of systemd, probably in Ubuntu 14.10, and you’ll find a ton of systemd libs and tools in 14.04. Just for giggles, look at the list of files in the systemd-services package in Ubuntu 14.04:

$ dpkg -L systemd-services

Check out the man pages to see what all of this stuff does.

It’s always scary when developers start monkeying around with key Linux subsystems, because we’re pretty much stuck with whatever they foist on us. If we don’t like a particular software application, or desktop environment, or command there are multiple alternatives and it is easy to use something else. But essential subsystems have deep hooks in the kernel, all manner of management scripts, and software package dependencies, so replacing one is not a trivial task.

So the moral is things change, computers are inevitably getting more complex, and it all works out in the end. Or not, but absent the ability to shape events to our own liking we have to deal with it.