Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1261541 > unrolled thread

Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Thorsten Alteholz <debian@alteholz.de> - 2025-09-15 16:50 +0200
    Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Bdale Garbee <bdale@gag.com> - 2025-09-15 19:10 +0200
    Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Matthew Vernon <matthew@debian.org> - 2025-09-24 11:10 +0200
      Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Marco d'Itri <md@Linux.IT> - 2025-09-25 19:30 +0200
        Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Matthew Vernon <matthew@debian.org> - 2025-09-29 19:10 +0200
          Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981) Matthew Vernon <matthew@debian.org> - 2025-09-30 00:10 +0200
    Bug#1115317: call for votes Matthew Vernon <matthew@debian.org> - 2025-10-02 15:30 +0200
      Bug#1115317: call for votes Matthew Vernon <matthew@debian.org> - 2025-10-02 15:40 +0200
        Bug#1115317: call for votes Paul Tagliamonte <paultag@debian.org> - 2025-10-03 15:30 +0200
      Bug#1115317: call for votes Stefano Rivera <stefanor@debian.org> - 2025-10-04 18:00 +0200
      Bug#1115317: call for votes Timo Röhling <roehling@debian.org> - 2025-10-05 13:20 +0200
      Bug#1115317: call for votes Matthew Garrett <mjg59@srcf.ucam.org> - 2025-10-06 19:10 +0200
      Bug#1115317: call for votes Helmut Grohne <helmut@subdivi.de> - 2025-10-06 23:50 +0200
      Bug#1115317: call for votes Christoph Berg <myon@debian.org> - 2025-10-07 14:50 +0200
    Bug#1115317: call for votes Craig <csmall@debian.org> - 2025-10-06 23:00 +0200
      Bug#1115317: call for votes Matthew Vernon <matthew@debian.org> - 2025-10-06 23:30 +0200
    Bug#1115317: Technical Committee resolution on /var/lock and systemd Matthew Vernon <matthew@debian.org> - 2025-10-07 11:10 +0200
      Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Simon Josefsson <simon@josefsson.org> - 2025-10-07 14:00 +0200
        Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Santiago Vila <sanvila@debian.org> - 2025-10-07 14:30 +0200
        Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Helmut Grohne <helmut@subdivi.de> - 2025-10-07 19:30 +0200
          Bug#1115317: Technical Committee resolution on /var/lock and systemd Simon Josefsson <simon@josefsson.org> - 2025-10-07 19:30 +0200
        Bug#1110980: Bug#1115317: Technical Committee resolution on /var/lock and systemd Marco d'Itri <md@Linux.IT> - 2025-10-07 22:10 +0200

Page 1 of 2  [1] 2  Next page →

#1261541 — Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)

Package: tech-ctte
Severity: normal


Hi,

I am a bit stuck with #1110981 and need your advice on how to proceed.

Due to a change in systemd, the directory /run/lock is no longer world 
writable, but uucp uses this directory to create its lock files (as it is 
documented in FHS). As you can see in #1110981 there already is a 
complaint from a user that uucp no longer works.

The corresponding bug #1110980 in systemd was marked as "wontfix". So 
what do you recommend how to go on from here? Change Debian policy (as 
asked in #1111839), revert the change in systemd, find a Debian wide 
solution or let every package maintainer implement their own solution?

   Thorsten

Relevant bugs up to now:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110981
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110980
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111839

[toc] | [next] | [standalone]

#1261570

[Multipart message — attachments visible in raw view] — view raw

Thorsten Alteholz <debian@alteholz.de> writes:

> Due to a change in systemd, the directory /run/lock is no longer world 
> writable, but uucp uses this directory to create its lock files (as it is 
> documented in FHS). As you can see in #1110981 there already is a 
> complaint from a user that uucp no longer works.

Let me add a tiny but significant detail to this discussion.

While I haven't personally used all of uucp in quite some time (but am
pleased to see it having a resurgence of interest in the ham radio world
for store and forward messaging over HF digital radio links!), I use
'cu' almost constantly for interacting with embedded serial consoles on
devices a USB connection away from my laptop.

Having a change imposed by the systemd community cause 'cu' to break
with no warning was really frustrating.  My temporary "fix" was to
manually open up the permissions on /run/lock, which is clearly not the
right long term solution, so I look forward to your answer to Thorsten.

