Linux systemd

systemd 262 fails a notify-reload service that ignores its reload signal

The upgrade notes for 262 are mostly a breaking-change list: services that neither catch nor block `ReloadSignal=` now fail to start, and TPM-sealed credentials are pinned to the SRK.

systemd 262 is out, dated 2026/09/22. Most of what the release notes have to say is breaking-change list, so here are the entries that end with a unit that will not start or a credential that will not load.

The two with teeth

A service of Type=notify-reload now has to catch or block ReloadSignal= before it sends READY=1. If it does neither, it fails to start with a protocol error. The old behaviour let it start, and a later reload could invoke the signal’s default action and kill the service, so the new failure is the safer of the two. It also arrives on upgrade day.

TPM-sealed credentials are now pinned to the TPM’s storage root key, which closes a man-in-the-middle interposer and lets sealed credentials work when the owner hierarchy is protected with a PIN. The asymmetry to plan around runs the other way: credentials minted after the change are not recognized by older systemd, while a new systemd still accepts credentials created before it. On a box that boots more than one systemd, a second distribution or a rescue image, a credential sealed by 262 is unknown to the other side.

Smaller breakage

  • DNS-SD services registered through systemd-resolved’s D-Bus RegisterService() are unregistered when the registering client disconnects. The client tracking never worked, so services used to linger; now the client has to hold the bus connection open for as long as the service should exist, which means one-shot busctl or gdbus registrations are withdrawn the moment the tool exits. *.dnssd files are how you register something outliving its caller.
  • journalctl rejects -F/--field combined with filters. It used to ignore the filters silently, which is worse. Scripts asking for a field list with a filter attached need rewriting.
  • UnsetEnvironment= is applied after the expansion of ExecStart= and friends. A variable listed there still expands in the command line, then is absent from the environment the process receives.
  • Rate-limit timers, including StartLimitIntervalSec=, moved from CLOCK_MONOTONIC to CLOCK_BOOTTIME. Time spent suspended now counts toward the limit, and state serialized by an older manager can expire once earlier after the upgrade.
  • systemd-tmpfiles rejects non-empty argument fields on line types that do not use them. They were ignored with a warning; now the configuration is rejected, so shipped tmpfiles.d snippets are worth auditing before the upgrade rather than after.
  • For packagers: the deprecated Meson options are gone, static or multicall builds now use -Dsystemd-multicall-binary=true, and old build directories want recreating. Two removals are announced for 263 as well: /run/boot-loader-entries/ and its interfaces, and the experimental systemd-sysupdated D-Bus API.

The line in the repository

The project’s own AGENTS.md is a separate read. It opens with a hard rule: before modifying any source file, an agent must prepend a callout to README.md reading “Remove this line to confirm you’ve reviewed this PR before submitting.” Agents may not remove it themselves, even when asked to clean up or finalize, so the only thing that takes the line out of the diff is a person. The same file says only human beings may be credited in commit messages, with no Co-Authored-By naming a model, and that a rule belongs there only after an agent has been seen to get that particular thing wrong in practice.

My read

A line in the README does not prove anyone read the patch. It leaves a mark a maintainer can see, which is the only place they were ever going to look, and it makes an unreviewed submission say so out loud. That is a smaller claim than a policy on AI contributions, and it is the one that might work.

Source: systemd v262 release notes and the repository’s AGENTS.md