[systemd-devel] Behavior of BindsTo when stopping a service

Andrei Borzenkov arvidjaar at gmail.com
Sun Jan 28 06:04:00 UTC 2018


28.01.2018 02:11, Amit Saha пишет:
> On Sun, 28 Jan 2018 at 6:22 am, Andrei Borzenkov <arvidjaar at gmail.com>
> wrote:
> 
>> 26.01.2018 05:11, Amit Saha пишет:
>>> Hello,
>>>
>>> I have a systemd service - drainconnections which I want to to make sure
>>> finishes stopping before systemd starts stopping another service. What I
>>> also want is to if I stop supervisord service, drainconnections should be
>>> stopped first.
>>>
>>> It seems like BindsTo is what I need for establishing the coupling
>> between
>>> the two units.
>>
>> If your description of services relationship is accurate and complete,
>> BindsTo is too strong here; you really need just PartsOf.
> 
> 
> Thanks. PartOf looks like something more suitable. Would having PartOf in
> supervisord obey the before after relationship setup by drainconnections
> service?
> 

PartsOf (like BindsTo) is orthogonal to After/Before. PartsOf/BindsTo
define what to do, After/Before define when to do.

> I will give it a shot.
> 
>>
>>
>>> The following unit file describes drainconnections:
>>>
>>>
>>> [Unit]
>>> Description=Drain Connections
>>> After=supervisord.service
>>> BindsTo=supervisord.service
>>>
...
>>>
>>> In addition, I also needed to add BindsTo=drainconnections to the
>>> supervisord service.
>>>
>>
>> This will create dependency loop with your unit definition shown above.
> 
> 
> Wouldn’t the Before/After take care of breaking the dependency loop? That
> seems to be what I observed.
> 

Probably I had to elaborate. If you need full BindsTo semantic (which is
superset of Requires) it only works as documented if you also have
corresponding After/Before which creates loop. Otherwise Requires part
is mostly useless. If you are only interested in propagating stop
request and "stopping on surprise removal" part of BindsTo then this is
probably OK, but this will make your units definitions rather confusing.



More information about the systemd-devel mailing list