Regards,

Bdale

[toc] | [prev] | [next] | [standalone]

#1262999

Hello Systemd maintainers,

The fallout from #1110980 has reached the technical committee, where the 
changes to /run/lock permissions is causing problems for software that 
uses it for lock files per FHS.

I see from the upstream issue both that some of systemd upstream 
consider FHS obsolete; but they do also envisage that distributions that 
want to keep /run/lock FHS-compliant could choose to do so downstream of 
systemd.

It seems to me that Debian Policy requires FHS compliance in this 
regard; would you be amenable to reverting this change in systemd (to 
make it policy-compliant again) at least until we can come up with a 
transition plan, please?

I think in any case #1110980 should be reopened at severity serious 
until this is resolved - any objections?

Thanks,

Matthew

[toc] | [prev] | [next] | [standalone]

#1263257

[Multipart message — attachments visible in raw view] — view raw

On Sep 24, Matthew Vernon <matthew@debian.org> wrote:

>It seems to me that Debian Policy requires FHS compliance in this 
>regard; would you be amenable to reverting this change in systemd (to 
>make it policy-compliant again) at least until we can come up with a 
>transition plan, please?
As I mentioned in #1110980, I think that /var/lock/ should be writeable 
by group dialout (at least until a different locking scheme will be 
agreed project-wide) but we should not make it world writeable again for 
all the good reasons explained by Luca and the other systemd upstream 
maintainers.

(While this fixes cu it does not help uucico, but as a long time UUCP 
user I would be happy to work on moving the internal-use UUCP lock files 
if the maintainer needs help.)

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#1263832 — Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)

Hi,

At the last TC meeting we discussed this bug; I think our conclusion 
then was that systemd needs to comply with policy and thus FHS regarding 
/var/lock which still needs to be usable for serial device locks, and we 
talked about a couple of options for how bounded our decision should be. 
I was asked to draft a ballot.

Here's a draft - please LMK you're OK with it or propose amendments.

I think the "The TC is sympathetic to..." paragraph represents 
consensus, but if you'd like it to be ballot-optional, LMK.

===8<===
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.

0) 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.

1) This change to systemd must persist until a satisfactory migration of 
impacted software has occurred and Policy updated accordingly.

2) This change to systemd must persist until the TC allows otherwise, 
which the TC expects to do once a suitable transition plan has been agreed.

Ballot options:

A) Issue items 0 + 1
B) Issue items 0 + 2
N) Further discussion

===8<===

Thanks,

Matthew

[toc] | [prev] | [next] | [standalone]

#1263866 — Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)

Hi,

Following input on IRC, a revised draft, with an extra option "2", 
meaning the previous option "2" is now option "3". As previously, I'd 
appreciate "this ballot is OK" and/or suggested amendments.

===8<===
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.

0) 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.

1) This change to systemd must persist until a satisfactory migration of 
impacted software has occurred and Policy updated accordingly.

2) This change to systemd must persist until Policy has been updated to 
allow it

3) This change to systemd must persist until the TC allows otherwise, 
which the TC expects to do once a suitable transition plan has been agreed.

Ballot options:

A) Issue items 0 + 1
B) Issue items 0 + 2
C) Issue items 0 + 3
N) Further discussion

===8<===

[toc] | [prev] | [next] | [standalone]

#1264390 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

Hi,

I call for a vote on the following ballot (I fixed the grammar of
option 2, and renamed the none of the above option per constitution,
but this is otherwise as the last draft). The vote runs for a week, or
until the outcome is no longer in doubt.

Regards,

Matthew

=== BEGIN ===

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.

0) 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.

1) This change to systemd must persist until a satisfactory migration
of impacted software has occurred and Policy updated accordingly.

2) This change to systemd must persist until Policy has been updated
to allow otherwise.

3) This change to systemd must persist until the TC allows otherwise,
which the TC expects to do once a suitable transition plan has been
agreed.

Ballot options:

A) Issue items 0 + 1
B) Issue items 0 + 2
C) Issue items 0 + 3
N) None of the above

=== END ===

[toc] | [prev] | [next] | [standalone]

#1264392 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

Hi,

