On 02.09.21 15:12, Andrei Borzenkov wrote:
On 02.09.2021 15:10, Leon Fauster wrote:
On 02.09.21 08:00, Andrei Borzenkov wrote:
On 02.09.2021 01:19, Leon Fauster wrote:
Example:
a@.service
b.service
a@.service is started as a@host1.service and b.service must be started
after a@host1.service but the unit will be differently parameterized
(depended of the region). So I want to generalize the requires
statement.
If you need to manually instantiate a@.service, you can just as well
manually add necessary Requires at the same time. E.g.
a@.service:
[Install]
RequiredBy=b.service
systemctl enable a@your-region.service
Indeed that was also what I tried but it seems that my problem is
that b.service needs a device from a.service, and that seems to need
some time to come up. Systemd is here to "fast". Just for the sake
It has nothing to do with being fast. Either a@.service should not
complete activation until device became available or you are solving the
wrong problem, because you actually want to order b.service against
device, not some random service.
of progress I implemented a workaround,
b.service.d/dep.conf
[Service]
ExecStartPre=/bin/sleep 3
I lost you here. If device appears as result of ExecStart in a.service,
no amount of delay *before* ExecStart is going to change anything. If
device appears independently of a.service, you are again solving the
wrong problem.
Let me rephrase it: "a" starts and systemd goes on and starts "b".
The "a" has Type=notify. My understanding (I'm not a systemd dev)
is that "a" completes from the point of systemd, therefore "b" is then
started. But the actual implementation of "b" needs a resource (device)
of "a" that obviously is not there when "b" is started.
So, "ExecStartPre=/bin/sleep 3" in b.service forces a pause and after
this pause the resource of "a" is available and "b" starts successfully.
I'm sure that this could be solved differently with all participating
components but in real world the human resources are limited and the
budget of the customer as well. ExecStartPre solves our problem and
some testing shows that different scenarios are covered as well. When
I find time I will take a closer look at the components especially the
"Type=notify" entry ...
a different workaround would be to let b.service fail and with the use
of Restart=on-failure bring it later up (RestartSec=5) but honestly that
seems to be more dirty then the above workaround.
I had also a device.unit in mind as trigger but I can not say in advance
what device will be used (dev0, dev1, dev2).
...
I use also a Before=b.service statement for a@.service but that is not
enough.
Why?
a@.service is started before b.service but in the same second, its to
close for b.service to be successful.
And how exactly Requires was going to help here?
I am just following the documentation:
- "its a common pattern to include a unit name in both"
Just give me some patience :-)
--
Leon
