Linux – Can a systemd dependency be applied only to a unit’s “ExecStart” action

arch linuxcryptsetupmountsystemd

I have a scenario where a number of storage volumes are encrypted using keys contained on a removable encrypted USB "keyring" flash drive. I am running Arch Linux and this question is about systemd dependency configuration.

The system is configured so that, as long as the keyring is present, the system boots and the volumes are mounted. The keyring passphrase is manually entered during boot.

I want to be able to remove the USB keyring once the system is up, However, I am having problems with this because systemd unmounts everything.

Here is an example of what I have done. First, /etc/crypttab

# <name>  <device>           <password>             <options>
keyring   PARTLABEL=keyring  none                   noauto
abc       /dev/lvm/abc       /root/keyring/abc.key  header=/root/keyring/abc.hdr
xyz       /dev/lvm/xyz       /root/keyring/xyz.key  header=/root/keyring/xyz.hdr

  • I am using a recent Git checkout of systemd that supports the header option; it was added to the code-base on January 8th.

  • I am using the partition label of the keyring because there are multiple physical keyrings for backup/convenience reasons. They may have different UUIDs but are setup with the same PARTUUID.

  • I am using noauto so the keyring is only a dependency of any devices that need to be decrypted.

Next is /etc/fstab:

# <file system>     <dir>         <type>    <options>
/dev/mapper/keyring /root/keyring ext4      ro,noauto
/dev/mapper/abc     /srv/abc      ext4
/dev/mapper/xyz     /srv/xyz      ext4

Again, the keyring is noauto so mounting only occurs due to it being a dependency. Also, it's mounted read-only so that it's safe to just pull it out.

Now, to create the dependency between the volume and the keyring, I have used a drop-in override, for example:

# /etc/systemd/system/systemd-cryptsetup\@abc.service.d/override.conf
[Unit]
Requires=root-keyring.mount

That all works fine for start-up. The problem is that removing the keyring stops the units that are dependent on it. I don't want this to happen – the dependency is only required to make the keys and headers accesible while the encrypted volumes are unlocked. Once unlocked, the keys and headers are no longer required.

So, my question is to ask how can I arrange a dependency on the keyring that only exists for the duration of the "ExecStart" command in the systemd-cryptsetup@.service unit ?

Alternatively, if this is the wrong approach, any improved solutions would be welcome.

Best Answer

Instead of an explicit dependency, perhaps you could use an automount.

I remember Systemd advertised this during Poettering's initial blog post, as a kind of implicit dependency. It's like how (with systemd) you can write requests to a socket and the appropriate service will be started for you, aka "socket activation". In this case, accessing the filesystem will cause it to be mounted.

With this approach you can expect to block until the service or filesystem is ready. Note: this implies your system will have a directory that blocks you if you try to look at it (once you've removed the "keyring" drive)... Maybe if you ever use /root for anything else, it'd be better to mount it elsewhere e.g. /automount/keyring, to avoid tripping over it. Personally I think this sort of issue makes automounts a bit confusing - but it does seem to make a very quick solution to your question.

If the filesystem is listed in /etc/fstab, just add x-systemd.automount to the list of options.

If it's described by a native .mount file instead, it looks like you need to create a .automount file of the same name. E.g. root-keyring.automount, containing:

[Automount]
Where=/root/keyring
Related Question