Systemd 259 Makes the Journal Persistent by Default and Formally Deprecates SysV Init Scripts

August 2, 2026 — The systemd team shipped version 259, and it is one of the most structural updates since v256. Three changes directly affect Linux administrators: the journal is now persistent by default, SysV init scripts are formally deprecated with removal scheduled for v260, and iptables support is completely removed from systemd-networkd and systemd-nspawn. If you run production servers, this release deserves an hour of your calendar before the end of the quarter.

Persistent journal by default: no more guesswork

Up to v258, systemd-journald applied conditional logic: if the /var/log/journal directory existed, the journal was stored persistently on disk; otherwise, it fell back to volatile storage in /run/log/journal, wiped on every reboot. This heuristic — convenient as it was for embedded systems — created a blind spot for administrators who wrongly assumed their logs survived reboots.

With v259, the journal is persistent by default. The daemon automatically creates /var/log/journal if absent, and logs are written there unconditionally. Volatile mode is still available via Storage=volatile in /etc/systemd/journald.conf, but the default behavior leaves no room for doubt.

Why it matters. A security incident or disk corruption occurring just before a reboot previously left administrators with no trace of the events leading up to shutdown. The new default guarantees that logs survive restarts unless explicitly opted out. The documentation notes that this persistence also applies to journal namespaces introduced in v257 — every container or isolated service now benefits from the same retention level.

SysV init: formal deprecation, removal in v260

System V init script support — via systemd-sysv-generator and systemd-sysv-install — is formally deprecated in v259 and will be completely removed in v260. Distributions and projects still shipping SysV scripts must migrate to native systemd units before the next major release.

The timeline is tight: v260 is expected within systemd’s regular release cadence, roughly three months after v259. For an administrator, the diagnosis is straightforward:

# List SysV scripts still present on the system
ls -la /etc/init.d/ | grep -v README
# Check whether sysv-generator is active
systemctl status sysv-generator 2>/dev/null || echo "SysV generator not running"

If the first command returns anything other than a README file, you have work to do. Each script must be converted into a native .service unit, or the service it manages must be replaced with a modern alternative.

What will actually break. Software that still installs via update-rc.d or manually places scripts in /etc/init.d/ will stop working at boot once v260 is deployed. This is especially true for certain proprietary backup agents, legacy monitoring tools, and older Java daemons that still ship /etc/init.d/ scripts instead of .service files.

v259 emits explicit warnings in the journal each time the SysV generator runs. Administrators can enable tracing:

journalctl -b | grep -i "sysv-generator"

iptables removed: nftables becomes the single standard

systemd-networkd and systemd-nspawn completely drop iptables support in v259. All network filtering rules generated by these components now go exclusively through nftables. This is a sharp dividing line: the Linux kernel still supports iptables via the nf_tables module that emulates the legacy interface, but systemd components now refuse any dependency on that layer.

For a server using systemd-networkd with firewall rules, the change is transparent if your distribution is recent. Fedora, Arch Linux, and Debian Trixie already default to nftables. Administrators on RHEL 9 or derivatives still relying on iptables must verify that their networkd rules are compatible before upgrading.

TPM 2.0 mandatory, cgroup v2 with HugeTLB, and new NvPCRs

TPM 1.2 support is removed from systemd-boot and systemd-stub. Only TPM 2.0 is retained, a decision the team justifies by the universal availability of TPM 2.0 modules since 2020. Machines equipped only with TPM 1.2 — certain generations of Dell PowerEdge and HPE ProLiant servers predating 2017 — lose systemd-level measured boot support.

On the resource management front, cgroup v2 is now mounted with HugeTLB accounting enabled (memory_hugetlb_accounting). HugeTLB memory pages are now counted against global memory limits, meaning a container that heavily consumes huge pages can now hit its MemoryMax limit — which was not always the case before.

The most technically significant innovation in this release concerns NvPCRs (Non-Volatile PCRs). The TPM 2.0 standard limits classic PCRs to 24 shared registers, a bottleneck that forces trade-offs between measurement coverage and trust chain stability. NvPCRs extend this measurement space without disrupting existing PCRs. In practical terms, systemd-analyze gains commands to inspect both classic PCRs and the new NvPCRs:

# List available PCRs and NvPCRs
systemd-analyze pcrs
# Display hardware and identity measurements
systemd-analyze tpm2-measure

Varlink pushes D-Bus aside, and musl enters through the side door

Varlink, the JSON-oriented IPC protocol introduced by Lennart Poettering, continues its rise. v259 now exposes the service manager’s execution settings via Varlink, adds the Reload and Reexecute calls, and extends Varlink APIs to systemd-repart, systemd-resolved, systemd-machined, and systemd-creds. Functional parity with D-Bus is reached for the service manager.

Alongside this, systemd introduces experimental support for building against musl libc, a first in the project’s history. The limitations are explicit: no long-term support guarantee, and certain features — notably around libseccomp and libselinux — are absent in a musl build. This opening targets minimalist containerized environments, where glibc’s size (several megabytes) is a luxury musl (under one megabyte) avoids.

Finally, systemd no longer links directly against libcap. The functionality has been reimplemented internally, shrinking the dependency tree and eliminating a friction point for containers. Dynamic loading (dlopen) now replaces static links to Linux audit, PAM, libseccomp, libselinux, libmount, and libacl, reducing the number of libraries loaded in memory for processes that do not actively use these features.

What you must do before v260

v259 is a preparatory release. It sends the signals, emits the warnings, and gives you time to act before v260 permanently removes SysV support.

• If you have scripts in /etc/init.d/: migrate them to .service units before the end of the quarter. Check with journalctl | grep sysv-generator how many scripts are still loaded at each boot.
• If you use systemd-networkd with iptables: switch to nftables now. v259 removes support; there is no grace period.
• If you rely on measured boot via TPM 1.2: plan a hardware replacement or use an external shim.
• If you audit logs: the default journald behavior changed. Verify that your log rotation, sized for /run in memory, will not fill /var/log on disk.

Systemd 259 is a quiet pivot: it does not break your systems today, but it draws a hard line that v260 will not cross without consequences. The quarter starts now.

References

• Systemd v259 release notes — GitHub, published August 2, 2026
• Systemd 259 Released With Major Changes — Linuxiac, August 2, 2026
• LWN.net — Systemd v259 released, accessed August 9, 2026