On Mon, Oct 13, 2025 at 07:55:55PM +0100, Simon McVittie wrote: > There are several orthogonal advisory lock mechanisms, and I don't think > Policy should take a general position on which one should be used, as long > as all programs that might want to exclude each other by holding a lock can > agree on which one they are going to use. The ones I know about are: > > * flock(2) (POSIX) and its command-line interface flock(1) (util-linux)
s/POSIX/BSD/ And let's say, we already have the "policy" to use flock(2) in form of https://systemd.io/BLOCK_DEVICE_LOCKING/, just restricted to block devices. We really don't need to invent something new. > For example, when Flatpak wants to prevent a concurrent Flatpak process from > deleting a runtime that is in use by an app, it implements that by locking > the file ${runtime}/.ref with fcntl F_SETLK. It would be fine for a program > that interacts with Flatpak (or a newer version of Flatpak itself) to use > either F_SETLK or F_OFD_SETLCK on ${runtime}/.ref, because F_OFD_SETLCK is > documented to be mutually exclusive with an incompatible F_SETLK, but it > would be a potentialy serious bug for it to use flock(2), because it is > unspecified whether flock(2) and F_SETLK exclude each other (and on Linux > they don't, unless NFS happens to be involved). What flatpak does internally is of concern how? Do they document this as external usable lock, then they also need to specify which method is to be used. But this would be unrelated to the Debian policy. > According to #1110980 and #1110981, the FHS, which Policy incorporates by > reference, specifies the use of lock files in /var/lock/ for serial ports. More current versions removed /var/lock completely, so we can just update the reference: https://uapi-group.org/specifications/specs/linux_file_system_hierarchy/ Bastian -- Murder is contrary to the laws of man and God. -- M-5 Computer, "The Ultimate Computer", stardate 4731.3