> === BEGIN ===
>
> 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.
>
> 0) 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.
>
> 1) This change to systemd must persist until a satisfactory migration
> of impacted software has occurred and Policy updated accordingly.
>
> 2) This change to systemd must persist until Policy has been updated
> to allow otherwise.
>
> 3) This change to systemd must persist until the TC allows otherwise,
> which the TC expects to do once a suitable transition plan has been
> agreed.
>
> Ballot options:
>
> A) Issue items 0 + 1
> B) Issue items 0 + 2
> C) Issue items 0 + 3
> N) None of the above
>
> === END ===

On the basis that I'd rather we just consider a transition plan than
have arguments about whether a particular proposal meets the terms of
a TC resolution, I vote:

C > A > B > N

Regards,

Matthew

[toc] | [prev] | [next] | [standalone]

#1264558 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

On Thu, Oct 02, 2025 at 02:31:15PM +0100, Matthew Vernon wrote:
>> 1) This change to systemd must persist until a satisfactory migration
>> of impacted software has occurred and Policy updated accordingly.
>>
>> 2) This change to systemd must persist until Policy has been updated
>> to allow otherwise.
>>
>> 3) This change to systemd must persist until the TC allows otherwise,
>> which the TC expects to do once a suitable transition plan has been
>> agreed.

The /var/lock change is a good change for us to target. We can't do it 
without coordinating a transition[1]. I look forward to this change
to the distro, and think it's a good thing for the ecosystem to move to.  
I'm happy to see this change in general.

Because I don't like the idea of TC being involved on an ongoing basis 
with implementation *and* transition, so i'd rather be clear on the 
acceptable end-state and let the project work it out - I vote:

A > C > B > N

[1]: The Release Team considers everything a transition where the upload 
      of a package requires changes (rebuilds or actual patches) to reverse 
      dependencies. (from https://wiki.debian.org/Teams/ReleaseTeam/Transitions)

-- 
   ⢀⣴⠾⠻⢶⣦⠀               Paul Tagliamonte <paultag>
   ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
   ⢿⡄⠘⠷⠚⠋        Debian, the universal operating system.
   ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3

[toc] | [prev] | [next] | [standalone]

#1264690 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

Hi Matthew (2025.10.02_14:57:12_+0200)
>=== BEGIN ===
>
>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.
>
>0) 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.
>
>1) This change to systemd must persist until a satisfactory migration
>of impacted software has occurred and Policy updated accordingly.
>
>2) This change to systemd must persist until Policy has been updated
>to allow otherwise.
>
>3) This change to systemd must persist until the TC allows otherwise,
>which the TC expects to do once a suitable transition plan has been
>agreed.
>
>Ballot options:
>
>A) Issue items 0 + 1
>B) Issue items 0 + 2
>C) Issue items 0 + 3
>N) None of the above
>
>=== END ===

I vote:

A > C > B > N

The change in systemd seems to be in the right direction, but some steps 
still need to be taken to get the project there. There is a transition 
that needs to be coordinated. So I support changing systemd to support 
the old style lock files until this transition is complete.

If we reach the point that policy has been updated, the transition is 
probably done. But I wouldn't want to put what's really a Release Team 
call onto the Policy Editors, so I prefer A to B. I'd rather it was our 
problem than the Plicy Editors, so I prefer C to B. I am comfortable in 
the non-specific project decision in A, so I rank it first.

I hope somebody will step up to coordinate this transition and get it 
done soon.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/

[toc] | [prev] | [next] | [standalone]

#1264778 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

Hi,

* Matthew Vernon <matthew@debian.org> [2025-10-02 13:57]:
>=== BEGIN ===
>
>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.
>
>0) 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.
>
>1) This change to systemd must persist until a satisfactory migration
>of impacted software has occurred and Policy updated accordingly.
>
>2) This change to systemd must persist until Policy has been updated
>to allow otherwise.
>
>3) This change to systemd must persist until the TC allows otherwise,
>which the TC expects to do once a suitable transition plan has been
>agreed.
>
>Ballot options:
>
>A) Issue items 0 + 1
>B) Issue items 0 + 2
>C) Issue items 0 + 3
>N) None of the above
>
>=== END ===

I vote

    A > C > B > N


