Re: Transitioning from existence-based lockfiles and /var/lock to flock
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
Reply to: