0

Can multiple instances of Unit= exist in a systemd.path or systemd.timer unit? Or, must one instead specify multiple instances of the path or timer unit, each with a single instance of Unit=? I haven't been able to find or derive any guidance elsewhere.

The former obviously is easier.

The specific application is to have a path unit activate two mount units.

In particular, the path unit monitors a virtual machine's log file, which is quiet until the VM runs. The mounts are of shares on the virtual machine and are defined in the host's fstab entries, each of which uses the x-systemd.requires= mount option to specify the path unit, so that the mounts don't occur until the virtual machine is running. This works well with a single share.

So, the more specific questions are (a) whether the path unit knows to simply propagate the mount units as instructed, leaving the mount units to mount the shares, or gets confused and can only propate a single mount unit; or (b) whether calling the same path unit twice in fstab creates conflicts or errors when the path unit has many Unit= directives (i.e., by re-creating all the mount points specified) or simply is an expression of a dependency.

Many thanks.

0

man systemd.timer says:

Unit=

The unit to activate when this timer elapses. The argument is a unit name, whose suffix is not ".timer". If not specified, this value defaults to a service that has the same name as the timer unit, except for the suffix. (See above.) It is recommended that the unit name that is activated and the unit name of the timer unit are named identically, except for the suffix.

man systemd.path similarly says:

Unit=

The unit to activate when any of the configured paths changes. The argument is a unit name, whose suffix is not ".path". If not specified, this value defaults to a service that has the same name as the path unit, except for the suffix. (See above.) It is recommended that the unit name that is activated and the unit name of the path unit are named identical, except for the suffix.

Neither of these suggest that you can have multiple Unit= lines or multiple arguments per Unit= line. Even if you try it and find it works, it's not guaranteed that it will work in future releases of systemd because it would be undocumented behaviour.

Therefore it's safest to create a single *.path/*.timer for each unit you need to trigger, even if it means identical *.path or *.timer units. There are probably already several *.timer units with OnCalendar=daily on your system.

Hoestly, it would be a little scary to trigger two independent services if I touch a single path. It invites race conditions. You could consider changing your service to use multiple ExecStartPre= or ExecStartPost= to sequence the operations, ensuring they always happen in a deterministic order.

2
  • Many thanks. I read the same man language and the trouble is, it neither suggests nor discourages multiple Unit= lines. It simply is silent on the topic. Other directives (e.g., ExecStart=) can appear several times (although obviously better just to consolidate scripts), so one wonders about Unit=. Documentation failures are rife, and in lieu of a rant (or naming names), I'll just say this omission is trivial. As for triggering multiple services, I've read others here describe using meta-units for triggering multiple various things, so whether scary or useful depends. So, the question remains. – ebsf Apr 7 at 23:37
  • man pages are rarely explicit about what doesn't work. On the other side, timer's OnCalendar= explicitly says "May be specified more than once". and service's ExecStart= says "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified.". When multiple directives are supported, documentation is very explicit about it. That means that absent documentation strongly suggests no support. – Stewart Apr 8 at 6:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.