The state of systemd: 2026 edition

At the 2026 All Systems Go! conference, systemd maintainers Luca Boccassi and Zbigniew Jędrzejewski-Szmek delivered the traditional "state of the project" session with an overview of the systemd project's accomplishments in the past year. That was followed by a maintainer round table where Boccassi, Jędrzejewski-Szmek, Daan De Meyer, and project leader Lennart Poettering fielded questions about systemd's size, health, and if it might replace Kubernetes. (It will not.)

I did not attend the All Systems Go! conference this year, but I watched the videos of the sessions after they were published. The "systemd: state of the project" and "systemd: round table" recordings are available in multiple video and audio-only formats via the Chaos Computer Club's media archive. The slides for the "systemd: state of the project" talk are also available.

Boccassi began by thanking Software in the Public Interest (SPI) for handling systemd's "financial and legal stuff", and mentioned that he sends SPI an annual report with information about the project's major releases, number of contributors, and so forth. In 2025, that worked out to two major systemd releases (v258 and v259), and 40 point releases. The project merged 6,160 commits from 379 contributors in 2025, which is down from 7,372 in 2024. He said that the project has already received contributions from 480 people by the end of September. The increased number of contributors, he said, is largely the result of people using LLM coding tools.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

The systemd v258 release took about nine months of development. Boccassi said that "everybody was unhappy" with the long release cycles, so the project decided to try to do a release every quarter. "We have two months of merging features and then one month of stabilization and release candidates." He said that the project did not always hit the exact calendar date it planned for a release but it was within a week or so each time. So far there have been three major systemd releases in 2026 (v260, v261, and v262). "It's more like herding cats than release engineering, but it is working so far and everybody seems to be happy with this. So we try to keep this fixed cadence. It's better for developers, for maintainers, for distributions, and consumers as well."

Smurf village

He noted that systemd had recently codified its governance: the document is fairly brief with only six short rules as well as a list of the project's current maintainers, and its project leader (Poettering, of course). Boccassi summarized the project's governance by saying that "it pretty much works like the Smurf's village. So we have Papa Smurf in charge, and then [the maintainers] more or less are a collective, making decisions, merging PRs and so on and so forth".

Jędrzejewski-Szmek displayed graphs of the project's GitHub issues and pull requests since 2016. He explained that the rate of issues being opened was accelerating, and if it kept up the project would face a large number of unresolved open issues. "We're currently at 3,000 [open issues]. This is already too much to have a handle on. So I don't know. This is not great."

The same pattern was emerging with pull requests. He said that the project had been doing well at keeping up with those requests until the middle of 2025. It was now starting to become overwhelmed due to what he called the AI revolution. "Now we are seeing exponential growth here, and if this continues, then we will just stop reviewing and processing pull requests, and I don't think that this can go on". The pace of merging commits into the code base, however, was more or less constant. "Nothing seems to influence the pace of commits to the systemd repo much. My hypothesis is that the number of people actually reviewing things hasn't changed that much, so this is why the pace of merging is constant". If the project was going to increase capacity, it would need to change its process or increase the number of people working on reviews.

Boccassi sped through a slide related to the continuous-integration changes that systemd had made in the past year or so. He noted that the project had added more test coverage for the ARMv7 architecture, as well as build tests for RISC-V. "Not unit tests, just build tests, because emulation is still too slow. Hopefully in the future it will get better."

The project has also added the ability for a maintainer to build systemd packages based on a pull request using the Open Build Service (OBS). "This is useful in case someone opens an issue but is not a technical person, so someone else can open a PR and then can tell them, 'Hey, go and install these packages from this repository that is specific to the PR,' and then they can then test it." The project also continues to make up-to-date packages available via OBS from its main branch, or from the the latest stable release, for Arch Linux, Debian, Fedora, openSUSE, and Ubuntu.

Security

Germany's Sovereign Tech Agency (STA) awarded a commission in 2025 to the systemd project of nearly €400,000 for improving its security and infrastructure. Boccassi said that the focus of the commission was in part to help improve integration between GNOME and systemd-managed home directories, improving the systemd OS installer, as well as systemd's system-update service. He did not go into much detail about these features, but Julian Sparber did give a talk on the systemd OS installer, and Dhanuka Warusadura gave a presentation on STA-funded work toward extending systemd-homed.

The STA has also funded a security bug-bounty program through the YesWeHack platform. Boccassi said that the project had to close the program to new submissions "because we had too many submissions and the triagers just did not have time to process them". He hoped they would be reopening submissions soon. Again, the influx of reports was due to LLM-assisted bug finding; he said the results were "not great". There were 183 reports opened, and only 13 were accepted. A total of 168 were closed as invalid, duplicates of other bugs, or out of scope. Two were still under review at the time of the talk. In total, the project awarded €21,250 through the bounty program.

The systemd project had recently updated its security policy, he said, and prefers to receive security reports through a process on GitHub. He said that systemd had received 62 reports via GitHub and had published 15 advisories so far. "So the signal-to-noise ratio is better here. I guess because you don't get paid for this."

In addition, systemd officially became a CVE Numbering Authority (CNA) in June; since then, he said, it had published two CVEs and rejected one. Boccassi explained that systemd would only publish CVEs for "the really high-priority stuff". When a CVE is issued "all the downstreams have to scramble and do a lot of work", so the project would only issue CVEs when the vulnerability was considered high severity and a CVE was necessary.

Release highlights

Boccassi said that he would run through a few of the interesting features from systemd releases of the past year, though he recommended following Poettering's Mastodon account for his posts about systemd releases. With systemd v259, the project converted most of its runtime dependencies to use dlopen() instead of explicit shared-library linking, and completed the process of converting dependencies in v260. Boccassi said that systemd now only depends directly on the GNU C Library. "We have no more fixed linked-in dependencies. We still have 20-odd optional dependencies, and they are all [opened] at runtime only when a feature actually requires it." That means that distributors can compile all of the optional features with external dependencies without having a large systemd binaries by default. "So you can have a single build, fully featured, and then decide in your image if you want to have the libraries or not." This was also important for security, he said, in reference to the role that library linking played in the XZ backdoor.

Boccassi noted that De Meyer added an --empower option to the run0 command, which is an alternative to sudo, in systemd v259. That option, he explained, allows users to escalate their privileges to become "almost root, pretty much root, but not UID 0". This means that users can, for example, run processes with root's privileges, but files would be created with the user's UID and GID. He also credited De Meyer with implementing a feature that allows per-user instances of systemd-machined, which enables unprivileged users to run virtual machines and containers using systemd.

Varlink is an interprocess communication (IPC) protocol that serves as an alternative to D-Bus. LWN covered varlink in 2018, not long after it was announced. In v260, systemd added the varlink registry as a way to discover which varlink-enabled services are available on a system. Poettering described the registry in more detail on Mastodon ahead of the v260 release. Boccassi also mentioned the metrics and reports subsystem that was added in v260 as a way to extract signed reports from a system.

Systemd added systemd-imds in v261, which provides support for acquiring data from a cloud provider's instance-metadata service (IMDS). This, Boccassi said, was basically systemd's replacement for cloud-init, which has been a standard for doing initial setup for instances running in the cloud. "Nobody seems to like cloud-init, so we now have a replacement for that."

In v262, Boccassi added a feature that he had wanted for a long time: the ability to enqueue more than one job at a time. Prior to that release, if a user started multiple jobs with a command like this

    # systemctl start a.service b.service

it would result in two EnqueueUnitJob() D-Bus IPC calls, which could lead to "a set of race conditions and nastiness". With v262, systemd now has the EnqueueUnitJobMany() API for D-Bus and varlink. "This lets you enqueue as many jobs as you want in a single IPC call, so that you can start, stop, or restart as many units as you want and guarantee that they are part of a single transaction in the manager."

Questions

Rather than taking questions during the state of systemd talk, Boccassi suggested that the audience use the maintainer round table session immediately afterward. The first question during that session was whether the maintainers had considered extending systemd to become a Kubernetes replacement and allowing it to manage not only jobs on a local system, but remote systems as well.

Poettering said that he did not think that systemd was the right component for that. "I think systemd is inherently the thing that manages the node. It's not the thing that orchestrates the node." He added that systemd-report was a way that an orchestrator could get a pretty good idea of a system's state and then make decisions based on that, but he did not think that orchestration belonged in systemd. "It's systemd's job to make this possible and provide the right tools for this. But the orchestrator—scheduling and stuff—I don't think that's systemd stuff."

Instead of extending systemd's remit to replacing Kubernetes, another audience member wanted to talk about size constraints: "Coming from the embedded world, where every byte of flash is valued in gold, we've seen an increase in the flash footprint with each systemd version. Is that something you take into consideration when developing new [features]?"

Jędrzejewski-Szmek thought that systemd was doing pretty well in that department: "While it is true that the code in systemd is growing, we are doing much better at making dependencies optional, which are actually bigger than systemd itself." Poettering said that keeping systemd's footprint small was important, which was why using Rust for systemd would be complicated because the Rust ecosystem lacked a philosophy of "trying to have dependencies that are dynamic and optional and gracefully degrading, and not having everything in one massive binary requiring everybody to compile everything". He and Boccassi supplied examples of recent features, such as systemd-report and systemd-imds, which were entirely optional. If they were not enabled, then there was no price to pay in terms of footprint.

Another audience member followed the growing footprint theme with an observation that with all the tools systemd is adding, "it's really becoming an ecosystem". He wanted to know when it was enough. "We keep adding more and more and more to the point that now systemd can do, I don't know, Kubernetes and all kinds of stuff". Boccassi retorted, "I think as long as nobody takes away Lennart's GitHub account, we'll keep adding".

Poettering said it was an absolutely valid question, and had been since day one. "Where do we draw the line? Frankly, the line has been moved. But if you ask me right now, it's the most basic stuff to keep a node running. But the simple fact of life is that what that basic stuff is, is changing. Right?" He referenced platform integrity; ten years ago, he said, that was not a thing. Now, however, it's "absolutely fundamental to OS design" and there was nowhere else he thought it could be implemented.

After some discussion and cross-talk, he added that the same question could apply to the Linux kernel and other projects. "The kernel nowadays has user-space tools and stuff like this in the repository, right? Where does it end? Where does it start? Like, we have a rough idea, but this rough idea is going to change over time, right?"

Continuing on the theme of scope of systemd, a question came up about the project's ability to maintain systemd's various components. "Do you see any particular components that have a particular lack in maintainers, and certain components which are much better maintained, and much better supported in terms of review and that sort of thing?" Poettering said that one of the reasons that the project tends to add features to systemd is that maintenance becomes easier. "If we fix something that is broken and it touches multiple modules, we tend to patch through the modules to update them". He added that the systemd governance document assigns maintainers to a few of the project's components, and everything else "basically has everybody as maintainers".

There are areas that receive more or less attention, he acknowledged, because priorities change over time. Poettering co-founded Amutable, which was announced in January this year, so his focus is what that company needs. "And the stuff that maybe we don't need is not so much [in focus]". He cited SELinux support as an area of systemd that was "very much under-supported", though Boccassi noted that someone from Red Hat had sent pull requests related to SELinux recently. By then, the session had run out of time. Boccassi said he was disappointed that nobody had explicitly asked about AI or Rust, and the session came to a close.

Note: you can avoid this step in the future by logging into your LWN account.