LWN: Comments on "Debian Technical Committee overrides systemd change" https://lwn.net/Articles/1041316/ This is a special feed containing comments posted to the individual LWN article titled "Debian Technical Committee overrides systemd change". en-us Wed, 15 Oct 2025 04:08:04 +0000 Wed, 15 Oct 2025 04:08:04 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Why was this a policy debate at all? https://lwn.net/Articles/1041981/ https://lwn.net/Articles/1041981/ mjg59 <div class="FormattedComment"> There's no requirement on upstream systemd at all - this is purely about how it's packaged in Debian.<br> </div> Wed, 15 Oct 2025 04:01:12 +0000 Why was this a policy debate at all? https://lwn.net/Articles/1041978/ https://lwn.net/Articles/1041978/ raven667 <div class="FormattedComment"> I am going to reiterate what others have said, it seems like having this hardcoded in systemd is not required and the technical mechanism which creates /var/lock -&gt; /run/lock is entirely a matter of configuration, fully supported by systemd without hardcoding anything, using systemd-tmpfiles. I'm fine with removing this from the main systemd software and leaving it up to local configuration, systemd is used on all sorts of different systems, not just servers/desktops which care about FHS, and having only the parts which are necessary for systemd to function hardcoded makes sense to me, leave everything else up to config. It seems like nothing needs to be reverted in systemd, unless the goal is not technical but social to prove that Debian can *make* the systemd project do/notdo something, if you can just drop a tmpfiles config in the package. Am I missing something, or does that about sum it up? <br> </div> Wed, 15 Oct 2025 03:49:28 +0000 Why not a separate tmpfs? https://lwn.net/Articles/1041976/ https://lwn.net/Articles/1041976/ lutchann <div class="FormattedComment"> I get that sometimes you have to agitate to move things forward, but I feel like the discussion could have acknowledged the history of the issue with more honesty.<br> </div> Wed, 15 Oct 2025 03:19:29 +0000 Progress with a Plan https://lwn.net/Articles/1041975/ https://lwn.net/Articles/1041975/ josh <div class="FormattedComment"> No, it works in any of the possible orderings: <br> <p> 1) Modern flock, modern traditional lock, legacy traditional lock: The modern program has the lock, the legacy program waits until the modern program is done.<br> <p> 2) Modern flock, legacy traditional lock, modern traditional lock: the legacy program has the lock, the modern program is waiting on the traditional lock before it can run.<br> <p> 3) Legacy traditional lock, modern flock, modern traditional lock: The legacy program has the lock, the modern program is waiting on the traditional lock before it can run.<br> </div> Wed, 15 Oct 2025 03:12:42 +0000 Progress with a Plan https://lwn.net/Articles/1041969/ https://lwn.net/Articles/1041969/ Hello71 <div class="FormattedComment"> your algorithm only works if the modern program is started after the legacy program. in the reverse order, they will both obtain the lock.<br> </div> Wed, 15 Oct 2025 02:38:19 +0000 Why not a separate tmpfs? https://lwn.net/Articles/1041948/ https://lwn.net/Articles/1041948/ fw <div class="FormattedComment"> This was what Debian had before: <a href="https://salsa.debian.org/systemd-team/systemd/-/commit/7ef47f9f6b09eb981cbcd0d7514b6793702ab8a8">https://salsa.debian.org/systemd-team/systemd/-/commit/7e...</a><br> <p> The revert did not bring back the separate mount point, though: <a href="https://salsa.debian.org/systemd-team/systemd/-/commit/9250e242b9b764b3aa54aa3af77da1753a5e67d0">https://salsa.debian.org/systemd-team/systemd/-/commit/92...</a><br> <p> I don't know why things are done this way.<br> </div> Tue, 14 Oct 2025 20:46:23 +0000 Single partition setups https://lwn.net/Articles/1041861/ https://lwn.net/Articles/1041861/ Jonno <div class="FormattedComment"> On my Debian oldstable system /run/lock is a tmpfs separate from /run, and limited to 5 MiB (i.e. mounted with -O "nosuid,nodev,noexec,size=5120k"), which to my mind solves the DoS concerns (as at least only programs using /run/lock are affected, not any other program using /run). I didn't do anything special to get this, so I'm not sure where it comes from, but somehow reverting to this behaviour sound reasonable to me.<br> <p> And if there is any problematic tmpfs mount in your typical Linux system it would be /dev/shm, as it has the same fs permissions, but mounted without noexec or any significant size restriction...<br> </div> Tue, 14 Oct 2025 12:38:38 +0000 Why not a separate tmpfs? https://lwn.net/Articles/1041862/ https://lwn.net/Articles/1041862/ gray_-_wolf <div class="FormattedComment"> If the worries are non-priviledged programs filling up /run, why just not make /run/lock a separate tmpfs, with reasonable size limits? Should that not protect against the inodes and space exhaustion while being significantly less nuclear option?<br> </div> Tue, 14 Oct 2025 12:27:57 +0000 Quota? https://lwn.net/Articles/1041858/ https://lwn.net/Articles/1041858/ eru <blockquote> shudder to think of allowing unprivileged programs to fill up a directory </blockquote> <p> Wouldn't setting a quota for /run/lock be a solution to this concern? Same for other shared directories for temporaries. Tue, 14 Oct 2025 12:16:26 +0000 Single partition setups https://lwn.net/Articles/1041853/ https://lwn.net/Articles/1041853/ aragilar <div class="FormattedComment"> Same on my Debian systems (with / and /home being different partitions on lvm, which I think is the default, or at least one of the suggested options?).<br> </div> Tue, 14 Oct 2025 11:14:03 +0000 Single partition setups https://lwn.net/Articles/1041846/ https://lwn.net/Articles/1041846/ rgb <div class="FormattedComment"> On my NixOS setup only /run/keys is ramfs, but good point anyhow.<br> </div> Tue, 14 Oct 2025 09:27:44 +0000 Single partition setups https://lwn.net/Articles/1041845/ https://lwn.net/Articles/1041845/ MaZe <div class="FormattedComment"> I believe nowadays stuff like this has a tendency to be a dedicated tmpfs mountpoint.<br> At least on my Fedora, /var/lock is -&gt; /run/lock, and /run is tmpfs.<br> </div> Tue, 14 Oct 2025 07:59:27 +0000 Single partition setups https://lwn.net/Articles/1041844/ https://lwn.net/Articles/1041844/ rgb <div class="FormattedComment"> Aren't now most systems installed with a single unified partition by default anyway, in which case making /var/lock read-only for general users isn't really helping anything at all? Having a reserved disk quota for root should be much more effective. Looks like a storm in a theoretical teacup. But I guess you have to start somewhere.<br> </div> Tue, 14 Oct 2025 07:36:06 +0000 New Package https://lwn.net/Articles/1041843/ https://lwn.net/Articles/1041843/ stephanlachnit <div class="FormattedComment"> I am a bit surprised why introducing a new package which contains the new tmpfiles config file? Then uucp et al can just depend on it and it can be gradually tackled without impacting the systemd package.<br> </div> Tue, 14 Oct 2025 06:59:07 +0000 Re: Progress with a Plan https://lwn.net/Articles/1041839/ https://lwn.net/Articles/1041839/ notriddle <div class="FormattedComment"> <span class="QuotedText">&gt; You can't really plan around people who are doing their own thing and throwing opaque blobs over the wall every so often.</span><br> <p> You can, but you end up heavily limiting the amount of shared data that different subsystems/services/apps can see. Mere blocking isn't enough, because (1) this tends to result in systems that don't work when the permission is turned off, because that code path isn't tested (2) the existence of the file might be sensitive information in and of itself (3) what happens if two systems both think they should be able to use the same name for their things?<br> <p> This also means any change of behavior that's visible to the blob has to be opt-in.<br> <p> That's not how UNIX was designed. That's not even how Windows was designed, though MS has haphazardly added application-level namespacing features to patch around specific, widespread breakages. Hardened web browsers like Tor actually go in the right direction, but they only try to protect sites from each other: new APIs provided by the browser itself are dumped directly into the global namespace, and though they avoid adding anything that will cause widespread breakage, it's still possible for new browser-provided APIs to break a site by existing.<br> <p> Other than hardware virtualization systems like MAME, does anything actually do better on backwards compat than web browsers?<br> </div> Tue, 14 Oct 2025 05:02:02 +0000 Progress with a Plan https://lwn.net/Articles/1041837/ https://lwn.net/Articles/1041837/ josh <div class="FormattedComment"> For any software that can be modified, bridging the two is as simple as "do both, in a well-defined order, to be compatible with software that hasn't yet transitioned to flock; if you can't get the traditional lock because it's taken, handle that as the lock being held; if you can't get the traditional lock because you don't have permission to the directory, ignore it".<br> </div> Tue, 14 Oct 2025 01:32:08 +0000 Progress with a Plan https://lwn.net/Articles/1041836/ https://lwn.net/Articles/1041836/ mjg59 <div class="FormattedComment"> It's more complicated than that - the issue includes different apps trying to access the serial port. If app A locks using flock() and app B locks using /run/lock then both can try accessing the port simultaneously. Bridging the two probably involves making it be a FUSE filesystem that then flock()s the right thing.<br> </div> Tue, 14 Oct 2025 01:25:18 +0000 Progress with a Plan https://lwn.net/Articles/1041834/ https://lwn.net/Articles/1041834/ smurf <div class="FormattedComment"> That would be too easy, apparently.<br> </div> Tue, 14 Oct 2025 00:41:09 +0000 What is the actual technical solution here? https://lwn.net/Articles/1041829/ https://lwn.net/Articles/1041829/ mjg59 <div class="FormattedComment"> The decision was around policy rather than mechanism - the maintainers are free to achieve the outcome through any technical approach they want.<br> </div> Mon, 13 Oct 2025 22:38:04 +0000 What is the actual technical solution here? https://lwn.net/Articles/1041828/ https://lwn.net/Articles/1041828/ skissane <div class="FormattedComment"> I'm assuming it is just going to be that when Debian packages systemd, they add a /etc/tmpfiles.d config by default to restore world-writeable /run/lock?<br> <p> Maybe I'm reading it wrong, but I came away from this article unclear what the final decision was.<br> </div> Mon, 13 Oct 2025 22:22:43 +0000 Progress with a Plan https://lwn.net/Articles/1041824/ https://lwn.net/Articles/1041824/ tux3 <div class="FormattedComment"> Well, beyond the specifics of this particular systemd change, are those binary-only packages part of the OS, or do they come from an external vendor?<br> If you get updates from your third-party vendor, I suppose you'd talk to them to learn what the plan is.<br> More times than I'd like I've been held back from updating the distribution for the sake of enterprise-quality vendor tools.<br> <p> There are also historical artifacts that don't receive updates, don't have a source to patch, and don't have a community fixing the binary directly. The kernel doesn't break those too often, so for containers have worked nicely, as a little time capsule.<br> <p> But third-party binaries aren't really participating in this whole free software distribution project. You can't really plan around people who are doing their own thing and throwing opaque blobs over the wall every so often.<br> </div> Mon, 13 Oct 2025 21:58:05 +0000 Progress with a Plan https://lwn.net/Articles/1041826/ https://lwn.net/Articles/1041826/ edgewood <div class="FormattedComment"> Perhaps to document how to add "a configuration file in /etc/tmpfiles.d to override systemd's defaults and create the directory with the desired permissions“.<br> <p> There's a difference between slowing down a reasonable change to give open source programs a chance to get updates and never making it because closed source programs can't update.<br> </div> Mon, 13 Oct 2025 21:49:24 +0000 Progress with a Plan https://lwn.net/Articles/1041825/ https://lwn.net/Articles/1041825/ dmv <div class="FormattedComment"> Yeah, honestly, when I read the title, I was thinking oh Lord, what drama is brewing in Debian-land now? But reading the story, it all looks fairly reasonable from both sides. And it’s a good example, I think, of how the infamously clunky bureaucratic processes of Debian align with and reinforce what makes Debian unique: its insistence on democratic processes, even where it would’ve been easier just to steamroll systemd packaging here (note the comment at the end in response to that question: because that’s now how things are supposed to work here). I know there are 1 million complaints, including from people who have deeply contributed to Debian and then become disillusioned with its processes, but I think this shows them in a good light. <br> </div> Mon, 13 Oct 2025 21:38:06 +0000 Progress with a Plan https://lwn.net/Articles/1041816/ https://lwn.net/Articles/1041816/ mb <div class="FormattedComment"> <span class="QuotedText">&gt;fix for users now</span><br> <p> That is not possible for users without source code.<br> What is your plan for those?<br> </div> Mon, 13 Oct 2025 20:49:22 +0000 Progress with a Plan https://lwn.net/Articles/1041812/ https://lwn.net/Articles/1041812/ honschu <div class="FormattedComment"> Yes, systemd wants to move ahead. Yes, tools still rely on FHS. Breakage hurts and legacy drags - let's stay connected through the shared aim of a great OS: fix for users now, publish a plan, and phase out UUCP-style locking cleanly.<br> </div> Mon, 13 Oct 2025 19:34:19 +0000