Re: [systemd-devel] Antw: [EXT] Re: Q: Difference between AssertPathExists and ConditionPathExists?

2022-03-17 Thread Andrei Borzenkov
On 17.03.2022 14:15, Ulrich Windl wrote:
 Andrei Borzenkov  schrieb am 17.03.2022 um 12:08 in
> Nachricht
> :
>> On Thu, Mar 17, 2022 at 12:32 PM Ulrich Windl
>>  wrote:
>>>
>>> Hi!
>>>
>>> When reading the manual page systemd.unit(5), I'm not quite sure what the 
>> difference between AssertPathExists and ConditionPathExists is:
>>>
>>> (Condition)
>>> If the specified absolute path name does not exist, the condition will fail.
>>>
>>> Vs.
>>>
>>> (Assert)
>>> However, unlike the conditions settings, any assertion setting that is not 
>> met results
>>> in failure of the start job it was triggered by.
>>> 
>>> What does that mean effectively?
>>>
>>
>> Assert makes the start job fail, which triggers any followup failure
>> processing (like failure of other units Requiring this one). Condition
>> silently skips starting of this unit but proceeds normally with
>> starting dependent units.
> 
> OK, ist that "skip" actually a "skip once (and silently) for now", or is it 
> more like a "delay until no longer true"?
> 

Start job is completed without doing anything, there is no delay.


[systemd-devel] Antw: [EXT] Re: Q: Difference between AssertPathExists and ConditionPathExists?

2022-03-17 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 17.03.2022 um 12:08 in
Nachricht
:
> On Thu, Mar 17, 2022 at 12:32 PM Ulrich Windl
>  wrote:
>>
>> Hi!
>>
>> When reading the manual page systemd.unit(5), I'm not quite sure what the 
> difference between AssertPathExists and ConditionPathExists is:
>>
>> (Condition)
>> If the specified absolute path name does not exist, the condition will fail.
>>
>> Vs.
>>
>> (Assert)
>> However, unlike the conditions settings, any assertion setting that is not 
> met results
>> in failure of the start job it was triggered by.
>> 
>> What does that mean effectively?
>>
> 
> Assert makes the start job fail, which triggers any followup failure
> processing (like failure of other units Requiring this one). Condition
> silently skips starting of this unit but proceeds normally with
> starting dependent units.

OK, ist that "skip" actually a "skip once (and silently) for now", or is it 
more like a "delay until no longer true"?

Regards,
Ulrich