Bug#1115317: Technical Committee resolution on /var/lock and systemd

Simon Josefsson <[email protected]> Tue, 07 Oct 2025 19:24:37 +0200

Newsgroups	gmane.linux.debian.devel.ctte
Message-ID	<87h5wasjze.fsf__45930.7596249104$1759858063$gmane$org@josefsson.org>

Helmut Grohne <[email protected]> writes:

>> Is there a reason the /var/lock directory MUST be provided by systemd
>> and no other package could provide it?
>
> systemd used to install /usr/lib/tmpfiles.d/debian.conf with a line
>
>     d /run/lock    1777 root root -   -
>
> overriding the systemd upstream configuration
> /usr/lib/tmpfiles.d/legacy.conf containing
>
>     d /run/lock 0755 root root -
>
> as the earlier lexicographical occurrence takes precedence. We could
> have a file /usr/lib/tmpfiles.d/fhs_run_lock.conf adding this back and
> it could also be installed by a different package, so yeah what you're
> proposing could be a middle ground.

Thanks for explaining!  Okay if this is just a one-line snippet, it
seems like a lot of work, but good to know it is feasible.

> Also keep in mind that we cannot just move packages from /var/lock based
> locking to flock() based locking one at a time. If two different
> packages compete about a device and they use different locking schemes,
> they'll both think they had exclusive access. Going for flock()
> practically needs to be a flag-day transition where all packages are
> updated at roughly the same time.

That seems like an archeological excursion, and I'm not sure it is the
best use of everyone's time...  maybe some other catch-all approach
could be designed to detect when two applications are using the same
device and deal with the lock problem.

Or merely give up and document that for a (possibly indefinite)
transition period, locking will be broken and users needs to take care
of this problem themselves.  This would allow partial and incremental
migrations towards flock() until all application are updated.

/Simon

signature.asc (application/pgp-signature, 1.2 KB)