[systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists

[Reindl Harald]

Am 14.08.2015 um 02:28 schrieb Ivan Shapovalov:
> On 2015-08-10 at 15:46 +0200, Reindl Harald wrote:
>>
>> Am 10.08.2015 um 15:28 schrieb Ivan Shapovalov:
>>> On 2015-08-10 at 15:14 +0200, Reindl Harald wrote:
>>>>
>>>> Am 10.08.2015 um 15:05 schrieb Ivan Shapovalov:
>>>>> On 2015-08-10 at 11:16 +0200, Reindl Harald wrote:
>>>>> Moreover,
>>>>>
>>>>>>
>>>>>> * "RuntimeDirectory" is a service configuration
>>>>>> * the daemon is started as unprivileged user
>>>>>> * "RuntimeDirectory" should be created long before
>>>>>>       ExecStart / ExecStartPost
>>>>>
>>>>> This is wrong. The runtime directory "will be created <...>
>>>>> when
>>>>> the unit is started, and removed when the unit is stopped".
>>>>
>>>> what is wrong?
>>>
>>> The runtime directory should be created right before the unit is
>>> started, not "long before ExecStart / ExecStartPost".
>>
>> so why trying to create it before "ExecStart" *and* "ExecStartPost"
>
> Because there may be no ExecStart= but ExecStartPost=.

how would that matter when "RuntimeDirectory" is just created at service 
start and removed at service end independent of any other lines?

>>>> "unit is started" is for me pretty clear the whole systemd-unit
>>>>
>>>>> As can be seen from the code, the runtime directory creation is
>>>>> attempted on execution of each configured process, be it
>>>>> ExecStart=
>>>>> or
>>>>> ExecStartPost= (or whatever else)
>>>>
>>>> and why in the world is the code written that way?
>>>
>>> This is pointless rhetoric.
>>
>> no it is not pointless rhetoric
>> it's a serious question
>
> See above.
>
> Doing explicit checks against existence of certain entries or
> implementing an ad-hoc FSM is way more fragile than just writing
> idempotent code

not it is not

mkdir, chown, chgrp, chmod at the very begin is fore sure not fragile, 
the expected behavior, free from race-conditions  and that the 
"idempotent code" is more fragile was already proven by the race 
condition of that topic

if the Fedora maintainer would care about such bugs it won't do that 
much harm, but they exists until the middle of a release lifetime

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150814/54d12fb3/attachment.sig>