A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v254.tar.gz
Changes since the previous release:
Announcements of Future Feature Removals and Incompatible Changes:
* The next release (v255) will remove support for split-usr (/usr/
mounted separately during late boot, instead of being mounted by the
initrd before switching to the rootfs) and unmerged-usr (parallel
directories /bin/ and /usr/bin/, /lib/ and /usr/lib/, …). For more
details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
* We intend to remove cgroup v1 support from a systemd release after
the end of 2023. If you run services that make explicit use of
cgroup v1 features (i.e. the "legacy hierarchy" with separate
hierarchies for each controller), please implement compatibility with
cgroup v2 (i.e. the "unified hierarchy") sooner rather than later.
Most of Linux userspace has been ported over already.
* Support for System V service scripts is now deprecated and will be
removed in a future release. Please make sure to update your software
*now* to include a native systemd unit file instead of a legacy
System V script to retain compatibility with future systemd releases.
* Support for the SystemdOptions EFI variable is deprecated.
'bootctl systemd-efi-options' will emit a warning when used. It seems
that this feature is little-used and it is better to use alternative
approaches like credentials and confexts. The plan is to drop support
altogether at a later point, but this might be revisited based on
user feedback.
* EnvironmentFile= now treats the line following a comment line
trailing with escape as a non comment line. For details, see:
https://github.com/systemd/systemd/issues/27975
* Behaviour of sandboxing options for the per-user service manager
units has changed. They now imply PrivateUsers=yes, which means user
namespaces will be implicitly enabled when a sandboxing option is
enabled in a user unit. Enabling user namespaces has the drawback
that system users will no longer be visible (and processes/files will
appear as owned by 'nobody') in the user unit.
By definition a sandboxed user unit should run with reduced
privileges, so impact should be small. This will remove a great
source of confusion that has been reported by users over the years,
due to how these options require an extra setting to be manually
enabled when used in the per-user service manager, which is not
needed in the system service manager. For more details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-December/048682.html
* systemd-run's switch --expand-environment= which currently is disabled
by default when combined with --scope, will be changed in a future
release to be enabled by default.
Security Relevant Changes:
* pam_systemd will now by default pass the CAP_WAKE_ALARM ambient
process capability to invoked session processes of regular users on
local seats (as well as to systemd --user), unless configured
otherwise via data from JSON user records, or via the PAM module's
parameter list. This is useful in order allow desktop tools such as
GNOME's Alarm Clock application to set a timer for
CLOCK_REALTIME_ALARM that wakes up the system when it elapses. A
per-user service unit file may thus use AmbientCapability= to pass
the capability to invoked processes. Note that this capability is
relatively narrow in focus (in particular compared to other process
capabilities such as CAP_SYS_ADMIN) and we already — by default —
permit more impactful operations such as system suspend to local
users.
Service Manager:
* "Startup" memory settings are now supported. Previously IO and CPU
settings were already supported via StartupCPUWeight= and similar.
The same logic has been added for the various per-unit memory
settings StartupMemoryMax= and related.
* The service manager gained support for enqueuing POSIX signals to
services that carry an additional integer value, exposing the
sigqueue() system call. This is accessible via new D-Bus calls
org.freedesktop.systemd1.Manager.QueueSignalUnit() and
org.freedesktop.systemd1.Unit.QueueSignal(), as well as in systemctl
via the new --kill-value= option.
* systemctl gained a new "list-paths" verb, which shows all currently
