Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct way to enable a custom target #12418

Closed
mobusdorphin opened this issue Apr 26, 2019 · 1 comment
Closed

Correct way to enable a custom target #12418

mobusdorphin opened this issue Apr 26, 2019 · 1 comment

Comments

@mobusdorphin
Copy link

mobusdorphin commented Apr 26, 2019

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 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.

@poettering
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants