You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have two daemons, one is a.service, which depends on an instance of b@.service. I will not necessarily know what the name of the b@.service instance is when writing the unit file, but a.service will definitely depend on one of those instances being running.
My solution is to create an b.target, of which b@.service contains PartOf=a.target and WantedBy=a.target.
I want b.target to be started any time graphical.target is started, so ideally I want b.target to be WantedBy=graphical.target. a.service should also be WantedBy=graphical.target, but also needs to be Requisite=b.target and After=b.target (It should not start b.target, and should fail if b.target is not started).
[ a.service ]
| |
| Depends on |
v v
[ b.target ] <--is part of--[b@x.service]
| |
| Should be |
| started by |
v v
[graphical.target]
The systemd.target documentation specifies that targets are installed with a Requires= clause, but if I do that, it creates a dependency loop, when really I want it to be RequiredBy or WantedBy graphical.target, and not the other way around.
This works if, and only if, I add an [Install] section with WantedBy=graphical.target to b.target. The documentation does not seem to indicate this should be done, but it works - on startup, graphical.target correctly starts up b.target, which starts up b@x.service, and graphical.target also starts a.service, which correctly waits for b@x.service to start.
Is this the correct way to handle a service depending on an instanced service, and is this the correct way to handle dependencies between targets? Just because something works does not necessarily mean it is the correct way to do it, and systemd in particular has a "systemd way" of doing things that tends to relieve headaches down the road if that "systemd way" is followed.
The text was updated successfully, but these errors were encountered:
This is not a support forum but a bug and feature request tracker. The submission form should have made that very clear, in order to minimize disappointments. Please contact the systemd mailing list or so instead, which is where support is provided. Thank you for unerstanding.
A little exposition to explain my situation:
I have two daemons, one is a.service, which depends on an instance of b@.service. I will not necessarily know what the name of the b@.service instance is when writing the unit file, but a.service will definitely depend on one of those instances being running.
My solution is to create an b.target, of which b@.service contains
PartOf=a.target
andWantedBy=a.target
.I want b.target to be started any time graphical.target is started, so ideally I want b.target to be
WantedBy=graphical.target
. a.service should also beWantedBy=graphical.target
, but also needs to beRequisite=b.target
andAfter=b.target
(It should not start b.target, and should fail if b.target is not started).The systemd.target documentation specifies that targets are installed with a
Requires=
clause, but if I do that, it creates a dependency loop, when really I want it to be RequiredBy or WantedBy graphical.target, and not the other way around.This works if, and only if, I add an [Install] section with
WantedBy=graphical.target
to b.target. The documentation does not seem to indicate this should be done, but it works - on startup, graphical.target correctly starts up b.target, which starts up b@x.service, and graphical.target also starts a.service, which correctly waits for b@x.service to start.Is this the correct way to handle a service depending on an instanced service, and is this the correct way to handle dependencies between targets? Just because something works does not necessarily mean it is the correct way to do it, and systemd in particular has a "systemd way" of doing things that tends to relieve headaches down the road if that "systemd way" is followed.
The text was updated successfully, but these errors were encountered: