Specify systemd dependency on any one of multiple units

systemd

Is it possible to specify a systemd dependency on any one of multiple units?

Currently, I have a unit Z that depends on at least one of unit A or unit B.

Configuring unit A to be WantedBy unit Z and unit B to be WantedBy unit Z mostly works.

However, if only one of units A or B is able to start, the boot process waits for the other unit to timeout before starting unit Z. I want to eliminate this timeout.

Units A and B require a timeout in order to function properly, however, once once of them has started, there is no need to wait for the other unit to timeout before starting unit Z.

Is there a way to specify that unit Z depends on either unit A or unit B, but does not need to wait for both unit A and unit B before starting unit Z?

In the Debian world, the packaging system uses Provides to specify something similar to what I'm hoping to accomplish here.

What I'm Trying To Accomplish

Debian used to support a keyscript option in crypttab but did not reimplement that option when upstream rewrote the startup scripts for the move to systemd. Previously, I used a keyscript to read my key from a USB drive. Currently, I am using a systemd unit file to take the place of the keyscript option (unit A). That works perfectly. However, USB drives are prone to failure, so for redundancy, I want to carry a second copy of my key on a second USB drive. And I want to add a second systemd unit file for that second USB drive (unit B), so that whichever USB drive is inserted, systemd is able to use that USB drive and continue without a timeout.

Other Things I've Tried

Using Conflicts to specify that A conflicts with B, and B conflicts with A. Unfortunately, systemd processes the conflict before attempting to start either of units A or B, and removes one of these units from the scheduler before trying to start the remaining unit. So Z sometimes fails, for example, if A fails, but B would have succeeded, if B was already eliminated from consideration due to the conflict with A.

Using JobTimeoutSec to shorten the timeout. Unfortunately, this can result in Z failing, if A and B timeout.

Michael Hampton's suggestions. As he mentions, the NTP example creates a weak dependency between each client and the target. Each NTP client wants the target, but the target does not depend on each of the NTP clients, so this works. However, as best I can tell, a weak dependency does not pull in the unit unless the unit also has an [Install] section specifying an additional dependency. So when I pull in my units A and B, the WantedBy in the [Install] section creates the blocking timeout. If I remove the [Install] section, units A and B are ignored.

Best Answer

This is a job for a systemd target unit.

Rather than give a contrived example, I'll give a real world example which is already present on your system.

Consider NTP. Most computers sync via NTP, but there are three (and maybe more) NTP clients that you might choose from: systemd-timesyncd, chronyd or (the classic) ntpd.

Each of the service units for these NTP clients is part of a target called time-sync.target, and weakly requires it as such.

Before=time-sync.target
Wants=time-sync.target

Thus, when you start any of the NTP clients, time-sync.target is started up after the NTP client starts. Note that time-sync.target itself is empty and doesn't actually do anything on its own.

So, if you run a service which requires that the system time has been synchronized, and would fail otherwise, you can require it to start only after time-sync.target has started.

After=time-sync.target
Requires=time-sync.target

You should easily be able to adapt this to your own service.

Related Solutions

Systemd: stop all uninstalled units

I asked the mailing list, and Lennart Poettering responded with the following advice:

http://lists.freedesktop.org/archives/systemd-devel/2013-July/012083.html

Quoting here for posterity:

So, the correct way to handle this is to make sure the packages in question contain the right scriplets that terminate all units they include before deinstallation. Of course, there'll always be broken packages like this I fear, hence I can totally see your usecase.

There's currently no nice way to handle this, but what you can do is this:

$ systemctl --all --type=not-found --type=error

This will list you all units where the load state is either "error" or "not-found" (note that 'not-found' is available only in very recent versions, and in older systemd versions was just a special case of 'error'. The command line above works for all versions). The --type= switch is used to filter unit types, but actually also can be used to filter for the load state.

Then filter out the first column:

$ systemctl --no-legend --all --type=not-found --type=error | awk '{ print $1 }'

This will give you a list of unit files which got referenced or started but have no unit file installed. Then use this to stop the units:

$ systemctl stop `systemctl --no-legend -all --type=not-found --type=error | awk '{ print $1}'`

How to configure multiple systemd services to use one timer

If you want to activate multiple services with a single timer insert a target in between:

The timer unit, let's call it foo.timer:

[Unit]
Description=My timer that runs saturdays, 9am and triggers foo.target

[Timer]
OnCalendar=Sat 9:00
Unit=foo.target

[Install]
WantedBy=timers.target

The target unit, let's call it foo.target:

[Unit]
Description= My target unit, that groups my two services xxx.service and yyy.service
Wants=xxx.service yyy.service
After=xxx.service yyy.service

[Install]
Also=foo.timer

And then the two services xxx.service and yyy.service:

[Unit]
Description=My service XXX

[Service]
ExecStart=/bin/echo I am XXX

[Install]
Also=foo.timer

[Unit]
Descritpion=My service YYY

[Service]
ExecStart=/bin/echo I am YYYY

[Install]
Also=foo.timer

Copy these four unit files (foo.timer, foo.target, xxx.service, yyy.service) into /etc/systemd/systemd/. Then enable and start the timer by issuing "systemctl enable --now foo.timer". That will hook foo.timer into timers.target, which is the generic target that is supposed to pull in all the various timers defined on a system. Note that you could as well do "systemctl enable foo.target" btw, and also "systemctl enable zzz.service", since the Also= lines in those units propagate the enablement requests towards foo.timer.