All your daemons are belong to us

systemd

Even though it was something I complained about in Arch, the one big thing I ended up missing was systemd. Arch makes systemd a first-class citizen. Debian has been in the middle of an official switch for months, but it still feels painful and not fully thought out. In retrospect, this makes sense: Arch has been on systemd for years, and Debian only announced systemd as the official init system back in February.

Of course, Debian has systemd. Jessie had the 204 release for most of the time I was using it. I’m back on Arch now, running systemd 215. As someone who uses my computer as a laptop and not, you know, a server, systemd user sessions are among the most useful features it has to offer.

Not long ago, I posted a horrible script for daemonizing my personal wiki. It barely worked. Sometimes it would cause ps to bug and report problems, which I was told to submit to the developers. Unfortunately, the line reported for causing the bug was the same line that was supposed to display information about the bug. I also have no idea where I’m supposed to report the bug - here at SourceForge? Who knows.

In lieu of writing a better script, something that uses mkdir for PID locks,¹ I started to miss the sheer beauty of letting systemd manage my user-level init. To me, it’s a simple fact that using shell scripts to spawn daemons for, say X startup is archaic, awful, and prone to errors.

On Arch, I can do this:

$ userctl start gitit

and it spawns my wiki process, keeps logs, and monitors its status like any other daemon. I’ve aliased userctl to systemctl --user, since it’s way easier to type and makes more sense in my head.

The script, located at $HOME/.config/systemd/user/gitit.service, looks like so:

[Unit]
Description=my personal wiki

[Service]
Type=simple
WorkingDirectory=%h/.gitit
ExecStart=/home/nathan/.cabal/bin/gitit -f %h/.gitit/my.conf
Restart=no

[Install]
WantedBy=console.target

Let’s break that down:

• [Unit]: generic information about the unit. Often contains dependency information - but not in this simple case. systemd.unit (5) has the details.
  • Description: name displayed in UI. For example, this is the name displayed when I type systemctl status gitit.²
• [Service]: Info about the process. See systemd.service (5) for the nitty-gritty.
  • Type: How the process gets started. simple means the process just runs, and it would block your terminal if you ran it at the shell and didn’t background it. There’s also forking for processes that call fork() during startup, oneshot, which starts and then dies quickly, and a few others that I won’t describe here.
  • WorkingDirectory: The directory that the service starts in. I had configured Gitit to start in $HOME/.gitit, and in systemd %h is the variable for a user’s home folder.
  • ExecStart: The command that launches the daemon (or program, in the case of oneshot). One quirk here: this has to be a fully qualified path, not just an executable or something you’d expect to find in $PATH.
  • Restart: Whether to restart the service on startup.
• [Install]: How to set up the dependencies and startup for a service.
  • WantedBy: The target that wants this service. Services in systemd are owned by targets, and when you enable or disable a target it will start the appropriate services with it. In this case, console.target is a service that starts every time I start a user session.

Once you have your daemons properly configured, systemd tracks everything they spawn and makes sure the process hierarchy matches that setup. There was a time, months ago, when I had my entire user session spawned by systemd - no bash scripts the whole way through. The htop tree output was beautiful: systemd tracks the parents of each process perfectly, and nothing escapes its watch and reparents to 1 like in traditional Linux systems.

And if I ever need more fine-grained control, cgroups have me covered.

Understanding

The other core part about Arch is that its very nature means you understand everything that goes on in your system. Certain parts about Debian just make it completely non-obvious how they work. What is update-alternatives doing under the hood? How is dpkg managing its configuration subsystem? The details are complicated just to use these systems, and finding information on the implementation nuts-and-bolts is over my head. The Arch philosophy of simplicity is immediately apparent: I can actually grok this system completely.

Even on a Debian minimal install, it started a daemon when I installed nethack. Frigging nethack! Can’t I make these decisions for myself?

There are situations where it’s not worth my time to figure out how to get things working, and I just want the operating system to do everything for me. But there’s an important balancing act whenever you’re building an operating system, where you can either make things easy at first and in the default case, or make them easy for the general case (but harder by default). Arch leans toward this system should be easy for a competent user.

Arch Build System

When I finally started compiling my own software on Debian, I realized how much harder it is to make packages compared to Arch. If I need a package for something that isn’t in the default repositories, I can usually spin one together in a few minutes (provided the software is easy to build). Debian packages are complicated, by contrast - capable of much more, perhaps, but raising the cost of creation.

Lowering the barrier to entry to the packaging system means I can have my entire system be first-class citizens to the package manager. That is awesome. I can’t remember the last time I had an arch system where I just ran sudo make install on some software and dropped it all over /usr/local. It’s easier to make a real package than to do that garbage.

Arch Wiki

The Arch Wiki is fantastic. I tell people it’s the best wiki in the Linux ecosystem. I’m pretty sure that I’m right about that one. Lots of people, including myself,³ really work hard to keep it up to date on the latest software in the Linux world. Today I was able to get nftables up and running in a few minutes thanks to their documentation.