My wish for a way to activate one systemd unit when another one started
I recently wrote (again) about bind mounts under systemd for ZFS
filesystems, covering how you don't want to put them in
fstab and how you might not want them to say
they're required by local-fs.target.
ZFS filesystems are special here because they're not represented in
/etc/fstab or in explicit
.mount units; instead they unpredictably
appear out of the blue when some other program is run. ZFS mounts aren't
the only thing that can appear this way; our local NFS mounts are
managed through a program, and for
that matter removable media is not always there. These other cases can
expose similar issues (especially NFS mounts). All of them could be
solved through a feature that, as far as I know, systemd doesn't have,
which is activating one unit when another unit asynchronously appears
and becomes active.
(With such a feature, I would set bind mounts to activate when the underlying filesystem had appeared and been successfully mounted.)
Effectively what I want is something like a hypothetical '
property. If any unit in the list appeared and became active, the
unit with a
TriggeredBy would automatically try to activate.
Generally you'd also want an
After= on the
Listed units would not have to exist at the beginning of systemd's
TriggeredBy couldn't be implemented by creating
/etc/systemd/system/<what>.d/ directories with drop-in files,
because that doesn't work for all units (eg, the last time I looked,
As far as I can see you can't implement this with any existing set
of properties in systemd.unit(5),
although maybe I'm missing something. It's possible that
After= will do this, but if so it's not entirely clear to me
and on systemd v237, this doesn't appear to work if you declare a
PartOf=' to a ZFS filesystem's
.mount unit (which will only
appear to systemd when the pool is imported). Even if
worked, it could be too strong for some uses (although it's probably
right for a bind mount to automatically unmount if you unmount the
I understand why systemd doesn't do this. Unlike Upstart, systemd is not necessarily fundamentally built around events, so having events trigger units is not as natural a thing to it. Systemd has some limited event triggering in the form of its various activation schemes (socket, path, automounting, and timers), but all of this is specific and seems relatively hard coded. Asynchronous event handling is the domain of udev.
Comments on this page:Written on 16 October 2021.