Wandering Thoughts archives

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 'TriggeredBy=' 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 TriggeredBy units. Listed units would not have to exist at the beginning of systemd's operation, and 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, automatically created .mount units).

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 PartOf= and 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 PartOf 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 underlying filesystem).

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.