[systemd-devel] systemd | Requires statement with an instantiated service

[Andrei Borzenkov]

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 at .service
>>> b.service
>>>
>>> a at .service is started as a at host1.service and b.service must be started
>>> after a at 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 at .service, you can just as well
>> manually add necessary Requires at the same time. E.g.
>>
>> a at .service:
>>
>> [Install]
>> RequiredBy=b.service
>>
>> systemctl enable a at 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 at .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.

> 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 at .service but that is not
>>> enough.
>>>
>>
>> Why?
> 
> a at .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?