I think it is important that the TC expresses clear expectations, and I
feel option B is too vague and implicitly asks the Policy editors to 
rule in our stead, which puts undue burden on them. I rate option A over 
option C because I'd rather see the usual Debian processes take over and 
not make the TC the defacto transition driver.


Cheers
Timo

-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#1265010 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

On Thu, Oct 02, 2025 at 01:57:12PM +0100, Matthew Vernon wrote:
> === BEGIN ===
> 
> 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.
> 
> 0) 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.
> 
> 1) This change to systemd must persist until a satisfactory migration
> of impacted software has occurred and Policy updated accordingly.
> 
> 2) This change to systemd must persist until Policy has been updated
> to allow otherwise.
> 
> 3) This change to systemd must persist until the TC allows otherwise,
> which the TC expects to do once a suitable transition plan has been
> agreed.
> 
> Ballot options:
> 
> A) Issue items 0 + 1
> B) Issue items 0 + 2
> C) Issue items 0 + 3
> N) None of the above
> 
> === END ===

I vote:

A > C > B > N

[toc] | [prev] | [next] | [standalone]

#1265047 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

On Thu, Oct 02, 2025 at 01:57:12PM +0100, Matthew Vernon wrote:
> === BEGIN ===
> 
> 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.
> 
> 0) 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.
> 
> 1) This change to systemd must persist until a satisfactory migration
> of impacted software has occurred and Policy updated accordingly.
> 
> 2) This change to systemd must persist until Policy has been updated
> to allow otherwise.
> 
> 3) This change to systemd must persist until the TC allows otherwise,
> which the TC expects to do once a suitable transition plan has been
> agreed.
> 
> Ballot options:
> 
> A) Issue items 0 + 1
> B) Issue items 0 + 2
> C) Issue items 0 + 3
> N) None of the above
> 
> === END ===

I vote C > B > A > N.

Rationale

We appear to have general consensus that flock-based locking is
technically superior and that we'd like it to be used. What we don't
quite agree yet is how to get there. The systemd approach has been to
deprecate and break the earlier locking scheme. As with other committee
members, I do not agree with that being a reasonable price to pay.
We're taking issue with how the transition is being done, not about the
direction of the transition.

The implied question here is whose responsibility it is to perform the
work required to get there. Answer A would practically require the
systemd maintainers to send a ton of patches for software half of which
we consider ready for a museum. I hope that we can find a solution where
the load can be shared in a better way. If that migration were to
happen, updating policy to match the status quo would usually be easy,
so B offers more ways to fulfil the imposed requirement than A. I favor
option C, because I expect it to put the least work on systemd
maintainers. Even though this causes the matter to go through the
committee again, it provides a pretty clear path that should leave few
disputes and misunderstandings behind. I caution that putting up higher
standards for a transition plan than we apply to other transitions would
not be reasonable. For instance, requiring a detailed schedule far in
the future would appear unwarranted to me. On the flip side, an estimate
of which packages are affected is something we'd probably want here.

Helmut

[toc] | [prev] | [next] | [standalone]

#1265114 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

> === BEGIN ===
> Ballot options:
> 
> A) Issue items 0 + 1
> B) Issue items 0 + 2
> C) Issue items 0 + 3
> N) None of the above
> 
> === END ===

Sorry for being late, I was called on a surprise business trip for
all of last week until today.

FTR, I agree with overriding the systemd maintainer(s) here.

A = B = C > N

Christoph

[toc] | [prev] | [next] | [standalone]

#1265039 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

I vote,

A > C > B > N

The newer locking method is way better but we cannot strand programs
that use it. I'd strongly suggest they do move to flock though.

Such change needs a careful transistion plan as part of the whole
point is for different programs to know if the device is in use.

[toc] | [prev] | [next] | [standalone]

#1265044 — Bug#1115317: call for votes

[Multipart message — attachments visible in raw view] — view raw

Hi,

The outcome is no longer in doubt, the winner is:
A) Issue items 0 + 1

The Technical Committee resolves as follows:

=== BEGIN ===

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.

=== END ===

Regards,

Matthew

[toc] | [prev] | [next] | [standalone]

#1265096 — 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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Matthew Vernon <matthew@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#1265111 — Bug#1110980: 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.

[toc] | [prev] | [next] | [standalone]

#1265135 — Bug#1110980: 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/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.

> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web