3 surprising things Linux sysadmins can do with systemd

When it first started out, there was a lot of press about systemd and its ability to speed up boot time. That feature had a mostly-universal appeal (it's less important to those who don't reboot), so in many ways, that's the reputation it still has today. And while it's true that systemd is the thing that launches services in parallel during startup, there's a lot more to it than that. Here are three things you may not have realized systemd could do but should be taking advantage. Get more tips from our new downloadable eBook, A pragmatic guide to systemd.

1. Simplify Linux ps

If you've ever used the ps or even just the top command, then you know that your computer is running hundreds of processes at any given moment. Sometimes, that's exactly the kind of information you need in order to understand what your computer, or its users, are up to. Other times, all you really need is a general overview.

The systemd-cgtop command provides a simple view of your computer's load based on the cgroups (control groups) tasks have been arranged into. Control groups are important to modern Linux, and are essentially the support structures underneath containers and Kubernetes (which in turn are why the cloud scales the way it does), but also they're useful constructs on your home PC. For instance, from the output of systemd-cgtop, you can see the load of your user processes as opposed to system processes:

Control Group               Proc+   %CPU   Memory  Input/s Output/s
/                             183    5.0     1.6G       0B     3.0M
user.slice                      4    2.8     1.1G       0B   174.7K
user.slice/user-1000.slice      4    2.8   968.2M       0B   174.7K
system.slice                   65    2.2     1.5G       0B     2.8M

You can also view just your userspace processes, or just your userspace processes and kernel threads.

This isn't a replacement for top or ps by any means, but it's an additional view into your system from a different and unique angle. And it can be vital when running containers, because containers use cgroups.

2. Linux cron

Cron is a classic component of Linux. When you want to schedule something to happen on a regular basis, you use cron. It's reliable and pretty well integrated into your system.

The problem is, cron doesn't understand that some computers get shut down. If you have a cronjob scheduled for midnight, but you turn your computer off at 23:59 every day, then your cronjob never runs. There's no facility for cron to detect that there was a missed job overnight.

As an answer to that problem, there's the excellent anacron, but that's not quite as integrated as cron. There's a lot of setup you have to do to get anacron running.

A second alternative is systemd timers. Like cron, it's already built in and ready to go. You have to write a unit file, which is definitely more lines than a one-line crontab entry, but it's also pretty simple. For instance, here's a unit file to run an imaginary backup script 30 minutes after startup, but only once a day. This ensures that my computer gets backed up, and prevents it from trying to backup more than once daily.

[Unit]
Description=Backup
Requires=myBackup.service

[Timer]
OnBootSec=30min
OnUnitActiveSec=1d

[Install]
WantedBy=timers.target

You can, of course, intervene and prompt a job to run with . Thanks to the OnUnitActiveSec directive, systemd doesn't attempt to run a job you've manually activated.

3. Run Linux containers

Containers make starting up a complex service really easy. You can run a Mattermost or Discourse server in mere minutes. The hard part, in some cases, is managing and monitoring the containers once you have them running. Podman makes it easy to manage them, but what do use to manage Podman? Well, you can use systemd.

Podman has a built-in command to generate unit files so your containers can be managed and monitored by systemd:

$ podman generate systemd --new --files --name example_pod

All you have to do then is start the service:

$ systemctl --user start pod-example_pod.service

As with any other service on your computer, systemd ensures that your pod runs no matter what. It logs problems, which you can view with journalctl along with your other essential logs, and you can monitor its activity within cgroups using systemd-cgtop.

It's no Kubernetes platform, but for one or two containers that you just want to have available on a reliable and predictable basis, Podman and systemd are an amazing pair.

Download the systemd eBook

There's a lot more to systemd, and you can learn the basics, along with lots of useful and pragmatic tips, from author David Both in his new complimentary pragmatic guide to systemd.