Would perhaps systemd.automount be the solution to this issue?

I'm not sure I understand how this differs from WantedBy= (i.e. the .wants/ subdirectories).

As far as I've tried, it does work for nonexistent units, e.g. a nonexistent .device can trigger a .mount when it becomes existent and active (IIRC, this is how auto,nofail is implemented), and externally-done mounts do likewise pick up any foo.mount.wants/ symlinks.

Though you can't create those via systemctl add-wants, and it's possible that older systemd versions might not have allowed to systemctl enable if the WantedBy= pointed to a nonexistent unit (I haven't checked; the latest version only shows a warning), but it works fine when the symlink is done manually or through a generator.

The same goes for foo.mount.d/, of course you can't really control things like "After=" or "Options=" for a mount that already happened, but you can add a [Unit] Wants= through drop-ins; my autofs-managed mounts seem to consistently trigger the test service I've added in both ways.

Maybe I misunderstand the problem you're trying to solve, but perhaps zfs-mount-generator(8) could alleviate at least some of these problems? Especially the custom properties?

Would systemd.path(5) be of some use?

Defines paths to monitor for certain changes: PathExists= may be used to watch the mere existence of a file or directory. […] DirectoryNotEmpty= may be used to watch a directory and activate the configured unit whenever it contains at least one file.

• https://www.freedesktop.org/software/systemd/man/systemd.path.html

Units also have various ConditionPath* checks:

ConditionDirectoryNotEmpty= is similar to ConditionPathExists= but verifies that a certain path exists and is a non-empty directory.

• https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionPathExists=

Automounting adds an extra layer of undesired indirection over top of a bind mount, and it's not clear from the systemd documentation what happens if the .mount unit fails when the automount unit tries to activate it. At best this is "on demand" bind mount attempts, which may eventually succeed, instead of a bind mount triggered (reliably) when the underlying mount appears.

If I'm understanding the idea right, a WantedBy (or Wants) doesn't deal with things being asynchronous, as far as I know and can see from the systemd documentation. The bind mount Wants the underlying real mount (whether this is expressed by itself or by the real mount having a WantedBy of the bind mount), but this merely means that the bind mount will fail if the real mount isn't there when it tries to start; it doesn't activate the bind mount when the real mount appears.

Inverting the Wants relationship so that the bind mount says it is WantedBy the underlying real mount doesn't work. If the real mount isn't there, the bind mount still tries to happen (since it's only a Wants). You don't want to use a RequiredBy instead, because then if the bind mount fails for some reason the real mount will at least be considered to have failed, which is not right and almost certainly not wanted.

(If you put a Condition on the bind mount that isn't satisfied if the real mount doesn't exist, systemd v237 doesn't retry the mount later; it sticks at 'start condition failed'.)

My guess is that zfs-mount-generator won't help, because the fundamental issue is units that don't activate immediately but that we want to trigger other units. Having real .mount units for ZFS filesystems probably doesn't help if the ZFS filesystems don't appear promptly when systemd is starting everything.

(This comment reply has been delayed by me wanting to find time to test some things brought up here.)

On systemd path units, testing says that they don't notice when a mount appears that has what they're looking for. If you have a path unit with PathExists=/cs/mail/.flag and it starts before the /cs/mail mount, it won't notice when the mount happens and the flag file is now present. This is probably an intrinsic limit in the underlying kernel inotify mechanism that path units use.

(If you 'systemd restart <what>.path', it does notice and will trigger your bind mount, but there's nothing to auto-restart your path units.)

If I'm understanding the idea right, a WantedBy (or Wants) doesn't deal with things being asynchronous, as far as I know and can see from the systemd documentation. The bind mount Wants the underlying real mount (whether this is expressed by itself or by the real mount having a WantedBy of the bind mount), but this merely means that the bind mount will fail if the real mount isn't there when it tries to start; it doesn't activate the bind mount when the real mount appears.

The point is that you could have the real mount Want the bind mount. It's a dependency loop, but not necessarily an ordering loop: the bind mount would have Wants/After=real, but the real mount would have Wants/Before=bindmount.

It looks like I messed up in my first round of testing a bind mount that set a WantedBy of the underlying mount, because it now works for me on the Ubuntu 18.04 LTS systemd v237. However, at least in this environment it has the problem that if I unmount the bind mount, systemd goes ahead and unmounts the underlying mount too (which then gets ZFS a bit upset). This is definitely not what I want in a general triggering relationship; I should be able to shut down the triggered thing (here, the bind mount) without the triggering thing getting shut down by systemd.

(I think I probably left my bind mount also WantedBy local-fs.target, so that systemd attempted to activate it on boot even when the underlying mount wasn't there because that's what I told it to do.)

You can get a lot of the way there with a ExecStartPost= directive, a ExecStartPre= directive, and a .path service file.

Have the triggering service (foo.service) create a temporary file via a ExecStartPost= directive (touch /path/to/some/file).

Have the triggered service (bar.service) have a corresponding .path unit file (bar.path) which is watching for the creation of the file created by the triggering service (ie. bar.path watches for foo.service to create /path/to/some/file).

Have the triggered service (bar.service) have a ExecStartPre= (or maybe ExecStartPost=) directive to clean up the file.

You could also just have a systemctl start call in the ExecStartPost= directive instead, but then you lose the declarative nature of systemd.

Oh and you probably can clean this up by abusing the JoinsNamespaceOf= directive to have the services share a file system namespace.