[systemd-devel] Antw: Re: Mutually exclusive (timer-triggered) services

[Alexander Koch]

>>>> * flock leaves the lock file behind so you'd need some type of
>>>> cleanup in case you really want the jobs to be trace-free. This is
>>>> not as trivial is it might seem, e.g. you cannot do it from the
>>>> service units themselves in `ExecStartPost=` or similar.
>>> An
>>> 
>>> ExecStartPost=-/usr/bin/flock -F /path/to/lock.file \
>>>               /usr/bin/rm /path/to/lock.file
>>> 
>>> should solve this issue.
>> 
>> So you can remove a file other processes are blocked lock-waiting on?
>> Didn't
>> expect this to work, thanks for the hint.
> 
> It's a common misconception (especially when grown up with Windows)
> that "rm" removes a file: Actually it "unlinks" the name from the
> inode. As long as the inode is opened by the kernel, the file (as seen
> from the kernel's perspective) still exists.

I haven't really grown up with Windows ;P

Assuming `flock` (the binary) uses the flock() syscall it still needs to 
go
through VFS to get a file descriptor. So if a second process calls 
`flock`
after the first one has already unlinked the name from the inode, the 
lock
file will not be found and thus be re-created, breaking the locking
mechanism.

Or did I miss something and the second flock somehow obtains the inode
number of the old lock?


Best regards,

Alex