systemd: reading the repository behind the service manager

The tree reveals a userland, not just an init system

The single most misleading thing about systemd is the assumption that it is only the service manager. The description in the repository metadata is The systemd System and Service Manager, and that is accurate, but the top-level tree contains fifty-six entries and most of them are not about services.

Group them by what they configure. The `hwdb.d/`, `sysctl.d/`, `modprobe.d/`, `tmpfiles.d/`, `rules.d/`, `mime/`, `catalog/` and `network/` directories are all declarative configuration that ships to `/usr/lib` and `/etc`. This is the software-specific behaviour layer: hardware database entries, kernel parameters, module options, temporary file creation, udev rules, MIME types, security policy, network configuration and resolvers. systemd is not asking you to install a package for each of these; it is reading one directory per concern.

Then there is the configuration you write yourself. `units/` holds the unit files systemd ships, `profile.d/` and `presets/` hold profile and preset data, `shell-completion/` holds completions for the command-line tools, `hostname-wordlist/` is a small but telling entry that suggests how much attention systemd pays to names, and `tools/` contains the standalone programs users actually type.

The rest is infrastructure: `src/` for the code, `man/` for manual pages, `test/` for the test suite, `docs/` for contributor and architecture guides, `po/` for translations, `mkosi/` for building test images, `factory/` for image generation, `factory/` and `coccinelle/` for semiautomatic source transformation, and the various dotfiles for editors, linters and static analysis.

Read that list and the project's actual scope becomes clear. It is a component library that happens to include the service manager, and the service manager is what most people name it after.

Parallel stable branches are the release strategy

The release data for this repository shows something that catches out contributors who assume one branch and one version.

Three releases are visible in the current window. There is v262-rc3, a release candidate for the main development series, published 2026-09-15. There is v259.9, tagged from the systemd-stable name, published 2026-09-11. And there is v258.11, also from systemd-stable, published the same day, 2026-09-11.

So two different stable series received point releases on the same day while the development series was in release candidate. That is the shape of a project that supports long-lived enterprise deployments seriously: v258 and v259 are both still receiving fixes, and the main branch is already preparing v262.

The gap between the candidate and the mature branches is where the practical consequence sits. Anything you build against a distribution package is almost certainly on v258 or v259, not v262. Which means the feature set you can read about in the newest documentation is not the feature set your distribution ships, and the `NEWS` file the README points you at is how you close that gap.

The README handles this explicitly by telling you stable branches with backported patches live in a separate systemd-stable repository. If you are tracking systemd behaviour, that repository is the more useful thing to watch than the main branch, and the difference between them is exactly the difference between what was accepted and what was considered safe to backport.

Dual licensing that lets one binary serve several audiences

The repository carries a `LICENSE.GPL2` file, a `LICENSE.LGPL2.1` file and a `LICENSES/` directory. The metadata records the primary licence as GPL-2.0, and the presence of the LGPL file next to it is not an oversight.

Dual licensing works by giving downstream consumers a choice of terms. Code under one licence can be reused inside a larger project under the terms of the other, which lets the same source satisfy different distribution requirements without the upstream project having to fork or re-release.

The `LICENSES/` directory is the SPDX convention for this, where each licence text lives in a file named after the identifier and downstream tooling reads the identifiers from source headers. That is a distribution-packaging concern rather than a design one, and it is worth recognising because it is the reason this repository can be consumed by both GPL and LGPL consumers without either side renegotiating terms.

For anyone auditing a system, the arrangement tells you which parts of the tree carry which obligations. Reading the licence identifiers on the files you depend on is more precise than assuming the repository's top-level GPL label applies uniformly, and it matters most for the standalone tools in `tools/`, which are the ones most likely to be copied out of the tree and redistributed on their own.

Static analysis and CI tooling is the real contribution guide

The README is mostly a list of badges, and each badge points at a different automated check. Together they form the most honest description of how this project enforces quality: OBS package status, Semaphore CI builds, Coverity Scan, OSS-Fuzz, CIFuzz, CII Best Practices, a Fossies codespell report, a Fedora translation status widget, Coveralls coverage, Repology packaging status and an OpenSSF Scorecard.

The fuzzing entries deserve emphasis for a C project that runs as PID 1. OSS-Fuzz and CIFuzz mean the parsers, which is where memory-safety bugs in a system component concentrate, are being fuzzed continuously and on every pull request. For an init system, that is not a nice-to-have, because a parser bug in a service manager is reachable by anyone who can write a unit file.

The dotfiles tell the same story from the contributor's side. `.clang-format`, `.clang-tidy`, `.clangd`, `.editorconfig`, `.ctags`, `.vimrc`, `.ycm_extra_conf.py`, `.dir-locals.el`, `.mailmap`, `.pylintrc`, `mypy.ini` and `ruff.toml` together say that C, Python and shell code in one repository are all expected to pass automated style and lint gates. The presence of Python tooling in a codebase that is C tells you that the tooling scripts are treated as production code.

There is also `AGENTS.md` and `CLAUDE.md` at the root, which means the project publishes machine-readable instructions for automated contributors. `CITATION.cff` is there for academic citation. The `coccinelle/` directory adds semantic patching on top of the text-level linters, which is what you use when you have to change hundreds of similar call sites consistently.

Put together with the `.github/` directory and `.semaphore/`, this is a repository whose review process is mostly automated. The README then sends humans to the right documents: the Code Map in `docs/ARCHITECTURE.md` for the repository layout, the hacking guide in `docs/HACKING.md` for testing your own modifications, `docs/CONTRIBUTING.md` for filing issues and pull requests, and `docs/CODING_STYLE.md` for preparing patches.

Where documentation actually lives, and where support comes from

A detail worth noting is how little documentation this repository contains. The README states that most documentation is available on systemd's website, and points the wiki at assorted, older, general information. Build requirements are in the `README` file, release notes are in `NEWS`, and everything architectural is in `docs/`.

That split is a deliberate choice with a real cost. `systemd.io` can be updated independently of the source tree and will describe the newest version, which is exactly why the `NEWS` file exists as the bridge. Anyone reading the website documentation on a distribution running v258 should assume the docs describe v262 until the `NEWS` file says otherwise.

Support, by contrast, is handled through people rather than files, and the README lists three channels: a mailing list at lists.freedesktop.org for systemd-devel, an IRC channel named systemd on libera.chat, and a Matrix channel. The IRC and Matrix options sharing the name systemd is a small reminder that the project has existed long enough to have established channels on both.

There is also a security bug bounty program, sponsored by the Sovereign Tech Fund and hosted through YesWeHack. For a component that starts before almost everything else on a Linux system, a funded disclosure process is a structural necessity rather than a nice extra, and the fact that it is named in the README rather than buried in a policy document tells you the project treats it as part of the interface.

Finally, the README points at Open Build Service repositories for packages built from git main and, separately, for packages built from the latest stable release. Those two OBS projects are the practical route to testing a systemd change before your distribution ships it, and they mirror the main-versus-stable split described earlier.

Editorial conclusion

The systemd repository is worth reading if you want to see how a Linux system is actually assembled, because the tree tells you where every layer of the userland lives and the docs directory explains the reasoning. For day-to-day administration, none of it matters, since the packaged binary and its man pages are what you interact with. Read docs/ARCHITECTURE.md first if you are auditing the codebase, keep an eye on the systemd-stable repository rather than main when you track fixes, and remember that this dual-licensed C code runs as PID 1 on millions of machines, so any patch you send goes through the CONTRIBUTING and CODING_STYLE guidance rather than a quick pull request.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. systemd/systemd on GitHub