= 3 things you didn't know systemd could do

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 realised systemd could do, but should be taking advantage.

== 1. Simplify 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.
https://www.redhat.com/sysadmin/cgroups-part-four[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:

[source,text]
----
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. 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 https://opensource.com/article/21/2/linux-automation[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.


[source,bash]
----
[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 containers

Containers make starting up a complex service really easy.
You can run a https://opensource.com/education/16/3/mattermost-open-source-chat[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, https://www.redhat.com/sysadmin/podman-run-pods-systemd-services[you can use systemd].

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

[source,bash]
----
$ podman generate systemd --new --files --name example_pod
----

All you have to do then is start the service:

[source,bash]
----
$ 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 or OpenShift, 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.

== Read more

There's a lot more to systemd, and you can learn the basicso, along with lots of useful and pragmatic tips, from author David Both in his new complementary LINK TO EBOOK.
