Bug#1115317: Technical Committee resolution on /var/lock and systemd
On Tue, Oct 07, 2025 at 01:54:10PM +0200, Simon Josefsson wrote: > I agree with everything in your e-mail, but it seems entirely possible > to reach the same goal by having /var/lock be "owned" by some other > package instead of systemd, which apparently have little interest to > support /var/lock. I can sympathise with systemd upstream on that, and > their desire to drop everything about /var/lock. Moving ownership of > /var/lock to another package, e.g., a NEW 'var-lock' package, may be a > friendlier way forward to everyone. > > Is there a reason the /var/lock directory MUST be provided by systemd > and no other package could provide it? > > Then all packages that need /var/lock in Debian can depend on this > 'var-lock' package, which would also allow us to better track which > packages still use this suboptimal interface for device locking. Or > just move the directory to 'base-files' or similar. Please note that /var/lock is just a symlink to /run/lock, and both base-files and systemd agree that such symlink should exist (even if their implementation differ a little). Since /run/lock is volatile, base-files is a bad place to keep the real directory. Thanks.
Bug#1115317: Technical Committee resolution on /var/lock and systemd
Matthew Vernon writes: > The TC therefore resolves that systemd shall provide /var/lock with > relaxed enough permissions that existing Debian software that uses > /var/lock for system-wide locks of serial devices (and similar > purposes) works again. Has it been discussed that /var/lock could be provided by some other package than systemd? I agree with everything in your e-mail, but it seems entirely possible to reach the same goal by having /var/lock be "owned" by some other package instead of systemd, which apparently have little interest to support /var/lock. I can sympathise with systemd upstream on that, and their desire to drop everything about /var/lock. Moving ownership of /var/lock to another package, e.g., a NEW 'var-lock' package, may be a friendlier way forward to everyone. Is there a reason the /var/lock directory MUST be provided by systemd and no other package could provide it? Then all packages that need /var/lock in Debian can depend on this 'var-lock' package, which would also allow us to better track which packages still use this suboptimal interface for device locking. Or just move the directory to 'base-files' or similar. Just an idea, /Simon signature.asc Description: PGP signature
Bug#1115317: Technical Committee resolution on /var/lock and systemd
On Oct 07, Simon Josefsson wrote: Has it been discussed that /var/lock could be provided by some other package than systemd? Of course. But base-files is the only package in which it would make sense to do this, and since the base-files maintainer disagrees then the only other option would be to introduce a new package and make all packages which may use serial devices depend on it. Since this would be significant work for the maintainers of Debian packages and still not solve the problem for third party packages then I quickly decided that it would be a pointless waste of time and resources. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1115317: Technical Committee resolution on /var/lock and systemd
Am 07.10.25 um 14:46 schrieb Henrik Ahlgren: Simon Josefsson writes: Then all packages that need /var/lock in Debian can depend on this 'var-lock' package, which would also allow us to better track which packages still use this suboptimal interface for device locking. Or just move the directory to 'base-files' or similar. /var/lock is already owned by base-files, and it is a symlink pointing to /run/lock, which is created by systemd (/usr/lib/tmpfiles.d/debian.conf). Systemd also has has a tmpfiles.d snipped called legacy.conf that attempt to create a relative symlink: d /run/lock 0755 root root - L /var/lock - - - - ../run/lock Since tmpfiles.d/debian.conf already has an entry for /run/lock, systemd-tmpfiles-setup.service complains: Oct 05 23:15:18 noux systemd-tmpfiles[689]: /usr/lib/tmpfiles.d/legacy.conf:14: Duplicate line for path "/run/lock", ignoring. As former systemd maintainer I want to provide some further details: /var/lock being a symlink to /run/lock is an important detail. Simply making /run/lock writable by arbitrary users or programs opens up /run (which is memory based) to DoS, so this should be avoided. In the past, /run/lock was a separate tmpfs with pretty tight memory constraints (it could only take up to 5 MB). This was a Debian specific patch which made /run/lock an "API fs", i.e. it was one of the first actions systemd did when starting up, i.e. it was basically available during the complete run-time of the system. It was implemented via [0] bluca dropped this patch and turned this into a run-lock.mount unit in [1]. This has the downside, that the /run/lock tmpfs is mounted much later during the boot process, so services needed to declare an explicit ordering against run-lock.mount if they needed that directory. It also didn't account for processes that were spawned by users, i.e. by interactive shells and also cron like stuff. bluca dropped this run-lock.mount unit in [2]. Given the ctte ruling, I would like to see /run/lock being a separate tmpfs again until all software requiring it has been updated. Michael [0] https://salsa.debian.org/systemd-team/systemd/-/blob/debian/bookworm/debian/patches/debian/Make-run-lock-tmpfs-an-API-fs.patch?ref_type=heads [1] https://salsa.debian.org/systemd-team/systemd/-/commit/d3f9a1f928a9f8ae6d917ec06cff651a03dfb8dc [2] https://salsa.debian.org/systemd-team/systemd/-/commit/7ef47f9f6b09eb981cbcd0d7514b6793702ab8a8 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1115317: Technical Committee resolution on /var/lock and systemd
unarchive 1110980 reopen 1110980 severity 1110980 important tags 1110980 - wontfix block 1115317 by 1110980 quit Hi, In #1115317, the Technical Committee (TC) was asked about the future of /var/lock, following a systemd upload which made this directory only writable by root. Bug #1110980 was opened against systemd, pointing out that FHS (and thus Debian Policy) has /var/lock as the standard interface for system-wide locks of serial devices and similar. In the upstream discussion of the issue ( https://github.com/systemd/systemd/issues/38563 ) the systemd authors declined to remain FHS-compliant, but rather noted that downstream distributions might wish to arrange for systemd to create /var/lock with appropriate permissions if they wish to. Nevertheless, #1110980 was closed "wontfix". The TC is sympathetic to the argument that flock(2) is a superior locking mechanism, and that an end-state where all existing software that still uses locks in /var/lock is migrated to using flock(2) instead would be desirable. The Technical Committee notes that an important part of the role of a Debian Developer is ensuring that software in Debian complies with Debian Policy. That a particular upstream is not interested in FHS compliance is not a sufficient reason for a Debian package to disregard the FHS as it is incorporated into Debian Policy. The TC therefore resolves that systemd shall provide /var/lock with relaxed enough permissions that existing Debian software that uses /var/lock for system-wide locks of serial devices (and similar purposes) works again. The TC exercises its power under constitution #6.1.4 to overrule the systemd maintainers in this regard. This change to systemd must persist until a satisfactory migration of impacted software has occurred and Policy updated accordingly. Thanks, Matthew, for the Technical Committee
Bug#1115317: Technical Committee resolution on /var/lock and systemd
Hi Simon, On Tue, Oct 07, 2025 at 01:54:10PM +0200, Simon Josefsson wrote: > Has it been discussed that /var/lock could be provided by some other > package than systemd? Technically speaking, /var/lock is owned by base-files. It is a symbolic link pointing to /run/lock. So let's pretend you really asked about /run/lock instead. > 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/lock1777 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. > Then all packages that need /var/lock in Debian can depend on this > 'var-lock' package, which would also allow us to better track which > packages still use this suboptimal interface for device locking. Or > just move the directory to 'base-files' or similar. I relate to the idea of only installing a permissive /run/lock when there is a package that actually benefits from it. Keep in mind though that what is being objected here is not the change itself, but the way it is being done. Once said package exists and policy is updated to document the additional dependency needed for obtaining FHS semantics, systemd can go back to its restrictive /run/lock permission. We hope that a solution is being found and that the requested reversion is of temporary nature without imposing what that solution is. 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. Helmut
Bug#1115317: Technical Committee resolution on /var/lock and systemd
Helmut Grohne 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/lock1777 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 Description: PGP signature
