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

[Ulrich Windl]

>>> Alexander Koch <mail at alexanderkoch.net> schrieb am 16.10.2019 um 16:14 in
Nachricht <9fb9c1a157e92baef1107ed3b66aa2b3 at alexanderkoch.net>:
>>>>> * 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

OK!

> 
> 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?

I guess any new process arriving late cannot aquire the (same) lock once the
first process has removed the name when the crowd has finished.
But as the remove itself locks, it means that the remove will happen only
after the lock has been released (requests being server FCFS (FIrst Come, First
Serviced).
If there's one process late, a new lock will be created, and likewise any new
arrivals will use that lock, until the lock is free.

Doesn't look like a 100% solution to me, but it might work. 

> 
> 
> Best regards,
> 
> Alex