After RTFM’ing, I realized, under the hood, systemd just runs mount command to mount the specified partition with the specified mount options listed in the mount unit file. Basically, you need to specify the following options in your unit file:

What= a partition name, path or UUID to mount
Where= an absolute path of a directory i.e. path to a mount point. If the mount point is non-existent, it will be created
Type= file system type. In most cases mount command auto-detects the file system
Options= Mount options to use when mounting

In the end, you can convert your typical fstab entry such as this:

UUID=86fef3b2-bdc9-47fa-bbb1-4e528a89d222 /mnt/backups ext4 defaults 0 0

to:

[Mount]
What=/dev/disk/by-uuid/86fef3b2-bdc9-47fa-bbb1-4e528a89d222
Where=/mnt/backups
Type=ext4
Options=defaults

10 years ago, systemd was announced and swiftly rose to become one of the most persistently controversial and polarizing pieces of software in recent history, and especially in the GNU/Linux world. The quality and nature of debate has not improved in the least from the major flame wars around 2012-2014, and systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it.

I am writing this essay both for my own solace, so I can finally lay it to rest, but also with the hopes that my analysis can provide some context to what has been a decade-long farce, and not, as in Benno Rice’s now famous characterization, tragedy.

systemd has become a mainstay for the Linux world, but one of the things that still seems to stick around is cron jobs. It’s understandable, as cron is a tool that we have been using for a long time. Change is hard, but I think systemd Timers make the change well worth it. Here are a few reasons why…