[prev in list] [next in list] [prev in thread] [next in thread] 

List:       systemd-devel
Subject:    Re: [systemd-devel] systemd | Requires statement with an instantiated service
From:       Colin Guthrie <gmane () colin ! guthr ! ie>
Date:       2021-09-02 14:52:59
Message-ID: sgqoge$92f$1 () ciao ! gmane ! io
[Download RAW message or body]

Leon Fauster wrote on 02/09/2021 15:39:
> 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 ...

Indeed. The correct way to solve this is to make "a" only notify that it 
has completed starting up when it's finished creating everything that 
any dependant service will need. This includes opening and listening on 
any sockets or creating any devices etc.

Ultimately the problem here is "a" is notifying too early.

Whether you solve this properly (i.e. fix "a") or with some duct tape 
and good will (i.e. a sleep 3 in "b") is up to you :-)


Cheers

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited http://www.tribalogic.net/
Open Source:
   Mageia Contributor http://www.mageia.org/
   PulseAudio Hacker http://www.pulseaudio.org/
   Trac Hacker http://trac.edgewall.org/

[prev in list] [next in list] [prev in thread] [next in thread]