Re: [systemd-devel] Antw: Re: Mutually exclusive (timer-triggered) services
Am 17.10.19 um 08:02 schrieb Ulrich Windl: >> 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. it's about *multiple* services and hence might not work it's the same as wenn you "tail -f" a logfile while in the meantime logrotate came, tail follows the old file with no further changes, the disk space is not freed because the open handlebut the rest of the world don#t care and is using the new one ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Mutually exclusive (timer-triggered) services
>>> Alexander Koch schrieb am 16.10.2019 um 16:14 in Nachricht <9fb9c1a157e92baef1107ed3b66aa...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Mutually exclusive (timer-triggered) services
* 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
