* 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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
