[systemd-devel] systemd prerelease 256-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v256-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Announcements of Future Feature Removals and Incompatible Changes:
* Support for automatic flushing of the nscd user/group database caches
will be dropped in a future release.
* Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now
considered obsolete and systemd by default will refuse to boot under
it. To forcibly reenable cgroup v1 support,
SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel command
line. The meson option 'default-hierarchy=' is also deprecated, i.e.
only cgroup v2 ('unified' hierarchy) can be selected as build-time
default.
* Previously, systemd-networkd did not explicitly remove any bridge
VLAN IDs assigned on bridge master and ports. Since version 256, if a
.network file for an interface has at least one valid setting in the
[BridgeVLAN] section, then all assigned VLAN IDs on the interface
that are not configured in the .network file are removed.
* systemd-gpt-auto-generator will stop generating units for ESP or
XBOOTLDR partitions if it finds mount entries for or below the /boot/
or /efi/ hierarchies in /etc/fstab. This is to prevent the generator
from interfering with systems where the ESP is explicitly configured
to be mounted at some path, for example /boot/efi/ (this type of
setup is obsolete, but still commonly found).
* The behavior of systemd-sleep and systemd-homed has been updated to
freeze user sessions when entering the various sleep modes or when
locking a homed-managed home area. This is known to cause issues with
the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary
drivers may want to add drop-in configuration files that set
SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for systemd-suspend.service
and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for
systemd-homed.service.
* systemd-tmpfiles and systemd-sysusers, when given a relative
configuration file path (with at least one directory separator '/'),
will open the file directly, instead of searching for the given
partial path in the standard locations. The old mode wasn't useful
because tmpfiles.d/ and sysusers.d/ configuration has a flat
structure with no subdirectories under the standard locations and
this change makes it easier to work with local files with those
tools.
* systemd-tmpfiles now properly applies nested configuration to 'R' and
'D' stanzas. For example, with the combination of 'R /foo' and 'x
/foo/bar', /foo/bar will now be excluded from removal.
General Changes and New Features:
* Various programs will now attempt to load the main configuration file
from locations below /usr/lib/, /usr/local/lib/, and /run/, not just
below /etc/. For example, systemd-logind will look for
/etc/systemd/logind.conf, /run/systemd/logind.conf,
/usr/local/lib/systemd/logind.conf, and /usr/lib/systemd/logind.conf,
and use the first file that is found. This means that the search
logic for the main config file and for drop-ins is now the same.
Similarly, kernel-install will look for the config files in
/usr/lib/kernel/ and the other search locations, and now also
supports drop-ins.
systemd-udevd now supports drop-ins for udev.conf.
* A new 'systemd-vpick' binary has been added. It implements the new
vpick protocol, where a "*.v/" directory may contain multiple files
which have versions (following the UAPI version format specification)
embedded in the file name. The files are ordered by version and
the newest one is selected.
systemd-nspawn --image=/--directory=, systemd-dissect,
systemd-portabled, and the RootDirectory=, RootImage=,
ExtensionImages=, and ExtensionDirectories= settings for units now
support the vpick protocol and allow the latest version to be
selected automatically if a "*.v/" directory is specified as the
source.
* Encrypted service credentials can now be made accessible to
unprivileged users. systemd-creds gained new options --user/--uid=
for encrypting/decrypting a credential for a specific
[systemd-devel] systemd 255 released
A new, official systemd release has just been tagged . Please download the tarball here: https://github.com/systemd/systemd/archive/v255.tar.gz Changes since the previous release: Announcements of Future Feature Removals and Incompatible Changes: * 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/, …) has been removed. 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. * 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. * "systemctl switch-root" is now restricted to initrd transitions only. Transitions between real systems should be done with "systemctl soft-reboot" instead. * The "ip=off" and "ip=none" kernel command line options interpreted by systemd-network-generator will now result in IPv6RA + link-local addressing being disabled, too. Previously DHCP was turned off, but IPv6RA and IPv6 link-local addressing was left enabled. * The NAMING_BRIDGE_MULTIFUNCTION_SLOT naming scheme has been deprecated and is now disabled. * SuspendMode=, HibernateState= and HybridSleepState= in the [Sleep] section of systemd-sleep.conf are now deprecated and have no effect. They did not (and could not) take any value other than the respective default. HybridSleepMode= is also deprecated, and will now always use the 'suspend' disk mode. Service Manager: * The way services are spawned has been overhauled. Previously, a process was forked that shared all of the manager's memory (via copy-on-write) while doing all the required setup (e.g.: mount namespaces, CGroup configuration, etc.) before exec'ing the target executable. This was problematic for various reasons: several glibc APIs were called that are not supposed to be used after a fork but before an exec, copy-on-write meant that if either process (the manager or the child) touched a memory page a copy was triggered, and also the memory footprint of the child process was that of the manager, but with the memory limits of the service. From this version onward, the new process is spawned using CLONE_VM and CLONE_VFORK semantics via posix_spawn(3), and it immediately execs a new internal binary, systemd-executor, that receives the configuration to apply via memfd, and sets up the process before exec'ing the target executable. The systemd-executor binary is pinned by file descriptor by each manager instance (system and users), and the reference is updated on daemon-reexec - it is thus important to reexec all running manager instances when the systemd-executor and/or libsystemd* libraries are updated on the filesystem. * Most of the internal process tracking is being changed to use PIDFDs instead of PIDs when the kernel supports it, to improve robustness and reliability. * A new option SurviveFinalKillSignal= can be used to configure the unit to be skipped in the final SIGTERM/SIGKILL spree on shutdown. This is part of the required configuration to let a unit's processes survive a soft-reboot operation. * System extension imag
[systemd-devel] systemd prerelease 255-rc4
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v255-rc4.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: Announcements of Future Feature Removals and Incompatible Changes: * 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/, …) has been removed. 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. * 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. * "systemctl switch-root" is now restricted to initrd transitions only. Transitions between real systems should be done with "systemctl soft-reboot" instead. * The "ip=off" and "ip=none" kernel command line options interpreted by systemd-network-generator will now result in IPv6RA + link-local addressing being disabled, too. Previously DHCP was turned off, but IPv6RA and IPv6 link-local addressing was left enabled. * The NAMING_BRIDGE_MULTIFUNCTION_SLOT naming scheme has been deprecated and is now disabled. * SuspendMode=, HibernateState= and HybridSleepState= in the [Sleep] section of systemd-sleep.conf are now deprecated and have no effect. They did not (and could not) take any value other than the respective default. HybridSleepMode= is also deprecated, and will now always use the 'suspend' disk mode. Service Manager: * The way services are spawned has been overhauled. Previously, a process was forked that shared all of the manager's memory (via copy-on-write) while doing all the required setup (e.g.: mount namespaces, CGroup configuration, etc.) before exec'ing the target executable. This was problematic for various reasons: several glibc APIs were called that are not supposed to be used after a fork but before an exec, copy-on-write meant that if either process (the manager or the child) touched a memory page a copy was triggered, and also the memory footprint of the child process was that of the manager, but with the memory limits of the service. From this version onward, the new process is spawned using CLONE_VM and CLONE_VFORK semantics via posix_spawn(3), and it immediately execs a new internal binary, systemd-executor, that receives the configuration to apply via memfd, and sets up the process before exec'ing the target executable. The systemd-executor binary is pinned by file descriptor by each manager instance (system and users), and the reference is updated on daemon-reexec - it is thus important to reexec all running manager instances when the systemd-executor and/or libsystemd* libraries are updated on the filesystem. * Most of the internal process tracking is being changed to use PIDFDs instead of PIDs when the kernel supports it, to improve robustness and reliability. * A new option SurviveFinalKillSignal= can be used to configure the unit
[systemd-devel] systemd prerelease 255-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v255-rc3.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: Announcements of Future Feature Removals and Incompatible Changes: * 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/, …) has been removed. 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. * 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. * "systemctl switch-root" is now restricted to initrd transitions only. Transitions between real systems should be done with "systemctl soft-reboot" instead. * The "ip=off" and "ip=none" kernel command line options interpreted by systemd-network-generator will now result in IPv6RA + link-local addressing being disabled, too. Previously DHCP was turned off, but IPv6RA and IPv6 link-local addressing was left enabled. * The NAMING_BRIDGE_MULTIFUNCTION_SLOT naming scheme has been deprecated and is now disabled. * SuspendMode=, HibernateState= and HybridSleepState= in the [Sleep] section of systemd-sleep.conf are now deprecated and have no effect. They did not (and could not) take any value other than the respective default. HybridSleepMode= is also deprecated, and will now always use the 'suspend' disk mode. Service Manager: * The way services are spawned has been overhauled. Previously, a process was forked that shared all of the manager's memory (via copy-on-write) while doing all the required setup (e.g.: mount namespaces, CGroup configuration, etc.) before exec'ing the target executable. This was problematic for various reasons: several glibc APIs were called that are not supposed to be used after a fork but before an exec, copy-on-write meant that if either process (the manager or the child) touched a memory page a copy was triggered, and also the memory footprint of the child process was that of the manager, but with the memory limits of the service. From this version onward, the new process is spawned using CLONE_VM and CLONE_VFORK semantics via posix_spawn(3), and it immediately execs a new internal binary, systemd-executor, that receives the configuration to apply via memfd, and sets up the process before exec'ing the target executable. The systemd-executor binary is pinned by file descriptor by each manager instance (system and users), and the reference is updated on daemon-reexec - it is thus important to reexec all running manager instances when the systemd-executor and/or libsystemd* libraries are updated on the filesystem. * Most of the internal process tracking is being changed to use PIDFDs instead of PIDs when the kernel supports it, to improve robustness and reliability. * A new option SurviveFinalKillSignal= can be used to configure the unit
[systemd-devel] systemd prerelease 255-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v255-rc2.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: Announcements of Future Feature Removals and Incompatible Changes: * 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/, …) has been removed. 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. * 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. * "systemctl switch-root" is now restricted to initrd transitions only. Transitions between real systems should be done with "systemctl soft-reboot" instead. * The "ip=off" and "ip=none" kernel command line options interpreted by systemd-network-generator will now result in IPv6RA + link-local addressing being disabled, too. Previously DHCP was turned off, but IPv6RA and IPv6 link-local addressing was left enabled. * The NAMING_BRIDGE_MULTIFUNCTION_SLOT naming scheme has been deprecated and is now disabled. * SuspendMode=, HibernateState= and HybridSleepState= in the [Sleep] section of systemd-sleep.conf are now deprecated and have no effect. They did not (and could not) take any value other than the respective default. HybridSleepMode= is also deprecated, and will now always use the 'suspend' disk mode. Service Manager: * The way services are spawned has been overhauled. Previously, a process was forked that shared all of the manager's memory (via copy-on-write) while doing all the required setup (e.g.: mount namespaces, CGroup configuration, etc.) before exec'ing the target executable. This was problematic for various reasons: several glibc APIs were called that are not supposed to be used after a fork but before an exec, copy-on-write meant that if either process (the manager or the child) touched a memory page a copy was triggered, and also the memory footprint of the child process was that of the manager, but with the memory limits of the service. From this version onward, the new process is spawned using CLONE_VM and CLONE_VFORK semantics via posix_spawn(3), and it immediately execs a new internal binary, systemd-executor, that receives the configuration to apply via memfd, and sets up the process before exec'ing the target executable. * Most of the internal process tracking is being changed to use PIDFDs instead of PIDs when the kernel supports it, to improve robustness and reliability. * A new option SurviveFinalKillSignal= can be used to configure the unit to be skipped in the final SIGTERM/SIGKILL spree on shutdown. This is part of the required configuration to let a unit's processes survive a soft-reboot operation. * System extension images (sysext) can now set EXTENSION_RELOAD_MANAGER=1 in their extension-release files to automatical
[systemd-devel] systemd prerelease 255-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v255-rc1.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: Announcements of Future Feature Removals and Incompatible Changes: * 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/, …) has been removed. 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. * 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. * "systemctl switch-root" is now restricted to initrd transitions only. Transitions between real systems should be done with "systemctl soft-reboot" instead. * The "ip=off" and "ip=none" kernel command line options interpreted by systemd-network-generator will now result in IPv6RA + link-local addressing being disabled, too. Previously DHCP was turned off, but IPv6RA and IPv6 link-local addressing was left enabled. * The NAMING_BRIDGE_MULTIFUNCTION_SLOT naming scheme has been deprecated and is now disabled. * SuspendMode=, HibernateState= and HybridSleepState= in the [Sleep] section of systemd-sleep.conf are now deprecated and have no effect. They did not (and could not) take any value other than the respective default. HybridSleepMode= is also deprecated, and will now always use the 'suspend' disk mode. Service Manager: * The way services are spawned has been overhauled. Previously, a process was forked that shared all of the manager's memory (via copy-on-write) while doing all the required setup (e.g.: mount namespaces, CGroup configuration, etc.) before exec'ing the target executable. This was problematic for various reasons: several glibc APIs were called that are not supposed to be used after a fork but before an exec, copy-on-write meant that if either process (the manager or the child) touched a memory page a copy was triggered, and also the memory footprint of the child process was that of the manager, but with the memory limits of the service. From this version onward, the new process is spawned using CLONE_VM and CLONE_VFORK semantics via posix_spawn(3), and it immediately execs a new internal binary, systemd-executor, that receives the configuration to apply via memfd, and sets up the process before exec'ing the target executable. * Most of the internal process tracking is being changed to use PIDFDs instead of PIDs when the kernel supports it, to improve robustness and reliability. * A new option SurviveFinalKillSignal= can be used to configure the unit to be skipped in the final SIGTERM/SIGKILL spree on shutdown. This is part of the required configuration to let a unit's processes survive a soft-reboot operation. * System extension images (sysext) can now set EXTENSION_RELOAD_MANAGER=1 in their extension-release files to automatical
[systemd-devel] systemd 254 released
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-pat
[systemd-devel] systemd prerelease 254-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v254-rc3.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md 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
[systemd-devel] systemd prerelease 254-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v254-rc2.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md 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. * 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 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 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 active .path units, similarly to how "systemctl list-timers" shows active timers, and "systemctl list-sockets" shows active sockets. * systemctl gained a new --when= switch which is honoured by the various forms of shutdown (i.e. reboot, kexec, poweroff, halt) and allows sc
[systemd-devel] systemd prerelease 254-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v254-rc1.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md 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. * 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 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 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 active .path units, similarly to how "systemctl list-timers" shows active timers, and "systemctl list-sockets" shows active sockets. * systemctl gained a new --when= switch which is honoured by the various forms of shutdown (i.e. reboot, kexec, poweroff, halt) and allows sc
[systemd-devel] systemd 253 released
A new, official systemd release has just been tagged . Please download the tarball here: https://github.com/systemd/systemd/archive/v253.tar.gz Changes since the previous release: Announcements of Future Feature Removals and Incompatible Changes: * We intend to remove cgroup v1 support from 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. * We intend to remove support for split-usr (/usr mounted separately during boot) and unmerged-usr (parallel directories /bin and /usr/bin, /lib and /usr/lib, etc). This will happen in the second half of 2023, in the first release that falls into that time window. For more details, see: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html * We intend to change behaviour w.r.t. units of the per-user service manager and sandboxing options, so that they work without having to manually enable PrivateUsers= as well, which is not required for system units. To make this work, we will implicitly enable user namespaces (PrivateUsers=yes) when a sandboxing option is enabled in a user unit. The drawback is that system users will no longer be visible (and appear as 'nobody') to the user unit when a sandboxing option is enabled. 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, as opposed as to the system service manager. We plan to enable this change in the next release later this year. For more details, see: https://lists.freedesktop.org/archives/systemd-devel/2022-December/048682.html Deprecations and incompatible changes: * systemctl will now warn when invoked without /proc/ mounted (e.g. when invoked after chroot() into an directory tree without the API mount points like /proc/ being set up.) Operation in such an environment is not fully supported. * The return value of 'systemctl is-active|is-enabled|is-failed' for unknown units is changed: previously 1 or 3 were returned, but now 4 (EXIT_PROGRAM_OR_SERVICES_STATUS_UNKNOWN) is used as documented. * 'udevadm hwdb' subcommand is deprecated and will emit a warning. systemd-hwdb (added in 2014) should be used instead. * 'bootctl --json' now outputs a single JSON array, instead of a stream of newline-separated JSON objects. * Udev rules in 60-evdev.rules have been changed to load hwdb properties for all modalias patterns. Previously only the first matching pattern was used. This could change what properties are assigned if the user has more and less specific patterns that could match the same device, but it is expected that the change will have no effect for most users. * systemd-networkd-wait-online exits successfully when all interfaces are ready or unmanaged. Previously, if neither '--any' nor '--interface=' options were used, at least one interface had to be in configured state. This change allows the case where systemd-networkd is enabled, but no interfaces are configured, to be handled gracefully. It may occur in particular when a different network manager is also enabled and used. * Some compatibility helpers were dropped: EmergencyAction= in the user manager, as well as measuring kernel command line into PCR 8 in systemd-stub, along with the -Defi-tpm-pcr-compat compile-time option. * The '-Dupdate-helper-user-timeout=' build-time option has been renamed to '-Dupdate-helper-user-timeout-sec=', and now takes an integer as parameter instead of a string. * The DDI image dissection logic (which backs RootImage= in service unit files, the --image= switch in various tools such as systemd-nspawn, as well as systemd-dissect) will now only mount file systems of types btrfs, ext4, xfs, erofs, squashfs, vfat. This list can be overridden via the $SYSTEMD_DISSECT_FILE_SYSTEMS environment variable. These file systems are fairly well supported and maintained in current kernels, while others ar
[systemd-devel] systemd prerelease 253-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v253-rc3.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: Announcements of Future Feature Removals and Incompatible Changes: * We intend to remove cgroup v1 support from 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. * We intend to remove support for split-usr (/usr mounted separately during boot) and unmerged-usr (parallel directories /bin and /usr/bin, /lib and /usr/lib, etc). This will happen in the second half of 2023, in the first release that falls into that time window. For more details, see: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html * We intend to change behaviour w.r.t. units of the per-user service manager and sandboxing options, so that they work without having to manually enable PrivateUsers= as well, which is not required for system units. To make this work, we will implicitly enable user namespaces (PrivateUsers=yes) when a sandboxing option is enabled in a user unit. The drawback is that system users will no longer be visible (and appear as 'nobody') to the user unit when a sandboxing option is enabled. 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, as opposed as to the system service manager. We plan to enable this change in the next release later this year. For more details, see: https://lists.freedesktop.org/archives/systemd-devel/2022-December/048682.html Deprecations and incompatible changes: * systemctl will now warn when invoked without /proc/ mounted (e.g. when invoked after chroot() into an directory tree without the API mount points like /proc/ being set up.) Operation in such an environment is not fully supported. * The return value of 'systemctl is-active|is-enabled|is-failed' for unknown units is changed: previously 1 or 3 were returned, but now 4 (EXIT_PROGRAM_OR_SERVICES_STATUS_UNKNOWN) is used as documented. * 'udevadm hwdb' subcommand is deprecated and will emit a warning. systemd-hwdb (added in 2014) should be used instead. * 'bootctl --json' now outputs a single JSON array, instead of a stream of newline-separated JSON objects. * Udev rules in 60-evdev.rules have been changed to load hwdb properties for all modalias patterns. Previously only the first matching pattern was used. This could change what properties are assigned if the user has more and less specific patterns that could match the same device, but it is expected that the change will have no effect for most users. * systemd-networkd-wait-online exits successfully when all interfaces are ready or unmanaged. Previously, if neither '--any' nor '--interface=' options were used, at least one interface had to be in configured state. This change allows the case where systemd-networkd is enabled, but no interfaces are configured, to be handled gracefully. It may occur in particular when a different network manager is also enabled and used. * Some compatibility helpers were dropped: EmergencyAction= in the user manager, as well as measuring kernel command line into PCR 8 in systemd-stub, along with the -Defi-tpm-pcr-compat compile-time option. * The '-Dupdate-helper-user-timeout=' build-time option has been renamed to '-Dupdate-helper-user-timeout-sec=', and now takes an integer as parameter instead of a string. * The DDI image dissection logic (which backs RootImage= in service unit files, the --image= switch in various tools such as systemd-nspawn, as well as systemd-dissect) will now only mount file systems of types btrfs, ext4, xfs, erofs, squas
[systemd-devel] systemd prerelease 253-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v253-rc2.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Deprecations and incompatible changes:
* systemctl will now warn when invoked without /proc/ mounted
(e.g. when invoked after chroot() into an directory tree without the
API mount points like /proc/ being set up.) Operation in such an
environment is not fully supported.
* The return value of 'systemctl is-active|is-enabled|is-failed' for
unknown units is changed: previously 1 or 3 were returned, but now 4
(EXIT_PROGRAM_OR_SERVICES_STATUS_UNKNOWN) is used as documented.
* 'udevadm hwdb' subcommand is deprecated and will emit a warning.
systemd-hwdb (added in 2014) should be used instead.
* 'bootctl --json' now outputs a single JSON array, instead of a stream
of newline-separated JSON objects.
* Udev rules in 60-evdev.rules have been changed to load hwdb
properties for all modalias patterns. Previously only the first
matching pattern was used. This could change what properties are
assigned if the user has more and less specific patterns that could
match the same device, but it is expected that the change will have
no effect for most users.
* systemd-networkd-wait-online exits successfully when all interfaces
are ready or unmanaged. Previously, if neither '--any' nor
'--interface=' options were used, at least one interface had to be in
configured state. This change allows the case, where systemd-networkd
is enabled but no interfaces are configured, to be handled
gracefully. It may occur in particular when a different network
manager is also enabled and used.
* Some compatibility helpers were dropped: EmergencyAction= in the user
manager, as well as measuring kernel command line into PCR 8 in
systemd-stub, along with the -Defi-tpm-pcr-compat compile-time
option.
* The '-Dupdate-helper-user-timeout=' build-time option has been
renamed to '-Dupdate-helper-user-timeout-sec=', and now takes an
integer as parameter instead of a string.
* The DDI image dissection logic (which backs RootImage= in service
unit files, the --image= switch in various tools such as
systemd-nspawn, as well as systemd-dissect) will now only mount file
systems of types btrfs, ext4, xfs, erofs, squashfs, vfat. This list
can be overriden via the $SYSTEMD_DISSECT_FILE_SYSTEMS environment
variable. These file systems are fairly well supported and maintained
in current kernels, while others are usually more niche, exotic or
legacy and thus typically do not receive the same level of security
support and fixes.
New components:
* A tool 'ukify' tool to build, measure, and sign Unified Kernel Images
(UKIs) has been added. This replaces functionality provided by
'dracut --uefi' and extends it with automatic calculation of PE file
offsets, insertion of signed PCR policies generated by
systemd-measure, support for initrd concatenation, signing of the
embedded Linux image and the combined image with sbsign, and
heuristics to autodetect the kernel uname and verify the splash
image.
Changes in systemd and units:
* A new service type Type=notify-reload is defined. When such a unit is
reloaded a UNIX process signal (typically SIGHUP) is sent to the main
service process. The manager will then wait until it receives a
"RELOADING=1" followed by a "READY=1" notification from the unit as
response (via sd_notify()). Otherwise, this type is the same as
Type=notify. A new setting ReloadSignal= may be used to change the
signal to send from the default of SIGHUP.
user@.service, systemd-networkd.service, systemd-udevd.service, and
systemd-logind have been updated to this type.
* Initrd environments which are not on a pure memory file system (e.g.
overlayfs combination as opposed to tmpfs) are now supported. With
this change, during the initrd → host transition ("switch root")
systemd will no longer erase all files of the initrd unless it's
backed by a memory file system such as tmpfs.
* New per-unit MemoryZSwapMax= option has been added to configure
memory.zswap.max cgroup propertie
[systemd-devel] systemd prerelease 253-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v253-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Deprecations and incompatible changes
* systemctl will now warn when invoked without /proc mounted (e.g. when
invoked after chroot into an image without the API mount points like
/proc being set up.) Operation in such an environment is not fully
supported.
* The return value of 'systemctl is-active|is-enabled|is-failed' for
unknown units is changed: previously 1 or 3 were returned, but now 4
(EXIT_PROGRAM_OR_SERVICES_STATUS_UNKNOWN) is used as documented.
* 'udevadm hwdb' subcommand is deprecated and will emit a warning.
systemd-hwdb (added in 2014) should be used instead.
* 'bootctl --json' now outputs well-formed JSON, instead of a stream
of newline-separated JSON objects.
* Udev rules in 60-evdev.rules have been changed to load hwdb properties
for all modalias patterns. Previously only the first matching pattern
was used. This could change what properties are assigned if the user
has more and less specific patterns that could match the same device,
but it is expected that the change will have no effect for most users.
* systemd-networkd-wait-online exits successfully when all interfaces
are ready or unmanaged. Previously, if neither '--any' nor
'--interface=' options were used, at least one interface had to be in
configured state. This change allows the case, where systemd-networkd
is enabled but no interfaces are configured, to be handled
gracefully. It may occur in particular when a different network
manager is also enabled and used.
* Some compatibility helpers were dropped: EmergencyAction= in the user
manager, measuring kernel command line into PCR 8 along with the
-Defi-tpm-pcr-compat compile-time option.
New components:
* A tool 'ukify' tool to build, measure, and sign Unified Kernel Images
(UKIs) has been added. This replaces functionality provided by
'dracut --uefi' and extends it with automatic calculation of offsets,
insertion of signed PCR policies generated by systemd-measure,
support for initrd concatenation, signing of the embedded Linux image
and the combined image with sbsign, and heuristics to autodetect the
kernel uname and verify the splash image.
Changes in systemd and units:
* A new unit type Type=notify-reload is defined. When such a unit is
reloaded via a signal, the manager will wait until it receives a
"READY=1" notification from the unit. Otherwise, this type is the
same as Type=notify.
user@.service, systemd-networkd.service, systemd-udevd.service, and
systemd-logind have been updated to this type; their reloads are now
synchronuous.
* Initrd environments which are not on a temporary file system (for
example an overlayfs combination) are now supported. Systemd will only
skip removal of the files in the initrd if it doesn't detect a
temporary file system.
* New MemoryZSwapMax= option has been added to configure
memory.zswap.max cgroup properties (the maximum amount of zswap used).
* New LogFilterPatterns= option can be used to specify regexp
accept/deny patterns for log entries generated by the unit. Based on
the option value, the manager sets the
user.journald_log_filter_patterns extended attribute on the unit
cgroup. systemd-journald checks for this attribute when receiving
messages, and will filter messages by matching the MESSAGE= part.
Rejected messages are neither stored in the journal nor forwarded.
This option can be used to filter noisy or uninteresting messages
from units.
* The manager has a new
org.freedesktop.systemd1.Manager.GetUnitByPIDFD() method to query
process ownership via a PIDFD, which is more resilient against PID
recycling issues.
* Scope units now support OOMPolicy=. Login session scopes default to
OOMPolicy=continue, allowing login scopes to survive the OOM killer
terminating some processes in the scope.
* systemd-fstab-generator now supports x-systemd.makefs option for
/sysroot (in the initrd).
* The maximum rate at which daemon reloads are executed can now be
limited wi
Re: [systemd-devel] Issue with systemd / journalctl
Hi, Thanks for your answer. In the meanwhile I've discovered it's linked to selinux filesystem not mounted (don't ask me why, I'm still trying to dig into this...) It solved most of the failed except the udev ones. Le 26/12/2022 à 23:27, Barry a écrit : On 26 Dec 2022, at 14:02,syst...@sioban.net wrote: Hi, I'm sorry if I'm at the wrong place but I feel I have a big issue with systemd and journalctl. Basically I know no more journal logs since 24/10 and I have no real idea why. I would ask on a debian mailing list. They will know the detail of how rsyslog service is packaged. Its not systemd itself that is likely to be the source of the problem It will most likely be the service unit files that you have installed that need debugging. Here is the full story, if I'm at the wrong place, please tell me so. I've discovered I have an issue with systemd on my Debian server. I've seen that some logging service don't want to start through systemd but the daemon itself start without issues: ❯ systemctl start rsyslog.service A dependency job for rsyslog.service failed. See 'journalctl -xe' for details. If I start manually rsyslogd, it's working: ❯ /usr/sbin/rsyslogd ❯ ps awx | grep rsyslog 45995 ?Ssl0:00 /usr/sbin/rsyslogd So I tried to understand what's wrong with systemd. First, journalctl -xe shows only lines from 24 Oct, nothing recent. I've tried timedatectl to ensure the date is correct but got this message ❯ timedatectl Failed to connect to bus: No such file or directory I've searched a lot on Internet and ended up running systemctl --failed command and it shown many failed services: ❯ systemctl --failed UNITLOAD ACTIVE SUBDESCRIPTION ● dbus.socket loaded failed failed D-Bus System Message Bus Socket ● syslog.socket loaded failed failed Syslog Socket ● systemd-fsckd.socketloaded failed failed fsck to fsckd communication Socket ● systemd-journald-audit.socket loaded failed failed Journal Audit Socket ● systemd-journald-dev-log.socket loaded failed failed Journal Socket (/dev/log) ● systemd-journald.socket loaded failed failed Journal Socket ● systemd-udevd-control.socketloaded failed failed udev Control Socket ● systemd-udevd-kernel.socket loaded failed failed udev Kernel Socket ● uuidd.socketloaded failed failed UUID daemon activation socket LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB= The low-level unit activation state, values depend on unit type. 9 loaded units listed. I've re-installed systemd-sysv and rebooted, cleaned old journalctl entries but same issues. Why do you need the sysv package on a systemd system at all? Barry Basically, I'm clueless here :/ If someone have an idea :D
[systemd-devel] Issue with systemd / journalctl
Hi, I'm sorry if I'm at the wrong place but I feel I have a big issue with systemd and journalctl. Basically I know no more journal logs since 24/10 and I have no real idea why. Here is the full story, if I'm at the wrong place, please tell me so. I've discovered I have an issue with systemd on my Debian server. I've seen that some logging service don't want to start through systemd but the daemon itself start without issues: > ❯ systemctl start rsyslog.service > A dependency job for rsyslog.service failed. See 'journalctl -xe' for details. If I start manually rsyslogd, it's working: > ❯ /usr/sbin/rsyslogd > ❯ ps awx | grep rsyslog > 45995 ? Ssl 0:00 /usr/sbin/rsyslogd So I tried to understand what's wrong with systemd. First, journalctl -xe shows only lines from 24 Oct, nothing recent. I've tried timedatectl to ensure the date is correct but got this message > ❯ timedatectl > Failed to connect to bus: No such file or directory I've searched a lot on Internet and ended up running systemctl --failed command and it shown many failed services: > ❯ systemctl --failed > UNIT LOAD ACTIVE SUB DESCRIPTION > ● dbus.socket loaded failed failed D-Bus System Message Bus Socket > ● syslog.socket loaded failed failed Syslog Socket > ● systemd-fsckd.socket loaded failed failed fsck to fsckd communication Socket > ● systemd-journald-audit.socket loaded failed failed Journal Audit Socket > ● systemd-journald-dev-log.socket loaded failed failed Journal Socket (/dev/log) > ● systemd-journald.socket loaded failed failed Journal Socket > ● systemd-udevd-control.socket loaded failed failed udev Control Socket > ● systemd-udevd-kernel.socket loaded failed failed udev Kernel Socket > ● uuidd.socket loaded failed failed UUID daemon activation socket > > LOAD = Reflects whether the unit definition was properly loaded. > ACTIVE = The high-level unit activation state, i.e. generalization of SUB. > SUB = The low-level unit activation state, values depend on unit type. > 9 loaded units listed. I've re-installed systemd-sysv and rebooted, cleaned old journalctl entries but same issues. Basically, I'm clueless here :/ If someone have an idea :D
[systemd-devel] systemd 252 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v252.tar.gz
Changes since the previous release:
Announcements of Future Feature Removals:
* We intend to remove cgroup v1 support from 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.
* We intend to remove support for split-usr (/usr mounted separately
during boot) and unmerged-usr (parallel directories /bin and
/usr/bin, /lib and /usr/lib, etc). This will happen in the second
half of 2023, in the first release that falls into that time window.
For more details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
Compatibility Breaks:
* ConditionKernelVersion= checks that use the '=' or '!=' operators
will now do simple string comparisons (instead of version comparisons
á la stverscmp()). Version comparisons are still done for the
ordering operators '<', '>', '<=', '>='. Moreover, if no operator is
specified, a shell-style glob match is now done. This creates a minor
incompatibility compared to older systemd versions when the '*', '?',
'[', ']' characters are used, as these will now match as shell globs
instead of literally. Given that kernel version strings typically do
not include these characters we expect little breakage through this
change.
* The service manager will now read the SELinux label used for SELinux
access checks from the unit file at the time it loads the file.
Previously, the label would be read at the moment of the access
check, which was problematic since at that time the unit file might
already have been updated or removed.
New Features:
* systemd-measure is a new tool for calculating and signing expected
TPM2 PCR values for a given unified kernel image (UKI) booted via
sd-stub. The public key used for the signature and the signed
expected PCR information can be embedded inside the UKI. This
information can be extracted from the UKI by external tools and code
in the image itself and is made available to userspace in the booted
kernel.
systemd-cryptsetup, systemd-cryptenroll, and systemd-creds have been
updated to make use of this information if available in the booted
kernel: when locking an encrypted volume/credential to the TPM
systemd-cryptenroll/systemd-creds will use the public key to bind the
volume/credential to any kernel that carries PCR information signed
by the same key pair. When unlocking such volumes/credentials
systemd-cryptsetup/systemd-creds will use the signature embedded in
the booted UKI to gain access.
Binding TPM-based disk encryption to public keys/signatures of PCR
values — instead of literal PCR values — addresses the inherent
"brittleness" of traditional PCR-bound TPM disk encryption schemes:
disks remain accessible even if the UKI is updated, without any TPM
specific preparation during the OS update — as long as each UKI
carries the necessary PCR signature information.
Net effect: if you boot a properly prepared kernel, TPM-bound disk
encryption now defaults to be locked to kernels which carry PCR
signatures from the same key pair. Example: if a hypothetical distro
FooOS prepares its UKIs like this, TPM-based disk encryption is now –
by default – bound to only FooOS kernels, and encrypted volumes bound
to the TPM cannot be unlocked on kernels from other sources. (But do
note this behaviour requires preparation/enabling in the UKI, and of
course users can always enroll non-TPM ways to unlock the volume.)
* systemd-pcrphase is a new tool that is invoked at six places during
system runtime, and measures additional words into TPM2 PCR 11, to
mark milestones of the boot process. This allows binding access to
specific TPM2-encrypted secrets to specific phases of the boot
process. (Example: LUKS2 disk encryption key only accessible in the
initrd, but not later.)
Changes in systemd itself, i.e. the manager and units
* The cpu controller is delegated to user manager units by default, and
CPUWeight=
[systemd-devel] systemd prerelease 252-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v252-rc3.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Announcements of Future Feature Removals:
* We intend to remove cgroup v1 support from 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.
* We intend to remove support for split-usr (/usr mounted separately
during boot) and unmerged-usr (parallel directories /bin and
/usr/bin, /lib and /usr/lib, etc). This will happen in the second
half of 2023, in the first release that falls into that time window.
For more details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
Compatibility Breaks:
* ConditionKernelVersion= checks that use the '=' or '!=' operators
will now do simple string comparisons (instead of version comparisons
á la stverscmp()). Version comparisons are still done for the
ordering operators '<', '>', '<=', '>='. Moreover, if no operator is
specified, a shell-style glob match is now done. This creates a minor
incompatibility compared to older systemd versions when the '*', '?',
'[', ']' characters are used, as these will now match as shell globs
instead of literally. Given that kernel version strings typically do
not include these characters we expect little breakage through this
change.
* The service manager will now read the SELinux label used for SELinux
access checks from the unit file at the time it loads the file.
Previously, the label would be read at the moment of the access
check, which was problematic since at that time the unit file might
already have been updated or removed.
New Features:
* systemd-measure is a new tool for calculating and signing expected
TPM2 PCR values for a given unified kernel image (UKI) booted via
sd-stub. The public key used for the signature and the signed
expected PCR information can be embedded inside the UKI. This
information can be extracted from the UKI by external tools and code
in the image itself and is made available to userspace in the booted
kernel.
systemd-cryptsetup, systemd-cryptenroll, and systemd-creds have been
updated to make use of this information if available in the booted
kernel: when locking an encrypted volume/credential to the TPM
systemd-cryptenroll/systemd-creds will use the public key to bind the
volume/credential to any kernel that carries PCR information signed
by the same key pair. When unlocking such volumes/credentials
systemd-cryptsetup/systemd-creds will use the signature embedded in
the booted UKI to gain access.
Binding TPM-based disk encryption to public keys/signatures of PCR
values — instead of literal PCR values — addresses the inherent
"brittleness" of traditional PCR-bound TPM disk encryption schemes:
disks remain accessible even if the UKI is updated, without any TPM
specific preparation during the OS update — as long as each UKI
carries the necessary PCR signature information.
Net effect: if you boot a properly prepared kernel, TPM-bound disk
encryption now defaults to be locked to kernels which carry PCR
signatures from the same key pair. Example: if a hypothetical distro
FooOS prepares its UKIs like this, TPM-based disk encryption is now –
by default – bound to only FooOS kernels, and encrypted volumes bound
to the TPM cannot be unlocked on kernels from other sources. (But do
note this behaviour requires preparation/enabling in the UKI, and of
course users can always enroll non-TPM ways to unlock the volume.)
* systemd-pcrphase is a new tool that is invoked at six places during
system runtime, and measures additional words into TPM2 PCR 11, to
mark milestones of the boot process. This allows binding access to
specific TPM2-encrypted secrets to specific phases of the boot
process. (Example: LUKS2 disk encryption k
[systemd-devel] systemd prerelease 252-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v252-rc2.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Announcements of Future Feature Removals:
* We intend to remove cgroup v1 support from 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.
* We intend to remove support for split-usr (/usr mounted separately
during boot) and unmerged-usr (parallel directories /bin and
/usr/bin, /lib and /usr/lib, etc). This will happen in the second
half of 2023, in the first release that falls into that time window.
For more details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
Compatibility Breaks:
* ConditionKernelVersion= checks that use the '=' or '!=' operators
will now do simple string comparisons (instead of version comparisons
á la stverscmp()). Version comparisons are still done for the
ordering operators '<', '>', '<=', '>='. Moreover, if no operator is
specified, a shell-style glob match is now done. This creates a minor
incompatibility compared to older systemd versions when the '*', '?',
'[', ']' characters are used, as these will now match as shell globs
instead of literally. Given that kernel version strings typically do
not include these characters we expect little breakage through this
change.
* The service manager will now read the SELinux label used for SELinux
access checks from the unit file at the time it loads the file.
Previously, the label would be read at the moment of the access
check, which was problematic since at that time the unit file might
already have been updated or removed.
New Features:
* systemd-measure is a new tool for calculating and signing expected
TPM2 PCR values for a given unified kernel image (UKI) booted via
sd-stub. The public key used for the signature and the signed
expected PCR information can be embedded inside the UKI. This
information can be extracted from the UKI by external tools and code
in the image itself and is made available to userspace in the booted
kernel.
systemd-cryptsetup, systemd-cryptenroll, and systemd-creds have been
updated to make use of this information if available in the booted
kernel: when locking an encrypted volume/credential to the TPM
systemd-cryptenroll/systemd-creds will use the public key to bind the
volume/credential to any kernel that carries PCR information signed
by the same key pair. When unlocking such volumes/credentials
systemd-cryptsetup/systemd-creds will use the signature embedded in
the booted UKI to gain access.
Binding TPM-based disk encryption to public keys/signatures of PCR
values — instead of literal PCR values — addresses the inherent
"brittleness" of traditional PCR-bound TPM disk encryption schemes:
disks remain accessible even if the UKI is updated, without any TPM
specific preparation during the OS update — as long as each UKI
carries the necessary PCR signature information.
Net effect: if you boot a properly prepared kernel, TPM-bound disk
encryption now defaults to be locked to kernels which carry PCR
signatures from the same key pair. Example: if a hypothetical distro
FooOS prepares its UKIs like this, TPM-based disk encryption is now –
by default – bound to only FooOS kernels, and encrypted volumes bound
to the TPM cannot be unlocked on kernels from other sources. (But do
note this behaviour requires preparation/enabling in the UKI, and of
course users can always enroll non-TPM ways to unlock the volume.)
* systemd-pcrphase is a new tool that is invoked at six places during
system runtime, and measures additional words into TPM2 PCR 11, to
mark milestones of the boot process. This allows binding access to
specific TPM2-encrypted secrets to specific phases of the boot
process. (Example: LUKS2 disk encryption k
[systemd-devel] systemd prerelease 252-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v252-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Announcement of Future Feature Removal:
* Please note that we intend to remove cgroupsv1 support from systemd
release after EOY 2023. If you run services that make explicit use of
cgroupsv1 features, please implement compatibility with cgroupsv2
sooner rather than later, if you haven't done so yet. Most of Linux
userspace has been ported over already.
* Please note that we intend to remove support for split-usr and
unmerged-usr. This will happen in the second half of 2023, in the
first release that falls into that time window. For more details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
Compatibility Breaks:
* ConditionKernelVersion= checks that use the = or != operator will now
do simple string compares (as opposed to version compare – á la
stverscmp() — as before, which is still done for the ordering
operators <, >, <=, >=). Moreover, if no operator is specified a
shell-style glob match is now done. This creates a minor
incompatibility compared to older systemd versions, in case the *, ?,
[, ], characters have been used in such condition expressions before,
as these will now match per shell glob rules instead of
literally. Given that kernel version strings typically do not include
these characters we expect little breakage through this change.
New Features:
* systemd-measure is a new helper to precalculate PCR measurements
to make it easier to set TPM2 policies.
Changes in systemd itself, i.e. the manager, and units
* The cpu controller is delegated to user manager units, and CPUWeight=
settings are applied to the top-level user slice units (app.slice,
background.slice, session.slice). This provides a degree of resource
isolation between different user services competing for the CPU.
* Systemd can optionally do a full preset in the "first boot" condition
(instead of just enable-only). This behaviour is controlled by the
compile-time option -Dfirst-boot-full-preset=. Right now it defaults
to 'false', but the plan is to switch it to 'true' for the subsequent
release.
* Systemd will set the taint flag 'support-ended' if it detects that
the os image is past its end-of-support date.
* Two new settings ConditionCredential= and AssertCredential= can
be used to skip or fail units if a certain credential is not provided.
* ConditionMemory= accepts size suffixes.
* DefaultSmackProcessLabel= can be used in system.conf and user.conf
to specify the smack label to use when not specified in a unit file.
* DefaultDeviceTimeoutSec= can be used system.conf and user.conf
to specify the default timeout for devices.
* C.UTF-8 is used as the default locale if nothing else has been
configured.
* Extend [Condition|Assert]Firmware= to conditionalize on certain SMBIOS
fields. For example
ConditionFirmware=smbios-field(board_name = "Custom Board") will
conditionalize a unit so that it is only run when
/sys/class/dmi/id/board_name contains "Custom Board" (without quotes).
* ConditionFirstBoot= now correctly evaluates as true only during the
boot phase of the first boot. A unit re-ran later, after booting has
completed, will no longer evaluate this condition as true.
* Socket units will now create sockets in the SELinuxContext= of the
associated service unit, if any.
* Boot phase transitions (start initrd -> exit initrd -> boot complete
-> shutdown) will be measured into PCR11, so that secrets can be bound
to specific runtime phases, e.g.: a LUKS encryption key could be
unsealed only in the initrd.
* Credentials will now also be provided to ExecStartPre= processes.
* Various units are now correctly ordered with initrd-switch-root.target
where previously some were just (indirectly) ordered only with
initrd-switch-root.service.
* In order to fully support the IPMI watchdog driver, which has not yet
been ported to the new numbered device interface, /dev/watchdog0 will
be tried first and systemd will silently fal
[systemd-devel] systemd 251 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v251.tar.gz
Changes since the previous release:
Backwards-incompatible changes:
* The minimum kernel version required has been bumped from 3.13 to 4.15,
and CLOCK_BOOTTIME is now assumed to always exist.
* C11 with GNU extensions (aka "gnu11") is now used to build our
components. Public API headers are still restricted to ISO C89.
* In v250, a systemd-networkd feature that automatically configures
routes to addresses specified in AllowedIPs= was added and enabled by
default. However, this causes network connectivity issues in many
existing setups. Hence, it has been disabled by default since
systemd-stable 250.3. The feature can still be used by explicitly
configuring RouteTable= setting in .netdev files.
* Jobs started via StartUnitWithFlags() will no longer return 'skipped'
when a Condition*= check does not succeed, restoring the JobRemoved
signal to the behaviour it had before v250.
* The org.freedesktop.portable1 methods GetMetadataWithExtensions() and
GetImageMetadataWithExtensions() have been fixed to provide an extra
return parameter, containing the actual extension release metadata.
The current implementation was judged to be broken and unusable, and
thus the usual procedure of adding a new set of methods was skipped,
and backward compatibility broken instead on the assumption that
nobody can be affected given the current state of this interface.
* All kernels supported by systemd mix RDRAND (or similar) into the
entropy pool at early boot. This means that on those systems, even if
/dev/urandom is not yet initialized, it still returns bytes that that
are at least as high quality as RDRAND. For that reason, we no longer
have reason to invoke RDRAND from systemd itself, which has
historically been a source of bugs. Furthermore, kernels ≥5.6 provide
the getrandom(GRND_INSECURE) interface for returning random bytes
before the entropy pool is initialized without warning into kmsg,
which is what we attempt to use if available. systemd's direct usage
of RDRAND has been removed. x86 systems ≥Broadwell that are running
an older kernel may experience kmsg warnings that were not seen with
250. For newer kernels, non-x86 systems, or older x86 systems, there
should be no visible changes.
* sd-boot will now measure the kernel command line into TPM PCR 12
rather than PCR 8. This improves usefulness of the measurements on
systems where sd-boot is chainloaded from Grub. Grub measures all
commands its executes into PCR 8, which makes it very hard to use
reasonably, hence separate ourselves from that and use PCR 12
instead, which is what certain Ubuntu editions already do. To retain
compatibility with systems running older systemd systems a new meson
option 'efi-tpm-pcr-compat' has been added (which defaults to false).
If enabled, the measurement is done twice: into the new-style PCR 12
*and* the old-style PCR 8. It's strongly advised to migrate all users
to PCR 12 for this purpose in the long run, as we intend to remove
this compatibility feature in two year's time.
* busctl capture now writes output in the newer pcapng format instead
of pcap.
* An udev rule that imported hwdb matches for USB devices with
lowercase hexadecimal vendor/product ID digits was added in systemd
250. This has been reverted, since uppercase hexadecimal digits are
supposed to be used, and we already had a rule that with the
appropriate match.
Users might need to adjust their local hwdb entries.
* arch_prctl(2) has been moved to the @default set in the syscall
filters
(as exposed via the SystemCallFilter= setting in service unit files).
It is apparently used by the linker now.
* The tmpfiles entries that create the /run/systemd/netif directory and
its subdirectories were moved from tmpfiles.d/systemd.conf to
tmpfiles.d/systemd-network.conf.
Users might need to adjust their files that override
tmpfiles.d/systemd.conf
to account for this change.
* The requirement for Portable Services images to contain a well-formed
os-release file (i.e.: contain at least an ID field) is now enforced.
This applies to base images and extensions, and also to
systemd-sysext.
Changes in the Boot Loader Specification, kernel-install and sd-boot:
* kernel
[systemd-devel] systemd prerelease 251-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v251-rc2.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Backwards-incompatible changes:
* The minimum kernel version required has been bumped from 3.13 to 4.15,
and CLOCK_BOOTTIME is now assumed to always exist.
* C11 with GNU extensions (aka "gnu11") is now used to build our
components. Public API headers are still restricted to ISO C89.
* In v250, a systemd-networkd feature that automatically configures
routes to addresses specified in AllowedIPs= was added and enabled by
default. However, this causes network connectivity issues in many
existing setups. Hence, it has been disabled by default since
systemd-stable 250.3. The feature can still be used by explicitly
configuring RouteTable= setting in .netdev files.
* Jobs started via StartUnitWithFlags() will no longer return 'skipped'
when a Condition*= check does not succeed, restoring the JobRemoved
signal to the behaviour it had before v250.
* The org.freedesktop.portable1 methods GetMetadataWithExtensions() and
GetImageMetadataWithExtensions() have been fixed to provide an extra
return parameter, containing the actual extension release metadata.
The current implementation was judged to be broken and unusable, and
thus the usual procedure of adding a new set of methods was skipped,
and backward compatibility broken instead on the assumption that
nobody can be affected given the current state of this interface.
* All kernels supported by systemd mix RDRAND (or similar) into the
entropy pool at early boot. This means that on those systems, even if
/dev/urandom is not yet initialized, it still returns bytes that that
are at least as high quality as RDRAND. For that reason, we no longer
have reason to invoke RDRAND from systemd itself, which has
historically been a source of bugs. Furthermore, kernels ≥5.6 provide
the getrandom(GRND_INSECURE) interface for returning random bytes
before the entropy pool is initialized without warning into kmsg,
which is what we attempt to use if available. systemd's direct usage
of RDRAND has been removed. x86 systems ≥Broadwell that are running
an older kernel may experience kmsg warnings that were not seen with
250. For newer kernels, non-x86 systems, or older x86 systems, there
should be no visible changes.
* sd-boot will now measure the kernel command line into TPM PCR 12
rather than PCR 8. This improves usefulness of the measurements on
systems where sd-boot is chainloaded from Grub. Grub measures all
commands its executes into PCR 8, which makes it very hard to use
reasonably, hence separate ourselves from that and use PCR 12
instead, which is what certain Ubuntu editions already do. To retain
compatibility with systems running older systemd systems a new meson
option 'efi-tpm-pcr-compat' has been added (which defaults to false).
If enabled, the measurement is done twice: into the new-style PCR 12
*and* the old-style PCR 8. It's strongly advised to migrate all users
to PCR 12 for this purpose in the long run, as we intend to remove
this compatibility feature in two year's time.
* busctl capture now writes output in the newer pcapng format instead
of pcap.
* An udev rule that imported hwdb matches for USB devices with
lowercase hexadecimal vendor/product ID digits was added in systemd
250. This has been reverted, since uppercase hexadecimal digits are
supposed to be used, and we already had a rule that with the
appropriate match.
Users might need to adjust their local hwdb entries.
* arch_prctl(2) has been moved to the @default set in the syscall
filters
(as exposed via the SystemCallFilter= setting in service unit files).
It is apparently used by the linker now.
* The tmpfiles entries that create the /run/systemd/netif directory and
its subdirectories were moved from tmpfiles.d/systemd.conf to
tmpfiles.d/systemd-network.conf.
Users might need to adjust their files that override
tmpfiles.d/systemd.conf
to account for this change.
Changes in the Boot Loader Specification, kernel-install and sd-boot:
* kernel-install's and bootctl's B
[systemd-devel] systemd prerelease 251-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v251-rc1.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: Backwards-incompatible changes: * The minimum kernel version required has been bumped from 3.13 to 3.15, and CLOCK_BOOTTIME is now assumed to always exist. * In v250, a systemd-networkd feature that automatically configures routes to addresses specified in AllowedIPs= was added and enabled by default. However, this causes network connectivity issues in many existing setups. Hence, it has been disabled by default since systemd-stable 250.3. The feature can still be used by explicitly configuring RouteTable= setting in .netdev files. * Jobs started via StartUnitWithFlags() will no longer return 'skipped' when a Condition*= check does not succeed, restoring the JobRemoved signal to the behaviour it had before v250. * The org.freedesktop.portable1 methods GetMetadataWithExtensions() and GetImageMetadataWithExtensions() have been fixed to provide an extra return parameter, containing the actual extension release metadata. The current implementation was judged to be broken and unusable, and thus the usual procedure of adding a new set of methods was skipped, and backward compatibility broken instead on the assumption that nobody can be affected given the current state of this interface. * All kernels supported by systemd mix RDRAND (or similar) into the entropy pool at early boot. This means that on those systems, even if /dev/urandom is not yet initialized, it still returns bytes that that are at least as high quality as RDRAND. For that reason, we no longer have reason to invoke RDRAND from systemd itself, which has historically been a source of bugs. Furthermore, kernels ≥5.6 provide the getrandom(GRND_INSECURE) interface for returning random bytes before the entropy pool is initialized without warning into kmsg, which is what we attempt to use if available. systemd's direct usage of RDRAND has been removed. x86 systems ≥Broadwell that are running an older kernel may experience kmsg warnings that were not seen with 250. For newer kernels, non-x86 systems, or older x86 systems, there should be no visible changes. * sd-boot will now measure the kernel command line into TPM PCR 12 rather than PCR 8. This improves usefulness of the measurements on systems where sd-boot is chainloaded from Grub. Grub measures all commands its executes into PCR 8, which makes it very hard to use reasonably, hence separate ourselves from that and use PCR 12 instead, which is what certain Ubuntu editions already do. To retain compatibility with systems running older systemd systems a new meson option 'efi-tpm-pcr-compat' has been added (which defaults to false). If enabled, the measurement is done twice: into the new-style PCR 12 *and* the old-style PCR 8. It's strongly advised to migrate all users to PCR 12 for this purpose in the long run, as we intend to remove this compatibility feature in two year's time. * busctl capture now writes output in the newer pcapng format instead of pcap. * An udev rule that imported hwdb matches for USB devices with lowercase hexadecimal vendor/product ID digits was added in systemd 250. This has been reverted, since uppercase hexadecimal digits are supposed to be used, and we already had a rule that with the appropriate match. Users might need to adjust their local hwdb entries. * arch_prctl(2) has been moved to the @default set in the syscall filters (as exposed via the SystemCallFilter= setting in service unit files). It is apparently used by the linker now. Changes in the Boot Loader Specification, kernel-install and sd-boot: * kernel-install's and bootctl's Boot Loader Specification Type #1 entry generation logic has been reworked. The user may now pick explicitly by which "token" string to name the installation's boot entries, via the new /etc/kernel/entry-token file or the new --entry-token= switch to bootctl. By default — as before — the entries are named after the local machine ID. However, in "golden image" environments, where the machine ID
[systemd-devel] systemd 250 released
A new, official systemd release has just been tagged . Please download the tarball here: https://github.com/systemd/systemd/archive/v250.tar.gz Changes since the previous release: * Support for encrypted and authenticated credentials has been added. This extends the credential logic introduced with v247 to support non-interactive symmetric encryption and authentication, based on a key that is stored on the /var/ file system or in the TPM2 chip (if available), or the combination of both (by default if a TPM2 chip exists the combination is used, otherwise the /var/ key only). The credentials are automatically decrypted at the moment a service is started, and are made accessible to the service itself in unencrypted form. A new tool 'systemd-creds' encrypts credentials for this purpose, and two new service file settings LoadCredentialEncrypted= and SetCredentialEncrypted= configure such credentials. This feature is useful to store sensitive material such as SSL certificates, passwords and similar securely at rest and only decrypt them when needed, and in a way that is tied to the local OS installation or hardware. * systemd-gpt-auto-generator can now automatically set up discoverable LUKS2 encrypted swap partitions. * The GPT Discoverable Partitions Specification has been substantially extended with support for root and /usr/ partitions for the majority of architectures systemd supports. This includes platforms that do not natively support UEFI, because even though GPT is specified under UEFI umbrella, it is useful on other systems too. Specifically, systemd-nspawn, systemd-sysext, systemd-gpt-auto-generator and Portable Services use the concept without requiring UEFI. * The GPT Discoverable Partitions Specifications has been extended with a new set of partitions that may carry PKCS#7 signatures for Verity partitions, encoded in a simple JSON format. This implements a simple mechanism for building disk images that are fully authenticated and can be tested against a set of cryptographic certificates. This is now implemented for the various systemd tools that can operate with disk images, such as systemd-nspawn, systemd-sysext, systemd-dissect, Portable services/RootImage=, systemd-tmpfiles, and systemd-sysusers. The PKCS#7 signatures are passed to the kernel (where they are checked against certificates from the kernel keyring), or can be verified against certificates provided in userspace (via a simple drop-in file mechanism). * systemd-dissect's inspection logic will now report for which uses a disk image is intended. Specifically, it will display whether an image is suitable for booting on UEFI or in a container (using systemd-nspawn's --image= switch), whether it can be used as portable service, or attached as system extension. * The system-extension.d/ drop-in files now support a new field SYSEXT_SCOPE= that may encode which purpose a system extension image is for: one of "initrd", "system" or "portable". This is useful to make images more self-descriptive, and to ensure system extensions cannot be attached in the wrong contexts. * The os-release file learnt a new PORTABLE_PREFIXES= field which may be used in portable service images to indicate which unit prefixes are supported. * The GPT image dissection logic in systemd-nspawn/systemd-dissect/… now is able to decode images for non-native architectures as well. This allows systemd-nspawn to boot images of non-native architectures if the corresponding user mode emulator is installed and systemd-binfmtd is running. * systemd-logind gained new settings HandlePowerKeyLongPress=, HandleRebootKeyLongPress=, HandleSuspendKeyLongPress= and HandleHibernateKeyLongPress= which may be used to configure actions when the relevant keys are pressed for more than 5s. This is useful on devices that only have hardware for a subset of these keys. By default, if the reboot key is pressed long the poweroff operation is now triggered, and when the suspend key is pressed long the hibernate operation is triggered. Long pressing the other two keys currently does not trigger any operation by default. * When showing unit status updates on the console during boot and shutdown, and a service is slow to start so that the cylon animation is shown, the most recent sd_notify() STATUS= text is now sho
[systemd-devel] systemd prerelease 250-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v250-rc3.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * Support for encrypted and authenticated credentials has been added. This extends the credential logic introduced with v247 to support non-interactive symmetric encryption and authentication, based on a key that is stored on the /var/ file system or in the TPM2 chip (if available), or the combination of both (by default if a TPM2 chip exists the combination is used, otherwise the /var/ key only). The credentials are automatically decrypted at the moment a service is started, and are made accessible to the service itself in unencrypted form. A new tool 'systemd-creds' encrypts credentials for this purpose, and two new service file settings LoadCredentialEncrypted= and SetCredentialEncrypted= configure such credentials. This feature is useful to store sensitive material such as SSL certificates, passwords and similar securely at rest and only decrypt them when needed, and in a way that is tied to the local OS installation or hardware. * systemd-gpt-auto-generator can now automatically set up discoverable LUKS2 encrypted swap partitions. * The GPT Discoverable Partitions Specification has been substantially extended with support for root and /usr/ partitions for the majority of architectures systemd supports. This includes platforms that do not natively support UEFI, because even though GPT is specified under UEFI umbrella, it is useful on other systems too. Specifically, systemd-nspawn, systemd-sysext, systemd-gpt-auto-generator and Portable Services use the concept without requiring UEFI. * The GPT Discoverable Partitions Specifications has been extended with a new set of partitions that may carry PKCS#7 signatures for Verity partitions, encoded in a simple JSON format. This implements a simple mechanism for building disk images that are fully authenticated and can be tested against a set of cryptographic certificates. This is now implemented for the various systemd tools that can operate with disk images, such as systemd-nspawn, systemd-sysext, systemd-dissect, Portable services/RootImage=, systemd-tmpfiles, and systemd-sysusers. The PKCS#7 signatures are passed to the kernel (where they are checked against certificates from the kernel keyring), or can be verified against certificates provided in userspace (via a simple drop-in file mechanism). * systemd-dissect's inspection logic will now report for which uses a disk image is intended. Specifically, it will display whether an image is suitable for booting on UEFI or in a container (using systemd-nspawn's --image= switch), whether it can be used as portable service, or attached as system extension. * The system-extension.d/ drop-in files now support a new field SYSEXT_SCOPE= that may encode which purpose a system extension image is for: one of "initrd", "system" or "portable". This is useful to make images more self-descriptive, and to ensure system extensions cannot be attached in the wrong contexts. * The os-release file learnt a new PORTABLE_PREFIXES= field which may be used in portable service images to indicate which unit prefixes are supported. * The GPT image dissection logic in systemd-nspawn/systemd-dissect/… now is able to decode images for non-native architectures as well. This allows systemd-nspawn to boot images of non-native architectures if the corresponding user mode emulator is installed and systemd-binfmtd is running. * systemd-logind gained new settings HandlePowerKeyLongPress=, HandleRebootKeyLongPress=, HandleSuspendKeyLongPress= and HandleHibernateKeyLongPress= which may be used to configure actions when the relevant keys are pressed for more than 5s. This is useful on devices that only have hardware for a subset of these keys. By default, if the reboot key is pressed long the poweroff operation is now triggered, and when the suspend key is pressed long the hibernate operation is triggered. Long pressing the other two keys currently does not trigger any operation by default.
[systemd-devel] systemd prerelease 250-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v250-rc2.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * Support for encrypted and authenticated credentials has been added. This extends the credential logic introduced with v247 to support non-interactive symmetric encryption and authentication, based on a key that is stored on the /var/ file system or in the TPM2 chip (if available), or the combination of both (by default if a TPM2 chip exists the combination is used, otherwise the /var/ key only). The credentials are automatically decrypted at the moment a service is started, and are made accessible to the service itself in unencrypted form. A new tool 'systemd-creds' encrypts credentials for this purpose, and two new service file settings LoadCredentialEncrypted= and SetCredentialEncrypted= configure such credentials. This feature is useful to store sensitive material such as SSL certificates, passwords and similar securely at rest and only decrypt them when needed, and in a way that is tied to the local OS installation or hardware. * systemd-gpt-auto-generator can now automatically set up discoverable LUKS2 encrypted swap partitions. * The GPT Discoverable Partitions Specification has been substantially extended with support for root and /usr/ partitions for the majority of architectures systemd supports. This includes platforms that do not natively support UEFI, because even though GPT is specified under UEFI umbrella, it is useful on other systems too. Specifically, systemd-nspawn, systemd-sysext, systemd-gpt-auto-generator and Portable Services use the concept without requiring UEFI. * The GPT Discoverable Partitions Specifications has been extended with a new set of partitions that may carry PKCS#7 signatures for Verity partitions, encoded in a simple JSON format. This implements a simple mechanism for building disk images that are fully authenticated and can be tested against a set of cryptographic certificates. This is now implemented for the various systemd tools that can operate with disk images, such as systemd-nspawn, systemd-sysext, systemd-dissect, Portable services/RootImage=, systemd-tmpfiles, and systemd-sysusers. The PKCS#7 signatures are passed to the kernel (where they are checked against certificates from the kernel keyring), or can be verified against certificates provided in userspace (via a simple drop-in file mechanism). * systemd-dissect's inspection logic will now report for which uses a disk image is intended. Specifically, it will display whether an image is suitable for booting on UEFI or in a container (using systemd-nspawn's --image= switch), whether it can be used as portable service, or attached as system extension. * The system-extension.d/ drop-in files now support a new field SYSEXT_SCOPE= that may encode which purpose a system extension image is for: one of "initrd", "system" or "portable". This is useful to make images more self-descriptive, and to ensure system extensions cannot be attached in the wrong contexts. * The os-release file learnt a new PORTABLE_PREFIXES= field which may be used in portable service images to indicate which unit prefixes are supported. * The GPT image dissection logic in systemd-nspawn/systemd-dissect/… now is able to decode images for non-native architectures as well. This allows systemd-nspawn to boot images of non-native architectures if the corresponding user mode emulator is installed and systemd-binfmtd is running. * systemd-logind gained new settings HandlePowerKeyLongPress=, HandleRebootKeyLongPress=, HandleSuspendKeyLongPress= and HandleHibernateKeyLongPress= which may be used to configure actions when the relevant keys are pressed for more than 5s. This is useful on devices that only have hardware for a subset of these keys. By default, if the reboot key is pressed long the poweroff operation is now triggered, and when the suspend key is pressed long the hibernate operation is triggered. Long pressing the other two keys currently does not trigger any operation by default.
[systemd-devel] systemd prerelease 250-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v250-rc1.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * Support for encrypted and authenticated credentials has been added. This extends the credential logic introduced with v247 to support non-interactive symmetric encryption and authentication, based on a key that is stored on the /var/ file system or in the TPM2 chip (if available), or the combination of both (by default if a TPM2 chip exists the combination is used, otherwise the /var/ key only). The credentials are automatically decrypted at the moment a service is started, and are made accessible to the service itself in unencrypted form. A new tool 'systemd-creds' encrypts credentials for this purpose, and two new service file settings LoadCredentialEncrypted= and SetCredentialEncrypted= configure such credentials. This feature is useful to store sensitive material such as SSL certificates, passwords and similar securely at rest and only decrypt them when needed, and in a way that is tied to the local OS installation or hardware. * systemd-gpt-auto-generator can now automatically set up discoverable LUKS2 encrypted swap partitions. * The GPT Discoverable Partitions Specification has been substantially extended with support for root and /usr/ partitions for the majority of architectures systemd supports. This includes platforms that do not natively support UEFI, because even though GPT is specified under UEFI umbrella, it is useful on other systems too. Specifically, systemd-nspawn, systemd-sysext, systemd-gpt-auto-generator and Portable Services use the concept without requiring UEFI. * The GPT Discoverable Partitions Specifications has been extended with a new set of partitions that may carry PKCS#7 signatures for Verity partitions, encoded in a simple JSON format. This implements a simple mechanism for building disk images that are fully authenticated and can be tested against a set of cryptographic certificates. This is now implemented for the various systemd tools that can operate with disk images, such as systemd-nspawn, systemd-sysext, systemd-dissect, Portable services/RootImage=, systemd-tmpfiles, and systemd-sysusers. The PKCS#7 signatures are passed to the kernel (where they are checked against certificates from the kernel keyring), or can be verified against certificates provided in userspace (via a simple drop-in file mechanism). * systemd-dissect's inspection logic will now report for which uses a disk image is intended. Specifically, it will display whether an image is suitable for booting on UEFI or in a container (using systemd-nspawn's --image= switch), whether it can be used as portable service, or attached as system extension. * The system-extension.d/ drop-in files now support a new field SYSEXT_SCOPE= that may encode which purpose a system extension image is for: one of "initrd", "system" or "portable". This is useful to make images more self-descriptive, and to ensure system extensions cannot be attached in the wrong contexts. * The os-release file learnt a new PORTABLE_PREFIXES= field which may be used in portable service images to indicate which unit prefixes are supported. * The GPT image dissection logic in systemd-nspawn/systemd-dissect/… now is able to decode images for non-native architectures as well. This allows systemd-nspawn to boot images of non-native architectures if the corresponding user mode emulator is installed and systemd-binfmtd is running. * systemd-logind gained new settings HandlePowerKeyLongPress=, HandleRebootKeyLongPress=, HandleSuspendKeyLongPress= and HandleHibernateKeyLongPress= which may be used to configure actions when the relevant keys are pressed for more than 5s. This is useful on devices that only have hardware for a subset of these keys. By default, if the reboot key is pressed long the poweroff operation is now triggered, and when the suspend key is pressed long the hibernate operation is triggered. Long pressing the other two keys currently does not trigger any operation by default.
Re: [systemd-devel] give unprivileged nspawn container write access to host wayland socket
Hey Nozz, I've tried the exact same setup and run into this problem. I've explained it a bit better here[1]. Since the linux kernel 5.12 there are filesystem id mappings that can be used for that in combination with --private-users=pick. I've written the pull request[0] to include support in nspawn for that. In my opinion this is the best way to share such a socket. There is not yet a systemd release containing the pull request. I'm not sure if the tempfs, where I guess your socket is located, implementation in linux does yet support those mappings, last time I checked (when I wrote the pull request) it didn't. Yes support for filesystem id mappings depends on the source filesystem. You could solve this by moving the socket to another location, for example an ext4 filesystem, until tmpfs supports it as well. Alternatively you could use extended acls for that. Another option would be to allow access for "other" on the socket, but not the parent folder, and use --bind as is. Best regards, nd [0] https://github.com/systemd/systemd/pull/19828 [1] https://lists.freedesktop.org/archives/systemd-devel/2021-May/046503.html OpenPGP_signature Description: OpenPGP digital signature
[systemd-devel] systemd 249 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v249.tar.gz
Changes since the previous release:
* When operating on disk images via the --image= switch of various
tools (such as systemd-nspawn or systemd-dissect), or when udev finds
no 'root=' parameter on the kernel command line, and multiple
suitable root or /usr/ partitions exist in the image, then a simple
comparison inspired by strverscmp() is done on the GPT partition
label, and the newest partition is picked. This permits a simple and
generic whole-file-system A/B update logic where new operating system
versions are dropped into partitions whose label is then updated with
a matching version identifier.
* systemd-sysusers now supports querying the passwords to set for the
users it creates via the "credentials" logic introduced in v247: the
passwd.hashed-password. and passwd.plaintext-password.
credentials are consulted for the password to use (either in UNIX
hashed form, or literally). By default these credentials are inherited
down from PID1 (which in turn imports it from a container manager if
there is one). This permits easy configuration of user passwords
during first boot. Example:
# systemd-nspawn -i foo.raw --volatile=yes
--set-credential=passwd.plaintext-password.root:foo
Note that systemd-sysusers operates in purely additive mode: it
executes no operation if the declared users already exist, and hence
doesn't set any passwords as effect of the command line above if the
specified root user exists already in the image. (Note that
--volatile=yes ensures it doesn't, though.)
* systemd-firstboot now also supports querying various system
parameters via the credential subsystems. Thus, as above this may be
used to initialize important system parameters on first boot of
previously unprovisioned images (i.e. images with a mostly empty
/etc/).
* PID 1 may now show both the unit name and the unit description
strings in its status output during boot. This may be configured with
StatusUnitFormat=combined in system.conf or
systemd.status-unit-format=combined on the kernel command line.
* The systemd-machine-id-setup tool now supports a --image= switch for
provisioning a machine ID file into an OS disk image, similar to how
--root= operates on an OS file tree. This matches the existing switch
of the same name for systemd-tmpfiles, systemd-firstboot, and
systemd-sysusers tools.
* Similarly, systemd-repart gained support for the --image= switch too.
In combination with the existing --size= option, this makes the tool
particularly useful for easily growing disk images in a single
invocation, following the declarative rules included in the image
itself.
* systemd-repart's partition configuration files gained support for a
new switch MakeDirectories= which may be used to create arbitrary
directories inside file systems that are created, before registering
them in the partition table. This is useful in particular for root
partitions to create mount point directories for other partitions
included in the image. For example, a disk image that contains a
root, /home/, and /var/ partitions, may set MakeDirectories=yes to
create /home/ and /var/ as empty directories in the root file system
on its creation, so that the resulting image can be mounted
immediately, even in read-only mode.
* systemd-repart's CopyBlocks= setting gained support for the special
value "auto". If used, a suitable matching partition on the booted OS
is found as source to copy blocks from. This is useful when
implementing replicating installers, that are booted from one medium
and then stream their own root partition onto the target medium.
* systemd-repart's partition configuration files gained support for a
Flags=, a ReadOnly= and a NoAuto= setting, allowing control of these
GPT partition flags for the created partitions: this is useful for
marking newly created partitions as read-only, or as not being
subject for automatic mounting from creation on.
* The /etc/os-release file has been extended with two new (optional)
variables IMAGE_VERSION= and IMAGE_ID=, carrying identity and version
information for OS images that are updated comprehensively and
atomically as one image. Two new specifiers %M, %A now resolve to
[systemd-devel] systemd prerelease 249-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v249-rc3.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* When operating on disk images via the --image= switch of various
tools (such as systemd-nspawn or systemd-dissect), and multiple
suitable root or /usr/ partitions exist in the image, then a simple
comparison inspired by strverscmp() is done on the GPT partition
label, and the newest partition is picked. This permits a simple and
generic whole-file-system A/B update logic where new operating system
versions are dropped into partitions whose label is then updated with
a matching version identifier.
* systemd-sysusers now supports querying the passwords to set for the
users it creates via the "credentials" logic introduced in v247: the
passwd.hashed-password. and passwd.plaintext-password.
credentials are consulted for the password to use (either in UNIX
hashed form, or literally). By default these credentials are inherited
down from PID1 (which in turn imports it from a container manager if
there is one). This permits easy configuration of user passwords
during first boot. Example:
# systemd-nspawn -i foo.raw --volatile=yes
--set-credential=passwd.plaintext-password.root:foo
Note that systemd-sysusers operates in purely additive mode: it
executes no operation if the declared users already exist, and hence
doesn't set any passwords as effect of the command line above if the
specified root user exists already in the image. (Note that
--volatile=yes ensures it doesn't, though.)
* systemd-firstboot now also supports querying various system
parameters via the credential subsystems. Thus, as above this may be
used to initialize important system parameters on first boot of
previously unprovisioned images (i.e. images with a mostly empty
/etc/).
* PID 1 may now show both the unit name and the unit description
strings in its status output during boot. This may be configured with
StatusUnitFormat=combined in system.conf or
systemd.status-unit-format=combined on the kernel command line.
* The systemd-machine-id-setup tool now supports a --image= switch for
provisioning a machine ID file into an OS disk image, similar to how
--root= operates on an OS file tree. This matches the existing switch
of the same name for systemd-tmpfiles, systemd-firstboot, and
systemd-sysusers tools.
* Similarly, systemd-repart gained support for the --image= switch too.
In combination with the existing --size= option, this makes the tool
particularly useful for easily growing disk images in a single
invocation, following the declarative rules included in the image
itself.
* systemd-repart's partition configuration files gained support for a
new switch MakeDirectories= which may be used to create arbitrary
directories inside file systems that are created, before registering
them in the partition table. This is useful in particular for root
partitions to create mount point directories for other partitions
included in the image. For example, a disk image that contains a
root, /home/, and /var/ partitions, may set MakeDirectories=yes to
create /home/ and /var/ as empty directories in the root file system
on its creation, so that the resulting image can be mounted
immediately, even in read-only mode.
* systemd-repart's CopyBlocks= setting gained support for the special
value "auto". If used, a suitable matching partition on the booted OS
is found as source to copy blocks from. This is useful when
implementing replicating installers, that are booted from one medium
and then stream their own root partition onto the target medium.
* systemd-repart's partition configuration files gained support for a
Flags=, a ReadOnly= and a NoAuto= setting, allowing control of these
GPT partition flags for the created partitions: this is useful for
marking newly created partitions as read-only, or as not being
subject for automatic mounting from creation on.
* The /etc/os-release file has been extended with two new (optional)
variables IMAGE_VERSION= and IMAGE_ID=, carrying identity and version
infor
[systemd-devel] systemd prerelease 249-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v249-rc2.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* When operating on disk images via the --image= switch of various
tools (such as systemd-nspawn or systemd-dissect), and multiple
suitable root or /usr/ partitions exist in the image, then a simple
comparison inspired by strverscmp() is done on the GPT partition
label, and the newest partition is picked. This permits a simple and
generic whole-file-system A/B update logic where new operating system
versions are dropped into partitions whose label is then updated with
a matching version identifier.
* systemd-sysusers now supports querying the passwords to set for the
users it creates via the "credentials" logic introduced in v247: the
passwd.hashed-password. and passwd.plaintext-password.
credentials are consulted for the password to use (either in UNIX
hashed form, or literally). By default these credentials are inherited
down from PID1 (which in turn imports it from a container manager if
there is one). This permits easy configuration of user passwords
during first boot. Example:
# systemd-nspawn -i foo.raw --volatile=yes
--set-credential=passwd.plaintext-password.root:foo
Note that systemd-sysusers operates in purely additive mode: it
executes no operation if the declared users already exist, and hence
doesn't set any passwords as effect of the command line above if the
specified root user exists already in the image. (Note that
--volatile=yes ensures it doesn't, though.)
* systemd-firstboot now also supports querying various system
parameters via the credential subsystems. Thus, as above this may be
used to initialize important system parameters on first boot of
previously unprovisioned images (i.e. images with a mostly empty
/etc/).
* Services gained a new ExitType= setting which can configure how to
determine when a service exited: the default is "main" which defines
the runtime by the service's main process lifetime (this matches the
only behaviour implemented in v248 and before), but with "cgroup" the
runtime is defined by the existence of any process in the service's
cgroup.
* The systemd-machine-id-setup tool now supports a --image= switch for
provisioning a machine ID file into an OS disk image, similar to how
--root= operates on an OS file tree. This matches the existing switch
of the same name for systemd-tmpfiles, systemd-firstboot, and
systemd-sysusers tools.
* Similarly, systemd-repart gained support for the --image= switch too.
In combination with the existing --size= option, this makes the tool
particularly useful for easily growing disk images in a single
invocation, following the declarative rules included in the image
itself.
* systemd-repart's partition configuration files gained support for a
new switch MakeDirectories= which may be used to create arbitrary
directories inside file systems that are created, before registering
them in the partition table. This is useful in particular for root
partitions to create mount point directories for other partitions
included in the image. For example, a disk image that contains a
root, /home/, and /var/ partitions, may set MakeDirectories=yes to
create /home/ and /var/ as empty directories in the root file system
on its creation, so that the resulting image can be mounted
immediately, even in read-only mode.
* systemd-repart's CopyBlocks= setting gained support for the special
value "auto". If used, a suitable matching partition on the booted OS
is found as source to copy blocks from. This is useful when
implementing replicating installers, that are booted from one medium
and then stream their own root partition onto the target medium.
* systemd-repart's partition configuration files gained support for a
Flags= and a ReadOnly= setting, allowing control of the GPT partition
flags for the created partitions: this is useful for marking newly
created partitions as read-only from the start.
* The /etc/os-release file has been extended with two new (optional)
variables IMAGE_V
[systemd-devel] systemd prerelease 249-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v249-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* When operating on disk images via the --image= switch of various
tools (such as systemd-nspawn or systemd-dissect), and multiple
suitable root or /usr/ partitions exist in the image, then a simple
comparison inspired by strverscmp() is done on the GPT partition
label, and the newest partition is picked. This permits a simple and
generic whole-file-system A/B update logic where new operating system
versions are dropped into partitions whose label is then updated with
a matching version identifier.
* systemd-sysusers now supports querying the passwords to set for the
users it creates via the "credentials" logic introduced in v247: the
passwd.hashed-password. and passwd.plaintext-password.
credentials are consulted for the password to use (either in UNIX
hashed form, or literally). By default these credentials are inherited
down from PID1 (which in turn imports it from a container manager if
there is one). This permits easy configuration of user passwords
during first boot. Example:
# systemd-nspawn -i foo.raw --volatile=yes
--set-credential=passwd.plaintext-password.root:foo
Note that systemd-sysusers operates in purely additive mode: it
executes no operation if the declared users already exist, and hence
doesn't set any passwords as effect of the command line above if the
specified root user exists already in the image. (Note that
--volatile=yes ensures it doesn't, though.)
* systemd-firstboot now also supports querying various system
parameters via the credential subsystems. Thus, as above this may be
used to initialize important system parameters on first boot of
previously unprovisioned images (i.e. images with a mostly empty
/etc/).
* Services gained a new ExitType= setting which can configure how to
determine when a service exited: the default is "main" which defines
the runtime by the service's main process lifetime (this matches the
only behaviour implemented in v248 and before), but with "cgroup" the
runtime is defined by the existence of any process in the service's
cgroup.
* The systemd-machine-id-setup tool now supports a --image= switch for
provisioning a machine ID file into an OS disk image, similar to how
--root= operates on an OS file tree. This matches the existing switch
of the same name for systemd-tmpfiles, systemd-firstboot, and
systemd-sysusers tools.
* Similarly, systemd-repart gained support for the --image= switch too.
In combination with the existing --size= option, this makes the tool
particularly useful for easily growing disk images in a single
invocation, following the declarative rules included in the image
itself.
* systemd-repart's partition configuration files gained support for a
new switch MakeDirectories= which may be used to create arbitrary
directories inside file systems that are created, before registering
them in the partition table. This is useful in particular for root
partitions to create mount point directories for other partitions
included in the image. For example, a disk image that contains a
root, /home/, and /var/ partitions, may set MakeDirectories=yes to
create /home/ and /var/ as empty directories in the root file system
on its creation, so that the resulting image can mounted immediately,
even in read-only mode.
* systemd-repart's CopyBlocks= setting gained support for the special
value "auto". If used, a suitable matching partition on the booted OS
is found as source to copy blocks from. This is useful when
implementing replicating installers, that are booted from one medium
and then stream their own root partition onto the target medium.
* systemd-repart's partition configuration files gained support for a
Flags= and a ReadOnly= setting, allowing control of the GPT partition
flags for the created partitions: this is useful for marking newly
created partitions as read-only from the start.
* The /etc/os-release file has been extended with two new (optional)
variables IMAGE_V
Re: [systemd-devel] systemd-nspawn with filesystem id mapping
Hi again, after some more debugging this EOVERFLOW seems to be the result of a call to may_o_create in fs/namei.c in the kernel. There is a check: if (!fsuidgid_has_mapping(dir->dentry->d_sb, mnt_userns)) return -EOVERFLOW; This seems to be the one returning EOVERFLOW to nspawn and resulting in the container spawn to fail. My guess would be that this is a systemd bug when combining filesystem id mapping with --bind. Before I start spending more time debugging this, has anyone so far used --bind with --private-users=pick and --private-users-ownership=map successfull? As far as I understand the pull request #19438 , didn't add any handling to the mount_bind function. Was this maybe overlooked? In my understanding there is a remount_idmap missing in that function well as the touch needs to be done in the correct user namespace or with mapped uid/gids. I'm new to the systemd source code, could somebody confirm that I'm on the right track there and not heading in the wrong direction? Thanks, nd OpenPGP_signature Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn with filesystem id mapping
Hi!
I was very pleased to see the "nspawn: add support for kernel 5.12 ID mapping
mounts #19438"-pull request and went right at it to try it out.
The following was tested on the current git head of systemd running on
archlinux.
What I try to achieve on a high level is kind of emulating bubblewrap and
executing chromium under wayland with gpu acceleration and working audio using
PipeWire.
For that I need to pass some sockets and devices to the container using
--bind-ro . I want to use --private-users=pick to have easier separation
between multiple Containers.
That means I do not know the running uid of the process before nspawn spawns my
container. That results on problems accessing the sockets.
Until now I used setfacl to work around this limitation and allow access to the
sockets.
I was hoping to be able to skip that with --private-users-ownership=map .
I'm passing three sockets belonging to uid 1000 on the host to a container with
private-users=pick and and try to access it via uid 1000 (name "user") in the
container.
Everything is happening on an ext4 file system. I'd prefer btrfs but that is
(so far) lacking id mapping support.
The full call looks like that:
statepath="/machines/state/chromium/${profilename}"
systemd-nspawn \
-D /machines/images/archlinux-chromium/ \
--private-users=pick \
--private-users-ownership=map \
--no-new-privileges=yes \
--as-pid2 \
--machine "chromium-${profilename}" \
--user user \
--bind-ro /var/run/user/1000/pulse/native:/sockets/pulse/native \
--bind-ro /var/run/user/1000/wayland-1:/sockets/wayland-1 \
--bind-ro /var/run/user/1000/pipewire-0:/sockets/pipewire-0 \
--bind "${statepath}:/home/user" \
--bind /dev/dri/renderD128 \
-E WAYLAND_DISPLAY=wayland-1 \
-E XDG_RUNTIME_DIR=/sockets \
chromium --enable-features=UseOzonePlatform --ozone-platform=wayland
This results in the following output:
Spawning container chromium-default on /machines/images/archlinux-chromium.
Press ^] three times within 1s to kill container.
Selected user namespace base 552206336 and range 65536.
Failed to create mount point
/machines/images/archlinux-chromium/sockets/pipewire-0: Value too large for
defined data type
I've run strace on it, this results in the following relevant output:
[pid 524] mount("/machines/state/chromium/default", "/proc/self/fd/8", NULL,
MS_BIND|MS_REC, NULL) = 0
[pid 524] close(8)= 0
[pid 524] newfstatat(AT_FDCWD, "/var/run/user/1000/pipewire-0",
{st_mode=S_IFSOCK|0666, st_size=0, ...}, 0) = 0
[pid 524] openat(AT_FDCWD, "/machines/images/archlinux-chromium",
O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = 8
[pid 524] openat(8, "sockets", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 10
[pid 524] newfstatat(10, "", {st_mode=S_IFDIR|0700, st_size=4096, ...},
AT_EMPTY_PATH) = 0
[pid 524] close(8)= 0
[pid 524] openat(10, "pipewire-0", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = -1
ENOENT (No such file or directory
)
[pid 524] close(10) = 0
[pid 524] newfstatat(AT_FDCWD, "/machines/images/archlinux-chromium/sockets",
{st_mode=S_IFDIR|0700, st_size=40
96, ...}, 0) = 0
[pid 524] openat(AT_FDCWD,
"/machines/images/archlinux-chromium/sockets/pipewire-0",
O_RDONLY|O_NOFOLLOW|O_CLOE
XEC|O_PATH) = -1 ENOENT (No such file or directory)
[pid 524] openat(AT_FDCWD,
"/machines/images/archlinux-chromium/sockets/pipewire-0",
O_WRONLY|O_CREAT|O_EXCL|O_
CLOEXEC, 0644) = -1 EOVERFLOW (Value too large for defined data type)
[pid 524] writev(2, [{iov_base="Failed to create mount point /ma"...,
iov_len=122}, {iov_base="\n", iov_len=1}]
, 2Failed to create mount point
/machines/images/archlinux-chromium/sockets/pipewire-0: Value too large for
defin
ed data type
) = 123
This maps to the touch in nspawn-mount.c at line 754.
If I skip the --bind(-ro) part this works fine (except chromium of course not
working), same if I keep the binds and remove the --private-users-ownership=map.
I'm kind of lost on how to go on about this issue at this point.
Have I made a mistake or wrong assumption about how that should work?
Should I open an issue on github about that?
Thanks,
nd
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 248 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v248.tar.gz
Changes since the previous release:
* A concept of system extension images is introduced. Such images may
be used to extend the /usr/ and /opt/ directory hierarchies at
runtime with additional files (even if the file system is read-only).
When a system extension image is activated, its /usr/ and /opt/
hierarchies and os-release information are combined via overlayfs
with the file system hierarchy of the host OS.
A new systemd-sysext tool can be used to merge, unmerge, list, and
refresh system extension hierarchies. See
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html.
The systemd-sysext.service automatically merges installed system
extensions during boot (before basic.target, but not in very early
boot, since various file systems have to be mounted first).
The SYSEXT_LEVEL= field in os-release(5) may be used to specify the
supported system extension level.
* A new ExtensionImages= unit setting can be used to apply the same
system extension image concept from systemd-sysext to the namespaced
file hierarchy of specific services, following the same rules and
constraints.
* Support for a new special "root=tmpfs" kernel command-line option has
been added. When specified, a tmpfs is mounted on /, and mount.usr=
should be used to point to the operating system implementation.
* A new configuration file /etc/veritytab may be used to configure
dm-verity integrity protection for block devices. Each line is in the
format "volume-name data-device hash-device roothash options",
similar to /etc/crypttab.
* A new kernel command-line option systemd.verity.root_options= may be
used to configure dm-verity behaviour for the root device.
* The key file specified in /etc/crypttab (the third field) may now
refer to an AF_UNIX/SOCK_STREAM socket in the file system. The key is
acquired by connecting to that socket and reading from it. This
allows the implementation of a service to provide key information
dynamically, at the moment when it is needed.
* When the hostname is set explicitly to "localhost", systemd-hostnamed
will respect this. Previously such a setting would be mostly silently
ignored. The goal is to honour configuration as specified by the
user.
* The fallback hostname that will be used by the system manager and
systemd-hostnamed can now be configured in two new ways: by setting
DEFAULT_HOSTNAME= in os-release(5), or by setting
$SYSTEMD_DEFAULT_HOSTNAME in the environment block. As before, it can
also be configured during compilation. The environment variable is
intended for testing and local overrides, the os-release(5) field is
intended to allow customization by different variants of a
distribution that share the same compiled packages.
* The environment block of the manager itself may be configured through
a new ManagerEnvironment= setting in system.conf or user.conf. This
complements existing ways to set the environment block (the kernel
command line for the system manager, the inherited environment and
user@.service unit file settings for the user manager).
* systemd-hostnamed now exports the default hostname and the source of
the configured hostname ("static", "transient", or "default") as
D-Bus properties.
* systemd-hostnamed now exports the "HardwareVendor" and
"HardwareModel" D-Bus properties, which are supposed to contain a
pair of cleaned up, human readable strings describing the system's
vendor and model. It's typically sourced from the firmware's DMI
tables, but may be augmented from a new hwdb database. hostnamectl
shows this in the status output.
* Support has been added to systemd-cryptsetup for extracting the
PKCS#11 token URI and encrypted key from the LUKS2 JSON embedded
metadata header. This allows the information how to open the
encrypted device to be embedded directly in the device and obviates
the need for configuration in an external file.
* systemd-cryptsetup gained support for unlocking LUKS2 volumes using
TPM2 hardware, as well as FIDO2 security tokens (in addition to the
pre-existing support for PKCS#11 security tokens).
* systemd-repart may enroll encrypted partitions using TPM
[systemd-devel] systemd prerelease 248-rc4
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v248-rc4.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* A concept of system extension images is introduced. Such images may
be used to extend the /usr/ and /opt/ directory hierarchies at
runtime with additional files (even if the file system is read-only).
When a system extension image is activated, its /usr/ and /opt/
hierarchies and os-release information are combined via overlayfs
with the file system hierarchy of the host OS.
A new systemd-sysext tool can be used to merge, unmerge, list, and
refresh system extension hierarchies. See
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html.
The systemd-sysext.service automatically merges installed system
extensions during boot (before basic.target, but not in very early
boot, since various file systems have to be mounted first).
The SYSEXT_LEVEL= field in os-release(5) may be used to specify the
supported system extension level.
* A new ExtensionImages= unit setting can be used to apply the same
system extension image concept from systemd-sysext to the namespaced
file hierarchy of specific services, following the same rules and
constraints.
* Support for a new special "root=tmpfs" kernel command-line option has
been added. When specified, a tmpfs is mounted on /, and mount.usr=
should be used to point to the operating system implementation.
* A new configuration file /etc/veritytab may be used to configure
dm-verity integrity protection for block devices. Each line is in the
format "volume-name data-device hash-device roothash options",
similar to /etc/crypttab.
* A new kernel command-line option systemd.verity.root_options= may be
used to configure dm-verity behaviour for the root device.
* The key file specified in /etc/crypttab (the third field) may now
refer to an AF_UNIX/SOCK_STREAM socket in the file system. The key is
acquired by connecting to that socket and reading from it. This
allows the implementation of a service to provide key information
dynamically, at the moment when it is needed.
* When the hostname is set explicitly to "localhost", systemd-hostnamed
will respect this. Previously such a setting would be mostly silently
ignored. The goal is to honour configuration as specified by the
user.
* The fallback hostname that will be used by the system manager and
systemd-hostnamed can now be configured in two new ways: by setting
DEFAULT_HOSTNAME= in os-release(5), or by setting
$SYSTEMD_DEFAULT_HOSTNAME in the environment block. As before, it can
also be configured during compilation. The environment variable is
intended for testing and local overrides, the os-release(5) field is
intended to allow customization by different variants of a
distribution that share the same compiled packages.
* The environment block of the manager itself may be configured through
a new ManagerEnvironment= setting in system.conf or user.conf. This
complements existing ways to set the environment block (the kernel
command line for the system manager, the inherited environment and
user@.service unit file settings for the user manager).
* systemd-hostnamed now exports the default hostname and the source of
the configured hostname ("static", "transient", or "default") as
D-Bus properties.
* systemd-hostnamed now exports the "HardwareVendor" and
"HardwareModel" D-Bus properties, which are supposed to contain a
pair of cleaned up, human readable strings describing the system's
vendor and model. It's typically sourced from the firmware's DMI
tables, but may be augmented from a new hwdb database. hostnamectl
shows this in the status output.
* Support has been added to systemd-cryptsetup for extracting the
PKCS#11 token URI and encrypted key from the LUKS2 JSON embedded
metadata header. This allows the information how to open the
encrypted device to be embedded directly in the device and obviates
the need for configuration in an external file.
* systemd-cryptsetup gained support for unlocking LUKS2 volu
[systemd-devel] systemd prerelease 248-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v248-rc3.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* A concept of system extension images is introduced. Such images may
be used to extend the /usr/ and /opt/ directory hierarchies at
runtime with additional files (even if the file system is read-only).
When a system extension image is activated, its /usr/ and /opt/
hierarchies and os-release information are combined via overlayfs
with the file system hierarchy of the host OS.
A new systemd-sysext tool can be used to merge, unmerge, list, and
refresh system extension hierarchies. See
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html.
The systemd-sysext.service automatically merges installed system
extensions during boot (before basic.target, but not in very early
boot, since various file systems have to be mounted first).
The SYSEXT_LEVEL= field in os-release(5) may be used to specify the
supported system extension level.
* A new ExtensionImages= unit setting can be used to apply the same
system extension image concept from systemd-sysext to the namespaced
file hierarchy of specific services, following the same rules and
constraints.
* Support for a new special "root=tmpfs" kernel command-line option has
been added. When specified, a tmpfs is mounted on /, and mount.usr=
should be used to point to the operating system implementation.
* A new configuration file /etc/veritytab may be used to configure
dm-verity integrity protection for block devices. Each line is in the
format "volume-name data-device hash-device roothash options",
similar to /etc/crypttab.
* A new kernel command-line option systemd.verity.root_options= may be
used to configure dm-verity behaviour for the root device.
* The key file specified in /etc/crypttab (the third field) may now
refer to an AF_UNIX/SOCK_STREAM socket in the file system. The key is
acquired by connecting to that socket and reading from it. This
allows the implementation of a service to provide key information
dynamically, at the moment when it is needed.
* When the hostname is set explicitly to "localhost", systemd-hostnamed
will respect this. Previously such a setting would be mostly silently
ignored. The goal is to honour configuration as specified by the
user.
* The fallback hostname that will be used by the system manager and
systemd-hostnamed can now be configured in two new ways: by setting
DEFAULT_HOSTNAME= in os-release(5), or by setting
$SYSTEMD_DEFAULT_HOSTNAME in the environment block. As before, it can
also be configured during compilation. The environment variable is
intended for testing and local overrides, the os-release(5) field is
intended to allow customization by different variants of a
distribution that share the same compiled packages.
* The environment block of the manager itself may be configured through
a new ManagerEnvironment= setting in system.conf or user.conf. This
complements existing ways to set the environment block (the kernel
command line for the system manager, the inherited environment and
user@.service unit file settings for the user manager).
* systemd-hostnamed now exports the default hostname and the source of
the configured hostname ("static", "transient", or "default") as
D-Bus properties.
* systemd-hostnamed now exports the "HardwareVendor" and
"HardwareModel" D-Bus properties, which are supposed to contain a
pair of cleaned up, human readable strings describing the system's
vendor and model. It's typically sourced from the firmware's DMI
tables, but may be augmented from a new hwdb database. hostnamectl
shows this in the status output.
* Support has been added to systemd-cryptsetup for extracting the
PKCS#11 token URI and encrypted key from the LUKS2 JSON embedded
metadata header. This allows the information how to open the
encrypted device to be embedded directly in the device and obviates
the need for configuration in an external file.
* systemd-cryptsetup gained support for unlocking LUKS2 volu
[systemd-devel] systemd prerelease 248-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v248-rc2.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* A concept of system extension images is introduced. Such images may
be used to extend the /usr/ and /opt/ directory hierarchies at
runtime with additional files (even if the file system is read-only).
When a system extension image is activated, its /usr/ and /opt/
hierarchies and os-release information are combined via overlayfs
with the file system hierarchy of the host OS.
A new systemd-sysext tool can be used to merge, unmerge, list, and
refresh system extension hierarchies. See
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html.
The systemd-sysext.service automatically merges installed system
extensions during boot (before basic.target, but not in very early
boot, since various file systems have to be mounted first).
The SYSEXT_LEVEL= field in os-release(5) may be used to specify the
supported system extension level.
* A new configuration file /etc/veritytab may be used to configure
dm-verity integrity protection for block devices. Each line is in the
format "volume-name data-device hash-device roothash options",
similar to /etc/crypttab.
* A new kernel command-line option systemd.verity.root_options= may be
used to configure dm-verity behaviour for the root device.
* The key file specified in /etc/crypttab (the third field) may now
refer to an AF_UNIX/SOCK_STREAM socket in the file system. The key is
acquired by connecting to that socket and reading from it. This
allows the implementation of a service to provide key information
dynamically, at the moment when it is needed.
* When the hostname is set explicitly to "localhost", systemd-hostnamed
will respect this. Previously such a setting would be mostly silently
ignored. The goal is to honour configuration as specified by the
user.
* The fallback hostname that will be used by the system manager and
systemd-hostnamed can now be configured in two new ways: by setting
DEFAULT_HOSTNAME= in os-release(5), or by setting
$SYSTEMD_DEFAULT_HOSTNAME in the environment block. As before, it can
also be configured during compilation. The environment variable is
intended for testing and local overrides, the os-release(5) field is
intended to allow customization by different variants of a
distribution that share the same compiled packages.
* The environment block of the manager itself may be configured through
a new ManagerEnvironment= setting in system.conf or user.conf. This
complements existing ways to set the environment block (the kernel
command line for the system manager, the inherited environment and
user@.service unit file settings for the user manager).
* systemd-hostnamed now exports the default hostname and the source of
the configured hostname ("static", "transient", or "default") as
D-Bus properties.
* systemd-hostnamed now exports the "HardwareVendor" and
"HardwareModel" D-Bus properties, which are supposed to contain a
pair of cleaned up, human readable strings describing the system's
vendor and model. It's typically sourced from the firmware's DMI
tables, but may be augmented from a new hwdb database. hostnamectl
shows this in the status output.
* Support has been added to systemd-cryptsetup for extracting the
PKCS#11 token URI and encrypted key from the LUKS2 JSON embedded
metadata header. This allows the information how to open the
encrypted device to be embedded directly in the device and obviates
the need for configuration in an external file.
* systemd-cryptsetup gained support for unlocking LUKS2 volumes using
TPM2 hardware, as well as FIDO2 security tokens (in addition to the
pre-existing support for PKCS#11 security tokens).
* systemd-repart may enroll encrypted partitions using TPM2
hardware. This may be useful for example to create an encrypted /var
partition bound to the machine on first boot.
* A new systemd-cryptenroll tool has been added to enroll TPM2, FIDO2
and PKCS#11 security tokens to LUKS volumes, list and destr
[systemd-devel] systemd prerelease 248-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v248-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* A concept of system extension images is introduced. Such images may
be used to extend the /usr/ and /opt/ directory hierarchies at
runtime with additional files (even if the file system is read-only).
When a system extension image is activated, its /usr/ and /opt/
hierarchies and os-release information are combined via overlayfs
with the file system hierarchy of the host OS.
A new systemd-sysext tool can be used to merge, unmerge, list, and
refresh system extension hierarchies. See
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html.
The systemd-sysext.service automatically merges installed system
extensions during boot (before basic.target, but not in very early
boot, since various file systems have to be mounted first).
The SYSEXT_LEVEL= field in os-release(5) may be used to specify the
supported system extension level.
* A new configuration file /etc/veritytab may be used to configure
dm-verity integrity protection for block devices. Each line is in the
format "volume-name data-device hash-device roothash options",
similar to /etc/crypttab.
* A new kernel command-line option systemd.verity.root_options= may be
used to configure dm-verity behaviour for the root device.
* The key file specified in /etc/crypttab (the third field) may now
refer to an AF_UNIX/SOCK_STREAM socket in the file system. The key is
acquired by connecting to that socket and reading from it. This
allows the implementation of a service to provide key information
dynamically, at the moment when it is needed.
* Support has been added to systemd-cryptsetup for extracting the
PKCS#11 token URI and encrypted key from the LUKS2 JSON embedded
metadata header. This allows the information how to open the
encrypted device to be embedded directly in the device and obviates
the need for configuration in an external file.
* systemd-cryptsetup gained support for unlocking LUKS2 volumes using
TPM2 hardware, as well as FIDO2 security tokens (in addition to the
pre-existing support for PKCS#11 security tokens).
* systemd-repart may enroll encrypted partitions using TPM2
hardware. This may be useful for example to create an encrypted /var
partition bound to the machine on first boot.
* A new systemd-cryptenroll tool has been added to enroll TPM2, FIDO2
and PKCS#11 security tokens to LUKS volumes, list and destroy
them. See:
http://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html
It also supports enrolling "recovery keys" and regular passphrases.
* The libfido2 dependency is now based on dlopen(), so that the library
is used at runtime when installed, but is not a hard runtime
dependency.
* systemd-cryptsetup gained support for two new options in
/etc/crypttab: "no-write-workqueue" and "no-read-workqueue" which
request synchronous processing of encryption/decryption IO.
* The manager may be configured at compile time to use the fexecve()
instead of the execve() system call when spawning processes. Using
fexecve() closes a window between checking the security context of an
executable and spawning it, but unfortunately the kernel displays
stale information in the process' "comm" field, which impacts ps
output and such.
* The configuration option -Dcompat-gateway-hostname has been dropped.
"_gateway" is now the only supported name.
* The ConditionSecurity=tpm2 unit file setting may be used to check if
the system has at least one TPM2 (tpmrm class) device.
* A new ConditionCPUFeature= has been added that may be used to
conditionalize units based on CPU features. For example,
ConditionCPUFeature=rdrand will condition a unit so that it is only
run when the system CPU supports the RDRAND opcode.
* The tables of system calls in seccomps filters are now automatically
generated from kernel lists exported on
https://fedora.juszkiewicz.com.pl/syscalls.html.
The following architectures should now
[systemd-devel] systemd 247 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v247.tar.gz
Changes since the previous release:
* KERNEL API INCOMPATIBILITY: Linux 4.14 introduced two new uevents
"bind" and "unbind" to the Linux device model. When this kernel
change was made, systemd-udevd was only minimally updated to handle
and propagate these new event types. The introduction of these new
uevents (which are typically generated for USB devices and devices
needing a firmware upload before being functional) resulted in a
number of issues which we so far didn't address. We hoped the kernel
maintainers would themselves address these issues in some form, but
that did not happen. To handle them properly, many (if not most) udev
rules files shipped in various packages need updating, and so do many
programs that monitor or enumerate devices with libudev or sd-device,
or otherwise process uevents. Please note that this incompatibility
is not fault of systemd or udev, but caused by an incompatible kernel
change that happened back in Linux 4.12, but is becoming more and
more visible as the new uevents are generated by more kernel drivers.
To minimize issues resulting from this kernel change (but not avoid
them entirely) starting with systemd-udevd 247 the udev "tags"
concept (which is a concept for marking and filtering devices during
enumeration and monitoring) has been reworked: udev tags are now
"sticky", meaning that once a tag is assigned to a device it will not
be removed from the device again until the device itself is removed
(i.e. unplugged). This makes sure that any application monitoring
devices that match a specific tag is guaranteed to both see uevents
where the device starts being relevant, and those where it stops
being relevant (the latter now regularly happening due to the new
"unbind" uevent type). The udev tags concept is hence now a concept
tied to a *device* instead of a device *event* — unlike for example
udev properties whose lifecycle (as before) is generally tied to a
device event, meaning that the previously determined properties are
forgotten whenever a new uevent is processed.
With the newly redefined udev tags concept, sometimes it's necessary
to determine which tags are the ones applied by the most recent
uevent/database update, in order to discern them from those
originating from earlier uevents/database updates of the same
device. To accommodate for this a new automatic property CURRENT_TAGS
has been added that works similar to the existing TAGS property but
only lists tags set by the most recent uevent/database
update. Similarly, the libudev/sd-device API has been updated with
new functions to enumerate these 'current' tags, in addition to the
existing APIs that now enumerate the 'sticky' ones.
To properly handle "bind"/"unbind" on Linux 4.12 and newer it is
essential that all udev rules files and applications are updated to
handle the new events. Specifically:
• All rule files that currently use a header guard similar to
ACTION!="add|change",GOTO="xyz_end" should be updated to use
ACTION=="remove",GOTO="xyz_end" instead, so that the
properties/tags they add are also applied whenever "bind" (or
"unbind") is seen. (This is most important for all physical device
types — those for which "bind" and "unbind" are currently
generated, for all other device types this change is still
recommended but not as important — but certainly prepares for
future kernel uevent type additions).
• Similarly, all code monitoring devices that contains an 'if' branch
discerning the "add" + "change" uevent actions from all other
uevents actions (i.e. considering devices only relevant after "add"
or "change", and irrelevant on all other events) should be reworked
to instead negatively check for "remove" only (i.e. considering
devices relevant after all event types, except for "remove", which
invalidates the device). Note that this also means that devices
should be considered relevant on "unbind", even though conceptually
this — in some form — invalidates the device. Since the pre
[systemd-devel] systemd prerelease 247-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v247-rc2.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* KERNEL API INCOMPATIBILITY: Linux 4.12 introduced two new uevents
"bind" and "unbind" to the Linux device model. When this kernel
change was made, systemd-udevd was only minimally updated to handle
and propagate these new event types. The introduction of these new
uevents (which are typically generated for USB devices and devices
needing a firmware upload before being functional) resulted in a
number of issues which we so far didn't address. We hoped the kernel
maintainers would themselves address these issues in some form, but
that did not happen. To handle them properly, many (if not most) udev
rules files shipped in various packages need updating, and so do many
programs that monitor or enumerate devices with libudev or sd-device,
or otherwise process uevents. Please note that this incompatibility
is not fault of systemd or udev, but caused by an incompatible kernel
change that happened back in Linux 4.12, but is becoming more and
more visible as the new uevents are generated by more kernel drivers.
To minimize issues resulting from this kernel change (but not avoid
them entirely) starting with systemd-udevd 247 the udev "tags"
concept (which is a concept for marking and filtering devices during
enumeration and monitoring) has been reworked: udev tags are now
"sticky", meaning that once a tag is assigned to a device it will not
be removed from the device again until the device itself is removed
(i.e. unplugged). This makes sure that any application monitoring
devices that match a specific tag is guaranteed to both see uevents
where the device starts being relevant, and those where it stops
being relevant (the latter now regularly happening due to the new
"unbind" uevent type). The udev tags concept is hence now a concept
tied to a *device* instead of a device *event* — unlike for example
udev properties whose lifecycle (as before) is generally tied to a
device event, meaning that the previously determined properties are
forgotten whenever a new uevent is processed.
With the newly redefined udev tags concept, sometimes it's necessary
to determine which tags are the ones applied by the most recent
uevent/database update, in order to discern them from those
originating from earlier uevents/database updates of the same
device. To accommodate for this a new automatic property CURRENT_TAGS
has been added that works similar to the existing TAGS property but
only lists tags set by the most recent uevent/database
update. Similarly, the libudev/sd-device API has been updated with
new functions to enumerate these 'current' tags, in addition to the
existing APIs that now enumerate the 'sticky' ones.
To properly handle "bind"/"unbind" on Linux 4.12 and newer it is
essential that all udev rules files and applications are updated to
handle the new events. Specifically:
• All rule files that currently use a header guard similar to
ACTION!="add|change",GOTO="xyz_end" should be updated to use
ACTION=="remove",GOTO="xyz_end" instead, so that the
properties/tags they add are also applied whenever "bind" (or
"unbind") is seen. (This is most important for all physical device
types — those for which "bind" and "unbind" are currently
generated, for all other device types this change is still
recommended but not as important — but certainly prepares for
future kernel uevent type additions).
• Similarly, all code monitoring devices that contains an 'if' branch
discerning the "add" + "change" uevent actions from all other
uevents actions (i.e. considering devices only relevant after "add"
or "change", and irrelevant on all other events) should be reworked
to instead negatively check for "remove" only (i.e. considering
devices relevant after all event types, except for "remove", which
invalidat
[systemd-devel] systemd prerelease 247-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v247-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* KERNEL API INCOMPATIBILITY: Linux 4.12 introduced two new uevents
"bind" and "unbind" to the Linux device model. When this kernel
change was made, systemd-udevd was only minimally updated to handle
and propagate these new event types. The introduction of these new
uevents (which are typically generated for USB devices and devices
needing a firmware upload before being functional) resulted in a
number of issues which we so far didn't address. We hoped the kernel
maintainers would themselves address these issues in some form, but
that did not happen. To handle them properly, many (if not most) udev
rules files shipped in various packages need updating, and so do many
programs that monitor or enumerate devices with libudev or sd-device,
or otherwise process uevents. Please note that this incompatibility
is not fault of systemd or udev, but caused by an incompatible kernel
change that happened back in Linux 4.12, but is becoming more and
more visible as the new uevents are generated by more kernel drivers.
To minimize issues resulting from this kernel change (but not avoid
them entirely) starting with systemd-udevd 247 the udev "tags"
concept (which is a concept for marking and filtering devices during
enumeration and monitoring) has been reworked: udev tags are now
"sticky", meaning that once a tag is assigned to a device it will not
be removed from the device again until the device itself is removed
(i.e. unplugged). This makes sure that any application monitoring
devices that match a specific tag is guaranteed to both see uevents
where the device starts being relevant, and those where it stops
being relevant (the latter now regularly happening due to the new
"unbind" uevent type). The udev tags concept is hence now a concept
tied to a *device* instead of a device *event* — unlike for example
udev properties whose lifecycle (as before) is generally tied to a
device event, meaning that the previously determined properties are
forgotten whenever a new uevent is processed.
With the newly redefined udev tags concept, sometimes it's necessary
to determine which tags are the ones applied by the most recent
uevent/database update, in order to discern them from those
originating from earlier uevents/database updates of the same
device. To accommodate for this a new automatic property CURRENT_TAGS
has been added that works similar to the existing TAGS property but
only lists tags set by the most recent uevent/database
update. Similarly, the libudev/sd-device API has been updated with
new functions to enumerate these 'current' tags, in addition to the
existing APIs that now enumerate the 'sticky' ones.
To properly handle "bind"/"unbind" on Linux 4.12 and newer it is
essential that all udev rules files and applications are updated to
handle the new events. Specifically:
• All rule files that currently use a header guard similar to
ACTION!="add|change",GOTO="xyz_end" should be updated to use
ACTION=="remove",GOTO="xyz_end" instead, so that the
properties/tags they add are also applied whenever "bind" (or
"unbind") is seen. (This is most important for all physical device
types — those for which "bind" and "unbind" are currently
generated, for all other device types this change is still
recommended but not as important — but certainly prepares for
future kernel uevent type additions).
• Similarly, all code monitoring devices that contains an 'if' branch
discerning the "add" + "change" uevent actions from all other
uevents actions (i.e. considering devices only relevant after "add"
or "change", and irrelevant on all other events) should be reworked
to instead negatively check for "remove" only (i.e. considering
devices relevant after all event types, except for "remove", which
invalidat
[systemd-devel] systemd 246 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v246.tar.gz
Changes since the previous release:
* The service manager gained basic support for cgroup v2 freezer. Units
can now be suspended or resumed either using new systemctl verbs,
freeze and thaw respectively, or via D-Bus.
* PID 1 may now automatically load pre-compiled AppArmor policies from
/etc/apparmor/earlypolicy during early boot.
* The CPUAffinity= setting in service unit files now supports a new
special value "numa" that causes the CPU affinity masked to be set
based on the NUMA mask.
* systemd will now log about all left-over processes remaining in a
unit when the unit is stopped. It will now warn about services using
KillMode=none, as this is generally an unsafe thing to make use of.
* Two new unit file settings
ConditionPathIsEncrypted=/AssertPathIsEncrypted= have been
added. They may be used to check whether a specific file system path
resides on a block device that is encrypted on the block level
(i.e. using dm-crypt/LUKS).
* Another pair of new settings ConditionEnvironment=/AssertEnvironment=
has been added that may be used for simple environment checks. This
is particularly useful when passing in environment variables from a
container manager (or from PAM in case of the systemd --user
instance).
* .service unit files now accept a new setting CoredumpFilter= which
allows configuration of the memory sections coredumps of the
service's processes shall include.
* .mount units gained a new ReadWriteOnly= boolean option. If set
it will not be attempted to mount a file system read-only if mounting
in read-write mode doesn't succeed. An option x-systemd.rw-only is
available in /etc/fstab to control the same.
* .socket units gained a new boolean setting PassPacketInfo=. If
enabled, the kernel will attach additional per-packet metadata to all
packets read from the socket, as an ancillary message. This controls
the IP_PKTINFO, IPV6_RECVPKTINFO, NETLINK_PKTINFO socket options,
depending on socket type.
* .service units gained a new setting RootHash= which may be used to
specify the root hash for verity enabled disk images which are
specified in RootImage=. RootVerity= may be used to specify a path to
the Verity data matching a RootImage= file system. (The latter is
only useful for images that do not contain the Verity data embedded
into the same image that carries a GPT partition table following the
Discoverable Partition Specification). Similarly, systemd-nspawn
gained a new switch --verity-data= that takes a path to a file with
the verity data of the disk image supplied in --image=, if the image
doesn't contain the verity data itself.
* .service units gained a new setting RootHashSignature= which takes
either a base64 encoded PKCS#7 signature of the root hash specified
with RootHash=, or a path to a file to read the signature from. This
allows validation of the root hash against public keys available in
the kernel keyring, and is only supported on recent kernels
(>= 5.4)/libcryptsetup (>= 2.30). A similar switch has been added to
systemd-nspawn and systemd-dissect (--root-hash-sig=). Support for
this mechanism has also been added to systemd-veritysetup.
* .service unit files gained two new options
TimeoutStartFailureMode=/TimeoutStopFailureMode= that may be used to
tune behaviour if a start or stop timeout is hit, i.e. whether to
terminate the service with SIGTERM, SIGABRT or SIGKILL.
* Most options in systemd that accept hexadecimal values prefixed with
0x in additional to the usual decimal notation now also support octal
notation when the 0o prefix is used and binary notation if the 0b
prefix is used.
* Various command line parameters and configuration file settings that
configure key or certificate files now optionally take paths to
AF_UNIX sockets in the file system. If configured that way a stream
connection is made to the socket and the required data read from
it. This is a simple and natural extension to the existing regular
file logic, and permits other software to provide keys or
certificates via simple IPC services, for example when unencrypted
storage on disk is not desired. Specifically, systemd-networkd's
Wireguard and MACSEC key file settings as well as
[systemd-devel] systemd prerelease 246-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v246-rc2.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* The service manager gained basic support for cgroup v2 freezer. Units
can now be suspended or resumed either using new systemctl verbs,
freeze and thaw respectively, or via D-Bus.
* PID 1 may now automatically load pre-compiled AppArmor policies from
/etc/apparmor/earlypolicy during early boot.
* The CPUAffinity= setting in service unit files now supports a new
special value "numa" that causes the CPU affinity masked to be set
based on the NUMA mask.
* systemd will now log about all left-over processes remaining in a
unit when the unit is stopped. It will now warn about services using
KillMode=none, as this is generally an unsafe thing to make use of.
* Two new unit file settings
ConditionPathIsEncrypted=/AssertPathIsEncrypted= have been
added. They may be used to check whether a specific file system path
resides on a block device that is encrypted on the block level
(i.e. using dm-crypt/LUKS).
* Another pair of new settings ConditionEnvironment=/AssertEnvironment=
has been added that may be used for simple environment checks. This
is particularly useful when passing in environment variables from a
container manager (or from PAM in case of the systemd --user
instance).
* .service unit files now accept a new setting CoredumpFilter= which
allows configuration of the memory sections coredumps of the
service's processes shall include.
* .mount units gained a new ReadWriteOnly= boolean option. If set
it will not be attempted to mount a file system read-only if mounting
in read-write mode doesn't succeed. An option x-systemd.rw-only is
available in /etc/fstab to control the same.
* .socket units gained a new boolean setting PassPacketInfo=. If
enabled, the kernel will attach additional per-packet metadata to all
packets read from the socket, as an ancillary message. This controls
the IP_PKTINFO, IPV6_RECVPKTINFO, NETLINK_PKTINFO socket options,
depending on socket type.
* .service units gained a new setting RootHash= which may be used to
specify the root hash for verity enabled disk images which are
specified in RootImage=. RootVerity= may be used to specify a path to
the Verity data matching a RootImage= file system. (The latter is
only useful for images that do not contain the Verity data embedded
into the same image that carries a GPT partition table following the
Discoverable Partition Specification). Similarly, systemd-nspawn
gained a new switch --verity-data= that takes a path to a file with
the verity data of the disk image supplied in --image=, if the image
doesn't contain the verity data itself.
* .service units gained a new setting RootHashSignature= which takes
either a base64 encoded PKCS#7 signature of the root hash specified
with RootHash=, or a path to a file to read the signature from. This
allows validation of the root hash against public keys available in
the kernel keyring, and is only supported on recent kernels
(>= 5.4)/libcryptsetup (>= 2.30). A similar switch has been added to
systemd-nspawn and systemd-dissect (--root-hash-sig=). Support for
this mechanism has also been added to systemd-veritysetup.
* .service unit files gained two new options
TimeoutStartFailureMode=/TimeoutStopFailureMode= that may be used to
tune behaviour if a start or stop timeout is hit, i.e. whether to
terminate the service with SIGTERM, SIGABRT or SIGKILL.
* Most options in systemd that accept hexadecimal values prefixed with
0x in additional to the usual decimal notation now also support octal
notation when the 0o prefix is used and binary notation if the 0b
prefix is used.
* Various command line parameters and configuration file settings that
configure key or certificate files now optionally take paths to
AF_UNIX sockets in the file system. If configured that way a stream
connection is made to the socket and the required data read from
it. This is a simple and natural extension to the existing regular
file logic, and permits other software
[systemd-devel] systemd prerelease 246-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v246-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* The service manager gained basic support for cgroup v2 freezer. Units
can now be suspended or resumed either using new systemctl verbs,
freeze and thaw respectively, or via D-Bus.
* PID 1 may now automatically load pre-compiled AppArmor policies from
/etc/apparmor/earlypolicy during early boot.
* The CPUAffinity= setting in service unit files now supports a new
special value "numa" that causes the CPU affinity masked to be set
based on the NUMA mask.
* systemd will now log about all left-over processes remaining in a
unit when the unit is stopped. It will now warn about services using
KillMode=none, as this is generally an unsafe thing to make use of.
* Two new unit file settings
ConditionPathIsEncrypted=/AssertPathIsEncrypted= have been
added. They may be used to check whether a specific file system path
resides on a block device that is encrypted on the block level
(i.e. using dm-crypt/LUKS).
* Another pair of new settings ConditionEnvironment=/AssertEnvironment=
has been added that may be used for simple environment checks. This
is particularly useful when passing in environment variables from a
container manager (or from PAM in case of the systemd --user
instance).
* .service unit files now accept a new setting CoredumpFilter= which
allows configuration of the memory sections coredumps of the
service's processes shall include.
* .mount units gained a new ReadWriteOnly= boolean option. If set
it will not be attempted to mount a file system read-only if mounting
in read-write mode doesn't succeed. An option x-systemd.rw-only is
available in /etc/fstab to control the same.
* .socket units gained a new boolean setting PassPacketInfo=. If
enabled, the kernel will attach additional per-packet metadata to all
packets read from the socket, as ancillary message. This controls the
IP_PKTINFO, IPV6_RECVPKTINFO, NETLINK_PKTINFO socket options,
depending on socket type.
* .service units gained a new setting RootHash= which may be used to
specify the root hash for verity enabled disk images which are
specified in RootImage=. RootVerity= may be used to specify a path to
the Verity data matching a RootImage= file system. (The latter is
only useful for images that do not contain the Verity data embedded
into the same image that carries a GPT partition table following the
Discoverable Partition Specification). Similarly, systemd-nspawn
gained a new switch --verity-data= that takes a path to a file with
the verity data of the disk image supplied in --image=, if the image
doesn't contain the verity data itself.
* .service units gained a new setting RootHashSignature= which takes
either a base64 encoded PKCS#7 signature of the root hash specified
with RootHash=, or a path to a file to read the signature from. This
allows validation of the root hash against public keys available in
the kernel keyring, and is only supported on recent kernels
(>= 5.4)/libcryptsetup (>= 2.30). A similar switch has been added to
systemd-nspawn and systemd-dissect (--root-hash-sig=). Support for
this mechanism has also been added to systemd-veritysetup.
* .service unit files gained two new options
TimeoutStartFailureMode=/TimeoutStopFailureMode= that may be used to
tune behaviour if a start or stop timeout is hit, i.e. whether to
terminate the service with SIGTERM, SIGABRT or SIGKILL.
* Most options in systemd that accept hexadecimal values prefixed with
0x in additional to the usual decimal notation now also support octal
notation when the 0o prefix is used and binary notation if the 0b
prefix is used.
* Unit files, tmpfiles.d/ snippets, sysusers.d/ snippets and other
configuration files that support specifier expansion learnt six new
specifiers: %a resolves to the current architecture, %o/%w/%B/%W
resolve to the various ID fields from /etc/os-release, %l resolves to
the "short" hostname of the system, i.e. the hostname configured in
the kernel truncated at the first dot.
[systemd-devel] systemd 245 released
A new, official systemd release has just been tagged . Please download the tarball here: https://github.com/systemd/systemd/archive/v245.tar.gz Changes since the previous release: * A new tool "systemd-repart" has been added, that operates as an idempotent declarative repartitioner for GPT partition tables. Specifically, a set of partitions that must or may exist can be configured via drop-in files, and during every boot the partition table on disk is compared with these files, creating missing partitions or growing existing ones based on configurable relative and absolute size constraints. The tool is strictly incremental, i.e. does not delete, shrink or move partitions, but only adds and grows them. The primary use-case is OS images that ship in minimized form, that on first boot are grown to the size of the underlying block device or augmented with additional partitions. For example, the root partition could be extended to cover the whole disk, or a swap or /home partitions could be added on first boot. It can also be used for systems that use an A/B update scheme but ship images with just the A partition, with B added on first boot. The tool is primarily intended to be run in the initrd, shortly before transitioning into the host OS, but can also be run after the transition took place. It automatically discovers the disk backing the root file system, and should hence not require any additional configuration besides the partition definition drop-ins. If no configuration drop-ins are present, no action is taken. * A new component "userdb" has been added, along with a small daemon "systemd-userdb.service" and a client tool "userdbctl". The framework allows defining rich user and group records in a JSON format, extending on the classic "struct passwd" and "struct group" structures. Various components in systemd have been updated to process records in this format, including systemd-logind and pam-systemd. The user records are intended to be extensible, and allow setting various resource management, security and runtime parameters that shall be applied to processes and sessions of the user as they log in. This facility is intended to allow associating such metadata directly with user/group records so that they can be produced, extended and consumed in unified form. We hope that eventually frameworks such as sssd will generate records this way, so that for the first time resource management and various other per-user settings can be configured in LDAP directories and then provided to systemd (specifically to systemd-logind and pam-system) to apply on login. For further details see: https://systemd.io/USER_RECORD https://systemd.io/GROUP_RECORD https://systemd.io/USER_GROUP_API * A small new service systemd-homed.service has been added, that may be used to securely manage home directories with built-in encryption. The complete user record data is unified with the home directory, thus making home directories naturally migratable. Its primary back-end is based on LUKS volumes, but fscrypt, plain directories, and other storage schemes are also supported. This solves a couple of problems we saw with traditional ways to manage home directories, in particular when it comes to encryption. For further discussion of this, see the video of Lennart's talk at AllSystemsGo! 2019: https://media.ccc.de/v/ASG2019-164-reinventing-home-directories For further details about the format and expectations on home directories this new daemon makes, see: https://systemd.io/HOME_DIRECTORY * systemd-journald is now multi-instantiable. In addition to the main instance systemd-journald.service there's now a template unit systemd-journald@.service, with each instance defining a new named log 'namespace' (whose name is specified via the instance part of the unit name). A new unit file setting LogNamespace= has been added, taking such a namespace name, that assigns services to the specified log namespaces. As each log namespace is serviced by its own independent journal daemon, this functionality may be used to improve performance and increase isolation of applications, at the price of losing global message ordering. Each instance of journald has a separate set of configuration files, with possibly different disk usa
[systemd-devel] systemd 245 released
A new, official systemd release has just been tagged . Please download the tarball here: https://github.com/systemd/systemd/archive/v245.tar.gz Changes since the previous release: * A new tool "systemd-repart" has been added, that operates as an idempotent declarative repartitioner for GPT partition tables. Specifically, a set of partitions that must or may exist can be configured via drop-in files, and during every boot the partition table on disk is compared with these files, creating missing partitions or growing existing ones based on configurable relative and absolute size constraints. The tool is strictly incremental, i.e. does not delete, shrink or move partitions, but only adds and grows them. The primary use-case is OS images that ship in minimized form, that on first boot are grown to the size of the underlying block device or augmented with additional partitions. For example, the root partition could be extended to cover the whole disk, or a swap or /home partitions could be added on first boot. It can also be used for systems that use an A/B update scheme but ship images with just the A partition, with B added on first boot. The tool is primarily intended to be run in the initrd, shortly before transitioning into the host OS, but can also be run after the transition took place. It automatically discovers the disk backing the root file system, and should hence not require any additional configuration besides the partition definition drop-ins. If no configuration drop-ins are present, no action is taken. * A new component "userdb" has been added, along with a small daemon "systemd-userdb.service" and a client tool "userdbctl". The framework allows defining rich user and group records in a JSON format, extending on the classic "struct passwd" and "struct group" structures. Various components in systemd have been updated to process records in this format, including systemd-logind and pam-systemd. The user records are intended to be extensible, and allow setting various resource management, security and runtime parameters that shall be applied to processes and sessions of the user as they log in. This facility is intended to allow associating such metadata directly with user/group records so that they can be produced, extended and consumed in unified form. We hope that eventually frameworks such as sssd will generate records this way, so that for the first time resource management and various other per-user settings can be configured in LDAP directories and then provided to systemd (specifically to systemd-logind and pam-system) to apply on login. For further details see: https://systemd.io/USER_RECORD https://systemd.io/GROUP_RECORD https://systemd.io/USER_GROUP_API * A small new service systemd-homed.service has been added, that may be used to securely manage home directories with built-in encryption. The complete user record data is unified with the home directory, thus making home directories naturally migratable. Its primary back-end is based on LUKS volumes, but fscrypt, plain directories, and other storage schemes are also supported. This solves a couple of problems we saw with traditional ways to manage home directories, in particular when it comes to encryption. For further discussion of this, see the video of Lennart's talk at AllSystemsGo! 2019: https://media.ccc.de/v/ASG2019-164-reinventing-home-directories For further details about the format and expectations on home directories this new daemon makes, see: https://systemd.io/HOME_DIRECTORY * systemd-journald is now multi-instantiable. In addition to the main instance systemd-journald.service there's now a template unit systemd-journald@.service, with each instance defining a new named log 'namespace' (whose name is specified via the instance part of the unit name). A new unit file setting LogNamespace= has been added, taking such a namespace name, that assigns services to the specified log namespaces. As each log namespace is serviced by its own independent journal daemon, this functionality may be used to improve performance and increase isolation of applications, at the price of losing global message ordering. Each instance of journald has a separate set of configuration files, with possibly different disk usa
[systemd-devel] systemd prerelease 245-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v245-rc2.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * A new tool "systemd-repart" has been added, that operates as an idempotent declarative repartitioner for GPT partition tables. Specifically, a set of partitions that must or may exist can be configured via drop-in files, and during every boot the partition table on disk is compared with these files, creating missing partitions or growing existing ones based on configurable relative and absolute size constraints. The tool is strictly incremental, i.e. does not delete, shrink or move partitions, but only adds and grows them. The primary use-case is OS images that ship in minimized form, that on first boot are grown to the size of the underlying block device or augmented with additional partitions. For example, the root partition could be extended to cover the whole disk, or a swap or /home partitions could be added on first boot. It can also be used for systems that use an A/B update scheme but ship images with just the A partition, with B added on first boot. The tool is primarily intended to be run in the initrd, shortly before transitioning into the host OS, but can also be run after the transition took place. It automatically discovers the disk backing the root file system, and should hence not require any additional configuration besides the partition definition drop-ins. If no configuration drop-ins are present, no action is taken. * A new component "userdb" has been added, along with a small daemon "systemd-userdb.service" and a client tool "userdbctl". The framework allows defining rich user and group records in a JSON format, extending on the classic "struct passwd" and "struct group" structures. Various components in systemd have been updated to process records in this format, including systemd-logind and pam-systemd. The user records are intended to be extensible, and allow setting various resource management, security and runtime parameters that shall be applied to processes and sessions of the user as they log in. This facility is intended to allow associating such metadata directly with user/group records so that they can be produced, extended and consumed in unified form. We hope that eventually frameworks such as sssd will generate records this way, so that for the first time resource management and various other per-user settings can be configured in LDAP directories and then provided to systemd (specifically to systemd-logind and pam-system) to apply on login. For further details see: https://systemd.io/USER_RECORD https://systemd.io/GROUP_RECORD https://systemd.io/USER_GROUP_API * A small new service systemd-homed.service has been added, that may be used to securely manage home directories with built-in encryption. The complete user record data is unified with the home directory, thus making home directories naturally migratable. Its primary back-end is based on LUKS volumes, but fscrypt, plain directories, and other storage schemes are also supported. This solves a couple of problems we saw with traditional ways to manage home directories, in particular when it comes to encryption. For further discussion of this, see the video of Lennart's talk at AllSystemsGo! 2019: https://media.ccc.de/v/ASG2019-164-reinventing-home-directories For further details about the format and expectations on home directories this new daemon makes, see: https://systemd.io/HOME_DIRECTORY * systemd-journald is now multi-instantiable. In addition to the main instance systemd-journald.service there's now a template unit systemd-journald@.service, with each instance defining a new named log 'namespace' (whose name is specified via the instance part of the unit name). A new unit file setting LogNamespace= has been added, taking such a namespace name, that assigns services to the specified log namespaces. As each log namespace is serviced by its own independent journal daemon, this functionality may be used to improve perf
[systemd-devel] systemd prerelease 245-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v245-rc1.tar.gz NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * A new tool "systemd-repart" has been added, that operates as an idempotent declarative repartitioner for GPT partition tables. Specifically, a set of partitions that must or may exist can be configured via drop-in files, and during every boot the partition table on disk is compared with these files, creating missing partitions or growing existing ones based on configurable relative and absolute size constraints. The tool is strictly incremental, i.e. does not delete, shrink or move partitions, but only adds and grows them. The primary use-case is OS images that ship in minimized form, that on first boot are grown to the size of the underlying block device or augmented with additional partitions. For example, the root partition could be extended to cover the whole disk, or a swap or /home partitions could be added on first boot. It can also be used for systems that use an A/B update scheme but ship images with just the A partition, with B added on first boot. The tool is primarily intended to be run in the initrd, shortly before transitioning into the host OS, but can also be run after the transition took place. It automatically discovers the disk backing the root file system, and should hence not require any additional configuration besides the partition definition drop-ins. If no configuration drop-ins are present, no action is taken. * A new component "userdb" has been added, along with a small daemon "systemd-userdb.service" and a client tool "userdbctl". The framework allows defining rich user and group records in a JSON format, extending on the classic "struct passwd" and "struct group" structures. Various components in systemd have been updated to process records in this format, including systemd-logind and pam-systemd. The user records are intended to be extensible, and allow setting various resource management, security and runtime parameters that shall be applied to processes and sessions of the user as they log in. This facility is intended to allow associating such metadata directly with user/group records so that they can be produced, extended and consumed in unified form. We hope that eventually frameworks such as sssd will generate records this way, so that for the first time resource management and various other per-user settings can be configured in LDAP directories and then provided to systemd (specifically to systemd-logind and pam-system) to apply on login. For further details see: https://systemd.io/USER_RECORD https://systemd.io/GROUP_RECORD https://systemd.io/USER_GROUP_API * A small new service systemd-homed.service has been added, that may be used to securely manage home directories with built-in encryption. The complete user record data is unified with the home directory, thus making home directories naturally migratable. Its primary back-end is based on LUKS volumes, but fscrypt, plain directories, and other storage schemes are also supported. This solves a couple of problems we saw with traditional ways to manage home directories, in particular when it comes to encryption. For further discussion of this, see the video of Lennart's talk at AllSystemsGo! 2019: https://media.ccc.de/v/ASG2019-164-reinventing-home-directories For further details about the format and expectations on home directories this new daemon makes, see: https://systemd.io/HOME_DIRECTORY * systemd-journald is now multi-instantiable. In addition to the main instance systemd-journald.service there's now a template unit systemd-journald@.service, with each instance defining a new named log 'namespace' (whose name is specified via the instance part of the unit name). A new unit file setting LogNamespace= has been added, taking such a namespace name, that assigns services to the specified log namespaces. As each log namespace is serviced by its own independent journal daemon, this functionality may be used to improve perf
[systemd-devel] systemd 244 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v244.tar.gz
Changes since the previous release:
* Support for the cpuset cgroups v2 controller has been added.
Processes may be restricted to specific CPUs using the new
AllowedCPUs= setting, and to specific memory NUMA nodes using the new
AllowedMemoryNodes= setting.
* The signal used in restart jobs (as opposed to e.g. stop jobs) may
now be configured using a new RestartKillSignal= settting. This
allows units which signals to request termination to implement
different behaviour when stopping in preparation for a restart.
* "systemctl clean" may now be used also for socket, mount, and swap
units.
* systemd will also read configuration options from the EFI variable
SystemdOptions. This may be used to configure systemd behaviour when
modifying the kernel command line is inconvenient, but configuration
on disk is read too late, for example for the options related to
cgroup hierarchy setup. 'bootctl systemd-efi-options' may be used to
set the EFI variable.
* systemd will now disable printk ratelimits in early boot. This should
allow us to capture more logs from the early boot phase where normal
storage is not available and the kernel ring buffer is used for
logging. Configuration on the kernel command line has higher priority
and overrides the systemd setting.
systemd programs which log to /dev/kmsg directly use internal
ratelimits to prevent runaway logging. (Normally this is only used
during early boot, so in practice this change has very little
effect.)
* Unit files now support top level dropin directories of the form
.d/ (e.g. service.d/) that may be used to add configuration
that affects all corresponding unit files.
* systemctl gained support for 'stop --job-mode=triggering' which will
stop the specified unit and any units which could trigger it.
* Unit status display now includes units triggering and triggered by
the unit being shown.
* The RuntimeMaxSec= setting is now supported by scopes, not just
.service units. This is particularly useful for PAM sessions which
create a scope unit for the user login. systemd.runtime_max_sec=
setting may used with the pam_systemd module to limit the duration
of the PAM session, for example for time-limited logins.
* A new @pkey system call group is now defined to make it easier to
whitelist memory protection syscalls for containers and services
which need to use them.
* systemd-udevd: removed the 30s timeout for killing stale workers on
exit. systemd-udevd now waits for workers to finish. The hard-coded
exit timeout of 30s was too short for some large installations, where
driver initialization could be prematurely interrupted during initrd
processing if the root file system had been mounted and init was
preparing to switch root. If udevd is run without systemd and workers
are hanging while udevd receives an exit signal, udevd will now exit
when udev.event_timeout is reached for the last hanging worker. With
systemd, the exit timeout can additionally be configured using
TimeoutStopSec= in systemd-udevd.service.
* udev now provides a program (fido_id) that identifies FIDO CTAP1
("U2F")/CTAP2 security tokens based on the usage declared in their
report and descriptor and outputs suitable environment variables.
This replaces the externally maintained whitelists of all known
security tokens that were used previously.
* Automatically generated autosuspend udev rules for whitelisted
devices have been imported from the Chromium OS project. This should
improve power saving with many more devices.
* udev gained a new "CONST{key}=value" setting that allows matching
against system-wide constants without forking a helper binary.
Currently "arch" and "virt" keys are supported.
* udev now opens CDROMs in non-exclusive mode when querying their
capabilities. This should fix issues where other programs trying to
use the CDROM cannot gain access to it, but carries a risk of
interfering with programs writing to the disk, if they did not open
the device in exclusive mode as they should.
* systemd-networkd does not create a default route for IPv4 link local
addressing anymore. The creation of the route was unexpected and was
brea
[systemd-devel] systemd prerelease 244-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v244-rc1.tar.gz
NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems,
but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* Support for the cpuset cgroups v2 controller has been added.
Processes may be restricted to specific CPUs using the new
AllowedCPUs= setting, and to specific memory NUMA nodes using the new
AllowedMemoryNodes= setting.
* The signal used in restart jobs (as opposed to e.g. stop jobs) may
now be configured using a new RestartKillSignal= settting. This
allows units which signals to request termination to implement
different behaviour when stopping in preparation for a restart.
* "systemctl clean" may now be used also for socket, mount, and swap
units.
* systemd will also read configuration options from the EFI variable
SystemdOptions. This may be used to configure systemd behaviour when
modifying the kernel command line is inconvenient, but configuration
on disk is read too late, for example for the options related to
cgroup hierarchy setup. 'bootctl systemd-efi-options' may be used to
set the EFI variable.
* systemd will now disable printk ratelimits in early boot. This should
allow us to capture more logs from the early boot phase where normal
storage is not available and the kernel ring buffer is used for
logging. Configuration on the kernel command line has higher priority
and overrides the systemd setting.
systemd programs which log to /dev/kmsg directly use internal
ratelimits to prevent runaway logging. (Normally this is only used
during early boot, so in practice this change has very little
effect.)
* Unit files now support top level dropin directories of the form
.d/ (e.g. service.d/) that may be used to add configuration
that affects all corresponding unit files.
* systemctl gained support for 'stop --job-mode=triggering' which will
stop the specified unit and any units which could trigger it.
* Unit status display now includes units triggering and triggered by
the unit being shown.
* The RuntimeMaxSec= setting is now supported by scopes, not just
.service units. This is particularly useful for PAM sessions which
create a scope unit for the user login. systemd.runtime_max_sec=
setting may used with the pam_systemd module to limit the duration
of the PAM session, for example for time-limited logins.
* A new @pkey system call group is now defined to make it easier to
whitelist memory protection syscalls for containers and services
which need to use them.
* systemd-udevd: removed the 30s timeout for killing stale workers on
exit. systemd-udevd now waits for workers to finish. The hard-coded
exit timeout of 30s was too short for some large installations, where
driver initialization could be prematurely interrupted during initrd
processing if the root file system had been mounted and init was
preparing to switch root. If udevd is run without systemd and workers
are hanging while udevd receives an exit signal, udevd will now exit
when udev.event_timeout is reached for the last hanging worker. With
systemd, the exit timeout can additionally be configured using
TimeoutStopSec= in systemd-udevd.service.
* udev now provides a program (fido_id) that identifies FIDO CTAP1
("U2F")/CTAP2 security tokens based on the usage declared in their
report and descriptor and outputs suitable environment variables.
This replaces the externally maintained whitelists of all known
security tokens that were used previously.
* Automatically generated autosuspend udev rules for whitelisted
devices have been imported from the Chromium OS project. This should
improve power saving with many more devices.
* udev gained a new "CONST{key}=value" setting that allows matching
against system-wide constants without forking a helper binary.
Currently "arch" and "virt" keys are supported.
* udev now opens CDROMs in non-exclusive mode when querying their
capabilities. This should fix issues where other programs trying to
use the CDROM cannot gain access to it, but carries a risk of
interfering with programs writing to the disk, if they did not open
[systemd-devel] systemd 243 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v243.tar.gz
Changes since the previous release:
* This release enables unprivileged programs (i.e. requiring neither
setuid nor file capabilities) to send ICMP Echo (i.e. ping) requests
by turning on the "net.ipv4.ping_group_range" sysctl of the Linux
kernel for the whole UNIX group range, i.e. all processes. This
change should be reasonably safe, as the kernel support for it was
specifically implemented to allow safe access to ICMP Echo for
processes lacking any privileges. If this is not desirable, it can be
disabled again by setting the parameter to "1 0".
* Previously, filters defined with SystemCallFilter= would have the
effect that any calling of an offending system call would terminate
the calling thread. This behaviour never made much sense, since
killing individual threads of unsuspecting processes is likely to
create more problems than it solves. With this release the default
action changed from killing the thread to killing the whole
process. For this to work correctly both a kernel version (>= 4.14)
and a libseccomp version (>= 2.4.0) supporting this new seccomp
action is required. If an older kernel or libseccomp is used the old
behaviour continues to be used. This change does not affect any
services that have no system call filters defined, or that use
SystemCallErrorNumber= (and thus see EPERM or another error instead
of being killed when calling an offending system call). Note that
systemd documentation always claimed that the whole process is
killed. With this change behaviour is thus adjusted to match the
documentation.
* On 64 bit systems, the "kernel.pid_max" sysctl is now bumped to
4194304 by default, i.e. the full 22bit range the kernel allows, up
from the old 16bit range. This should improve security and
robustness, as PID collisions are made less likely (though certainly
still possible). There are rumours this might create compatibility
problems, though at this moment no practical ones are known to
us. Downstream distributions are hence advised to undo this change in
their builds if they are concerned about maximum compatibility, but
for everybody else we recommend leaving the value bumped. Besides
improving security and robustness this should also simplify things as
the maximum number of allowed concurrent tasks was previously bounded
by both "kernel.pid_max" and "kernel.threads-max" and now effectively
only a single knob is left ("kernel.threads-max"). There have been
concerns that usability is affected by this change because larger PID
numbers are harder to type, but we believe the change from 5 digits
to 7 digits doesn't hamper usability.
* MemoryLow= and MemoryMin= gained hierarchy-aware counterparts,
DefaultMemoryLow= and DefaultMemoryMin=, which can be used to
hierarchically set default memory protection values for a particular
subtree of the unit hierarchy.
* Memory protection directives can now take a value of zero, allowing
explicit opting out of a default value propagated by an ancestor.
* systemd now defaults to the "unified" cgroup hierarchy setup during
build-time, i.e. -Ddefault-hierarchy=unified is now the build-time
default. Previously, -Ddefault-hierarchy=hybrid was the default. This
change reflects the fact that cgroupsv2 support has matured
substantially in both systemd and in the kernel, and is clearly the
way forward. Downstream production distributions might want to
continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
their builds as unfortunately the popular container managers have not
caught up with the kernel API changes.
* Man pages are not built by default anymore (html pages were already
disabled by default), to make development builds quicker. When
building systemd for a full installation with documentation, meson
should be called with -Dman=true and/or -Dhtml=true as appropriate.
The default was changed based on the assumption that quick one-off or
repeated development builds are much more common than full optimized
builds for installation, and people need to pass various other
options to when doing "proper" builds anyway, so the gain from making
development builds quicker is bigger th
[systemd-devel] systemd prerelease 243-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v243-rc2.tar.gz
NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems,
but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* This release enables unprivileged programs (i.e. requiring neither
setuid nor file capabilities) to send ICMP Echo (i.e. ping) requests
by turning on the "net.ipv4.ping_group_range" sysctl of the Linux
kernel for the whole UNIX group range, i.e. all processes. This
change should be reasonably safe, as the kernel support for it was
specifically implemented to allow safe access to ICMP Echo for
processes lacking any privileges. If this is not desirable, it can be
disabled again by setting the parameter to "1 0".
* Previously, filters defined with SystemCallFilter= would have the
effect that any calling of an offending system call would terminate
the calling thread. This behaviour never made much sense, since
killing individual threads of unsuspecting processes is likely to
create more problems than it solves. With this release the default
action changed from killing the thread to killing the whole
process. For this to work correctly both a kernel version (>= 4.14)
and a libseccomp version (>= 2.4.0) supporting this new seccomp
action is required. If an older kernel or libseccomp is used the old
behaviour continues to be used. This change does not affect any
services that have no system call filters defined, or that use
SystemCallErrorNumber= (and thus see EPERM or another error instead
of being killed when calling an offending system call). Note that
systemd documentation always claimed that the whole process is
killed. With this change behaviour is thus adjusted to match the
documentation.
* On 64 bit systems, the "kernel.pid_max" sysctl is now bumped to
4194304 by default, i.e. the full 22bit range the kernel allows, up
from the old 16bit range. This should improve security and
robustness, as PID collisions are made less likely (though certainly
still possible). There are rumours this might create compatibility
problems, though at this moment no practical ones are known to
us. Downstream distributions are hence advised to undo this change in
their builds if they are concerned about maximum compatibility, but
for everybody else we recommend leaving the value bumped. Besides
improving security and robustness this should also simplify things as
the maximum number of allowed concurrent tasks was previously bounded
by both "kernel.pid_max" and "kernel.threads-max" and now effectively
only a single knob is left ("kernel.threads-max"). There have been
concerns that usability is affected by this change because larger PID
numbers are harder to type, but we believe the change from 5 digits
to 7 digits doesn't hamper usability.
* MemoryLow= and MemoryMin= gained hierarchy-aware counterparts,
DefaultMemoryLow= and DefaultMemoryMin=, which can be used to
hierarchically set default memory protection values for a particular
subtree of the unit hierarchy.
* Memory protection directives can now take a value of zero, allowing
explicit opting out of a default value propagated by an ancestor.
* systemd now defaults to the "unified" cgroup hierarchy setup during
build-time, i.e. -Ddefault-hierarchy=unified is now the build-time
default. Previously, -Ddefault-hierarchy=hybrid was the default. This
change reflects the fact that cgroupsv2 support has matured
substantially in both systemd and in the kernel, and is clearly the
way forward. Downstream production distributions might want to
continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
their builds as unfortunately the popular container managers have not
caught up with the kernel API changes.
* Man pages are not built by default anymore (html pages were already
disabled by default), to make development builds quicker. When
building systemd for a full installation with documentation, meson
should be called with -Dman=true and/or -Dhtml=true as appropriate.
The default was changed based on the assumption that quick one-off or
repeated development builds are much more common than full
[systemd-devel] systemd prerelease 243-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v243-rc1.tar.gz
NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems,
but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* This release enables unprivileged programs (i.e. requiring neither
setuid nor file capabilities) to send ICMP Echo (i.e. ping) requests
by turning on the "net.ipv4.ping_group_range" sysctl of the Linux
kernel for the whole UNIX group range, i.e. all processes. This
change should be reasonably safe, as the kernel support for it was
specifically implemented to allow safe access to ICMP Echo for
processes lacking any privileges. If this is not desirable, it can be
disabled again by setting the parameter to "1 0".
* Previously, filters defined with SystemCallFilter= would have the
effect that any calling of an offending system call would terminate
the calling thread. This behaviour never made much sense, since
killing individual threads of unsuspecting processes is likely to
create more problems than it solves. With this release the default
action changed from killing the thread to killing the whole
process. For this to work correctly both a kernel version (>= 4.14)
and a libseccomp version (>= 2.4.0) supporting this new seccomp
action is required. If an older kernel or libseccomp is used the old
behaviour continues to be used. This change does not affect any
services that have no system call filters defined, or that use
SystemCallErrorNumber= (and thus see EPERM or another error instead
of being killed when calling an offending system call). Note that
systemd documentation always claimed that the whole process is
killed. With this change behaviour is thus adjusted to match the
documentation.
* On 64 bit systems, the "kernel.pid_max" sysctl is now bumped to
4194304 by default, i.e. the full 22bit range the kernel allows, up
from the old 16bit range. This should improve security and
robustness, as PID collisions are made less likely (though certainly
still possible). There are rumours this might create compatibility
problems, though at this moment no practical ones are known to
us. Downstream distributions are hence advised to undo this change in
their builds if they are concerned about maximum compatibility, but
for everybody else we recommend leaving the value bumped. Besides
improving security and robustness this should also simplify things as
the maximum number of allowed concurrent tasks was previously bounded
by both "kernel.pid_max" and "kernel.threads-max" and now effectively
only a single knob is left ("kernel.threads-max"). There have been
concerns that usability is affected by this change because larger PID
numbers are harder to type, but we believe the change from 5 digits
to 7 digits doesn't hamper usability.
* MemoryLow= and MemoryMin= gained hierarchy-aware counterparts,
DefaultMemoryLow= and DefaultMemoryMin=, which can be used to
hierarchically set default memory protection values for a particular
subtree of the unit hierarchy.
* Memory protection directives can now take a value of zero, allowing
explicit opting out of a default value propagated by an ancestor.
* A new setting DisableControllers= has been added that may be used to
explicitly disable one or more cgroups controllers for a unit and all
its children.
* systemd now defaults to the "unified" cgroup hierarchy setup during
build-time, i.e. -Ddefault-hierarchy=unified is now the build-time
default. Previously, -Ddefault-hierarchy=hybrid was the default. This
change reflects the fact that cgroupsv2 support has matured
substantially in both systemd and in the kernel, and is clearly the
way forward. Downstream production distributions might want to
continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
their builds as unfortunately the popular container managers have not
caught up with the kernel API changes.
* Man pages are not built by default anymore (html pages were already
disabled by default), to make development builds quicker. When
building systemd for a full installation with documentation, meson
should be called with -Dman=tru
Re: [systemd-devel] OFFLIST Re: systemd's connections to /run/systemd/private ?
On Tue, 9 Jul 2019 15:29:24 -0400 Brian Reichert wrote: > On Tue, Jul 09, 2019 at 06:20:02PM +0100, > systemd-devel@lists.freedesktop.org wrote: > > > > Posting private messages to a public list is generally considered > > very RUDE. > > I agree, and I apologize. > > The message I received, and replied to, did not come from a private > email address; it apparently came from the mailing list software, > and I did not realize that until I hit 'reply': > > Date: Tue, 9 Jul 2019 11:21:13 +0100 > From: systemd-devel@lists.freedesktop.org > To: Brian Reichert > Subject: OFFLIST Re: [systemd-devel] systemd's connections to >/run/systemd/private ? Ah, mea culpa. I apologize to you and to the list for the noise. I had the wrong setting in my MUA, which is hopefully now fixed. _______ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Anybody care to fix the list processor?
On Mon, 01 Jul 2019 08:20:23 +0200 "Ulrich Windl" wrote: > >>> Simon McVittie schrieb am 11.06.2019 um > >>> 16:29 in Nachricht > <20190611142939.GA6676@horizon>: > > On Tue, 11 Jun 2019 at 15:44:07 +0200, Ulrich Windl wrote: > >> Does anybody running the list care to fix the list-processor. > > > > I don't think the members of this list > > control its infrastructure, but I've opened > > <https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/158>. > > I agree, but they might care that the list they are using is > operational. Is this problem being worked on? It seems quite serious; it apparently prevents people from subscribing to the list as well as changing permissions. There was just a post to the openSUSE list reporting that he is unable to subscribe to the systemd-devel list because the confirmation email is rejected. https://lists.opensuse.org/opensuse-support/2019-07/msg5.html I tried to subscribe to the systemd-devel mailing list, to ask questions there directly, but they don't seem to have a correctly-configured mail server; the confirmation email fails thusly: : 131.252.210.177 does not like recipient. Remote host said: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table Giving up on 131.252.210.177. I will see if the poster can add his situation to the bug report, but if anybody could fix this problem in the meantime ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Q: ConditionPathExists=
On Wed, 05 Jun 2019 09:11:36 +0200 "Ulrich Windl" wrote: > >>> Reindl Harald schrieb am 04.06.2019 um > >>> 14:23 in > Nachricht <4e4bc6ca-2637-b10d-f4f6-536f45264...@thelounge.net>: > > > > > Am 04.06.19 um 14:17 schrieb Ulrich Windl: > [...] > > BTW: can you please only reply to the list instead reply all, your > > offlist copy is typically faster which leads in automatically > > delete the later coming list-message on mailservers configured to > > kill such needless duplicates and that breaks threading and > > reply-list in sane mail clients > > This is a thing the list should fix via Reply-To header (there is non > set). I can only "Reply" (goes to the From:) or "Reply to all". > Everything else is complex editing. It's a thing that you can fix by choosing a MUA with appropriate list-handling capabilities. When I hit Reply, the message goes to the list, not to the originator. openSUSE Leap 15.0. Claws-mail 3.16.0. You may also be able to adjust the options in your chosen MUA; I don't know. Otherwise, hand edit the replies if you don't want to use a capable MUA. See e.g. https://en.opensuse.org/openSUSE:Mailing_lists_subscription or https://mailman.readthedocs.io/en/release-3.0/src/mailman/handlers/docs/reply-to.html or https://www.gnu.org/software/mailman/mailman-admin/node11.html for explanations of why the list, like many others, does not 'fix' the header. Note also the warnings about the religious nature of the issue. _______ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd-nspawn: Update syntax to launch an image
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20190520150804.1469-1-kchamart%40redhat.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/6] pstore: The new documentation for the pstore configuration file
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1558016915-24397-7-git-send-email-eric.devolder%40oracle.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ask-password: prevent buffer overrow when reading from keyring
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20190513195801.26721-1-cascardo%40canonical.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 242 released
A new, official systemd release has just been tagged . Please download the tarball here: https://github.com/systemd/systemd/archive/v242.tar.gz Changes since the previous release: * In .link files, MACAddressPolicy=persistent (the default) is changed to cover more devices. For devices like bridges, tun, tap, bond, and similar interfaces that do not have other identifying information, the interface name is used as the basis for persistent seed for MAC and IPv4LL addresses. The way that devices that were handled previously is not changed, and this change is about covering more devices then previously by the "persistent" policy. MACAddressPolicy=random may be used to force randomized MACs and IPv4LL addresses for a device if desired. Hint: the log output from udev (at debug level) was enhanced to clarify what policy is followed and which attributes are used. `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/` may be used to view this. * The .device units generated by systemd-fstab-generator and other generators do not automatically pull in the corresponding .mount unit as a Wants= dependency. This means that simply plugging in the device will not cause the mount unit to be started automatically. But please note that the mount unit may be started for other reasons, in particular if it is part of local-fs.target, and any unit which (transitively) depends on local-fs.target is started. * networkctl list/status/lldp now accept globbing wildcards for network interface names to match against all existing interfaces. * The $PIDFILE environment variable is set to point the absolute path configured with PIDFile= for processes of that service. * The fallback DNS server list was augmented with Cloudflare public DNS servers. Use `-Ddns-servers=` to set a different fallback. * A new special target usb-gadget.target will be started automatically when a USB Device Controller is detected (which means that the system is a USB peripheral). * A new unit setting CPUQuotaPeriodSec= assigns the time period relatively to which the CPU time quota specified by CPUQuota= is measured. * A new unit setting ProtectHostname= may be used to prevent services from modifying hostname information (even if they otherwise would have privileges to do so). * A new unit setting NetworkNamespacePath= may be used to specify a namespace for service or socket units through a path referring to a Linux network namespace pseudo-file. * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now have an effect on .socket units: when used the listening socket is created within the configured network namespace instead of the host namespace. * ExecStart= command lines in unit files may now be prefixed with ':' in which case environment variable substitution is disabled. (Supported for the other ExecXYZ= settings, too.) * .timer units gained two new boolean settings OnClockChange= and OnTimezoneChange= which may be used to also trigger a unit when the system clock is changed or the local timezone is modified. systemd-run has been updated to make these options easily accessible from the command line for transient timers. * Two new conditions for units have been added: ConditionMemory= may be used to conditionalize a unit based on installed system RAM. ConditionCPUs= may be used to conditionalize a unit based on install CPU cores. * The @default system call filter group understood by SystemCallFilter= has been updated to include the new rseq() system call introduced in kernel 4.15. * A new time-set.target has been added that indicates that the system time has been set from a local source (possibly imprecise). The existing time-sync.target is stronger and indicates that the time has been synchronized with a precise external source. Services where approximate time is sufficient should use the new target. * "systemctl start" (and related commands) learnt a new --show-transaction option. If specified brief information about all jobs queued because of the requested operation is shown. * systemd-networkd recognizes a new operation state 'enslaved', used (instead of 'degraded' or 'carrier') for interfaces which form a bridge, bond, or similar, and an new 'degraded-carrier' operational state used for the bond or bridge maste
[systemd-devel] systemd prerelease 242-rc4
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v242-rc4.tar.gz NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * In .link files, MACAddressPolicy=persistent (the default) is changed to cover more devices. For devices like bridges, tun, tap, bond, and similar interfaces that do not have other identifying information, the interface name is used as the basis for persistent seed for MAC and IPv4LL addresses. The way that devices that were handled previously is not changed, and this change is about covering more devices then previously by the "persistent" policy. MACAddressPolicy=random may be used to force randomized MACs and IPv4LL addresses for a device if desired. Hint: the log output from udev (at debug level) was enhanced to clarify what policy is followed and which attributes are used. `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/` may be used to view this. * The .device units generated by systemd-fstab-generator and other generators do not automatically pull in the corresponding .mount unit as a Wants= dependency. This means that simply plugging in the device will not cause the mount unit to be started automatically. But please note that the mount unit may be started for other reasons, in particular if it is part of local-fs.target, and any unit which (transitively) depends on local-fs.target is started. * networkctl list/status/lldp now accept globbing wildcards for network interface names to match against all existing interfaces. * The $PIDFILE environment variable is set to point the absolute path configured with PIDFile= for processes of that service. * The fallback DNS server list was augmented with Cloudflare public DNS servers. Use `-Ddns-servers=` to set a different fallback. * A new special target usb-gadget.target will be started automatically when a USB Device Controller is detected (which means that the system is a USB peripheral). * A new unit setting CPUQuotaPeriodSec= assigns the time period relatively to which the CPU time quota specified by CPUQuota= is measured. * A new unit setting ProtectHostname= may be used to prevent services from modifying hostname information (even if they otherwise would have privileges to do so). * A new unit setting NetworkNamespacePath= may be used to specify a namespace for service or socket units through a path referring to a Linux network namespace pseudo-file. * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now have an effect on .socket units: when used the listening socket is created within the configured network namespace instead of the host namespace. * ExecStart= command lines in unit files may now be prefixed with ':' in which case environment variable substitution is disabled. (Supported for the other ExecXYZ= settings, too.) * .timer units gained two new boolean settings OnClockChange= and OnTimezoneChange= which may be used to also trigger a unit when the system clock is changed or the local timezone is modified. systemd-run has been updated to make these options easily accessible from the command line for transient timers. * Two new conditions for units have been added: ConditionMemory= may be used to conditionalize a unit based on installed system RAM. ConditionCPUs= may be used to conditionalize a unit based on install CPU cores. * The @default system call filter group understood by SystemCallFilter= has been updated to include the new rseq() system call introduced in kernel 4.15. * A new time-set.target has been added that indicates that the system time has been set from a local source (possibly imprecise). The existing time-sync.target is stronger and indicates that the time has been synchronized with a precise external source. Services where approximate time is sufficient should use the new target. * "systemctl start" (and related commands) learnt a new --show-transaction option. If specified brief information about all jobs queued because of the requested operation is shown. * systemd-networkd recognizes a new operation st
[systemd-devel] systemd prerelease 242-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v242-rc3.tar.gz NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * In .link files, MACAddressPolicy=persistent (the default) is changed to cover more devices. For devices like bridges, tun, tap, bond, and similar interfaces that do not have other identifying information, the interface name is used as the basis for persistent seed for MAC and IPv4LL addresses. The way that devices that were handled previously is not changed, and this change is about covering more devices then previously by the "persistent" policy. MACAddressPolicy=random may be used to force randomized MACs and IPv4LL addresses for a device if desired. Hint: the log output from udev (at debug level) was enhanced to clarify what policy is followed and which attributes are used. `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/` may be used to view this. * The .device units generated by systemd-fstab-generator and other generators do not automatically pull in the corresponding .mount unit as a Wants= dependency. This means that simply plugging in the device will not cause the mount unit to be started automatically. But please note that the mount unit may be started for other reasons, in particular if it is part of local-fs.target, and any unit which (transitively) depends on local-fs.target is started. * networkctl list/status/lldp now accept globbing wildcards for network interface names to match against all existing interfaces. * The $PIDFILE environment variable is set to point the absolute path configured with PIDFile= for processes of that service. * The fallback DNS server list was augmented with Cloudflare public DNS servers. Use `-Ddns-servers=` to set a different fallback. * A new special target usb-gadget.target will be started automatically when a USB Device Controller is detected (which means that the system is a USB peripheral). * A new unit setting CPUQuotaPeriodSec= assigns the time period relatively to which the CPU time quota specified by CPUQuota= is measured. * A new unit setting ProtectHostname= may be used to prevent services from modifying hostname information (even if they otherwise would have privileges to do so). * A new unit setting NetworkNamespacePath= may be used to specify a namespace for service or socket units through a path referring to a Linux network namespace pseudo-file. * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now have an effect on .socket units: when used the listening socket is created within the configured network namespace instead of the host namespace. * ExecStart= command lines in unit files may now be prefixed with ':' in which case environment variable substitution is disabled. (Supported for the other ExecXYZ= settings, too.) * .timer units gained two new boolean settings OnClockChange= and OnTimezoneChange= which may be used to also trigger a unit when the system clock is changed or the local timezone is modified. systemd-run has been updated to make these options easily accessible from the command line for transient timers. * Two new conditions for units have been added: ConditionMemory= may be used to conditionalize a unit based on installed system RAM. ConditionCPUs= may be used to conditionalize a unit based on install CPU cores. * The @default system call filter group understood by SystemCallFilter= has been updated to include the new rseq() system call introduced in kernel 4.15. * "systemctl start" (and related commands) learnt a new --show-transaction option. If specified brief information about all jobs queued because of the requested operation is shown. * systemd-networkd recognizes a new operation state 'enslaved', used (instead of 'degraded' or 'carrier') for interfaces which form a bridge, bond, or similar, and an new 'degraded-carrier' operational state used for the bond or bridge master interface when one of the enslaved devices is not operational. * .network files learnt the new IgnoreCarrierLoss= option for leaving netw
[systemd-devel] systemd prerelease 242-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v242-rc2.tar.gz NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * In .link files, MACAddressPolicy=persistent (the default) is changed to cover more devices. For devices like bridges, tun, tap, bond, and similar interfaces that do not have other identifying information, the interface name is used as the basis for persistent seed for MAC and IPv4LL addresses. The way that devices that were handled previously is not changed, and this change is about covering more devices then previously by the "persistent" policy. MACAddressPolicy=random may be used to force randomized MACs and IPv4LL addresses for a device if desired. Hint: the log output from udev (at debug level) was enhanced to clarify what policy is followed and which attributes are used. `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/` may be used to view this. * The .device units generated by systemd-fstab-generator and other generators do not automatically pull in the corresponding .mount unit as a Wants= dependency. This means that simply plugging in the device will not cause the mount unit to be started automatically. But please note that the mount unit may be started for other reasons, in particular if it is part of local-fs.target, and any unit which (transitively) depends on local-fs.target is started. * networkctl list/status/lldp now accept globbing wildcards for network interface names to match against all existing interfaces. * The $PIDFILE environment variable is set to point the absolute path configured with PIDFile= for processes of that service. * The fallback DNS server list was augmented with Cloudflare public DNS servers. Use `-Ddns-servers=` to set a different fallback. * A new special target usb-gadget.target will be started automatically when a USB Device Controller is detected (which means that the system is a USB peripheral). * A new unit setting CPUQuotaPeriodSec= assigns the time period relatively to which the CPU time quota specified by CPUQuota= is measured. * A new unit setting ProtectHostname= may be used to prevent services from modifying hostname information (even if they otherwise would have privileges to do so). * A new unit setting NetworkNamespacePath= may be used to specify a namespace for service or socket units through a path referring to a Linux network namespace pseudo-file. * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now have an effect on .socket units: when used the listening socket is created within the configured network namespace instead of the host namespace. * ExecStart= command lines in unit files may now be prefixed with ':' in which case environment variable substitution is disabled. (Supported for the other ExecXYZ= settings, too.) * .timer units gained two new boolean settings OnClockChange= and OnTimezoneChange= which may be used to also trigger a unit when the system clock is changed or the local timezone is modified. systemd-run has been updated to make these options easily accessible from the command line for transient timers. * Two new conditions for units have been added: ConditionMemory= may be used to conditionalize a unit based on installed system RAM. ConditionCPUs= may be used to conditionalize a unit based on install CPU cores. * The @default system call filter group understood by SystemCallFilter= has been updated to include the new rseq() system call introduced in kernel 4.15. * "systemctl start" (and related commands) learnt a new --show-transaction option. If specified brief information about all jobs queued because of the requested operation is shown. * systemd-networkd recognizes a new operation state 'enslaved', used (instead of 'degraded' or 'carrier') for interfaces which form a bridge, bond, or similar, and an new 'degraded-carrier' operational state used for the bond or bridge master interface when one of the enslaved devices is not operational. * .network files learnt the new IgnoreCarrierLoss= option for leaving netw
[systemd-devel] systemd prerelease 242-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v242-rc1.tar.gz NOTE: This is ☠️ pre-release☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * In .link files, MACAddressPolicy=persistent (the default) is changed to cover more devices. For devices like bridges, tun, tap, bond, and similar interfaces that do not have other identifying information, the interface name is used as the basis for persistent seed for MAC and IPv4LL addresses. The way that devices that were handled previously is not changed, and this change is about covering more devices then previously by the "persistent" policy. MACAddressPolicy=random may be used to force randomized MACs and IPv4LL addresses for a device if desired. Hint: the log output from udev (at debug level) was enhanced to clarify what policy is followed and which attributes are used. `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/` may be used to view this. * The .device units generated by systemd-fstab-generator and other generators do not automatically pull in the corresponding .mount unit as a Wants= dependency. This means that simply plugging in the device will not cause the mount unit to be started automatically. But please note that the mount unit may be started for other reasons, in particular if it is part of local-fs.target, and any unit which (transitively) depends on local-fs.target is started. * networkctl list/status/lldp now accept globbing wildcards for network interface names to match against all existing interfaces. * The $PIDFILE environment variable is set to point the absolute path configured with PIDFile= for processes of that service. * The fallback DNS server list was augmented with Cloudflare public DNS servers. Use `-Ddns-servers=` to set a different fallback. * A new special target usb-gadget.target will be started automatically when a USB Device Controller is detected (which means that the system is a USB peripheral). * A new unit setting CPUQuotaPeriodSec= assigns the time period relatively to which the CPU time quota specified by CPUQuota= is measured. * A new unit setting ProtectHostname= may be used to prevent services from modifying hostname information (even if they otherwise would have privileges to do so). * A new unit setting NetworkNamespacePath= may be used to specify a namespace for service or socket units through a path referring to a Linux network namespace pseudo-file. * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now have an effect on .socket units: when used the listening socket is created within the configured network namespace instead of the host namespace. * ExecStart= command lines in unit files may now be prefixed with ':' in which case environment variable substitution is disabled. (Supported for the other ExecXYZ= settings, too.) * .timer units gained two new boolean settings OnClockChange= and OnTimezoneChange= which may be used to also trigger a unit when the system clock is changed or the local timezone is modified. systemd-run has been updated to make these options easily accessible from the command line for transient timers. * Two new conditions for units have been added: ConditionMemory= may be used to conditionalize a unit based on installed system RAM. ConditionCPUs= may be used to conditionalize a unit based on install CPU cores. * The @default system call filter group understood by SystemCallFilter= has been updated to include the new rseq() system call introduced in kernel 4.15. * "systemctl start" (and related commands) learnt a new --show-transaction option. If specified brief information about all jobs queued because of the requested operation is shown. * systemd-networkd recognizes a new operation state 'enslaved', used (instead of 'degraded' or 'carrier') for interfaces which form a bridge, bond, or similar, and an new 'degraded-carrier' operational state used for the bond or bridge master interface when one of the enslaved devices is not operational. * .network files learnt the new IgnoreCarrierLoss= option for leaving netw
[systemd-devel] systemd 241 released
A new, official systemd release has just been tagged . Please download
the tarball here:
https://github.com/systemd/systemd/archive/v241.tar.gz
Changes since the previous release:
* The default locale can now be configured at compile time. Otherwise,
a suitable default will be selected automatically (one of C.UTF-8,
en_US.UTF-8, and C).
* The version string shown by systemd and other tools now includes the
git commit hash when built from git. An override may be specified
during compilation, which is intended to be used by distributions to
include the package release information.
* systemd-cat can now filter standard input and standard error streams
for different syslog priorities using the new --stderr-priority=
option.
* systemd-journald and systemd-journal-remote reject entries which
contain too many fields (CVE-2018-16865) and set limits on the
process' command line length (CVE-2018-16864).
* $DBUS_SESSION_BUS_ADDRESS environment variable is set by pam_systemd
again.
* A new network device NamePolicy "keep" is implemented for link files,
and used by default in 99-default.link (the fallback configuration
provided by systemd). With this policy, if the network device name
was already set by userspace, the device will not be renamed again.
This matches the naming scheme that was implemented before
systemd-240. If naming-scheme < 240 is specified, the "keep" policy
is also enabled by default, even if not specified. Effectively, this
means that if naming-scheme >= 240 is specified, network devices will
be renamed according to the configuration, even if they have been
renamed already, if "keep" is not specified as the naming policy in
the .link file. The 99-default.link file provided by systemd includes
"keep" for backwards compatibility, but it is recommended for user
installed .link files to *not* include it.
The "kernel" policy, which keeps kernel names declared to be
"persistent", now works again as documented.
* kernel-install script now optionally takes the paths to one or more
initrd files, and passes them to all plugins.
* The mincore() system call has been dropped from the @system-service
system call filter group, as it is pretty exotic and may potentially
used for side-channel attacks.
* -fPIE is dropped from compiler and linker options. Please specify
-Db_pie=true option to meson to build position-independent
executables. Note that the meson option is supported since meson-0.49.
* The fs.protected_regular and fs.protected_fifos sysctls, which were
added in Linux 4.19 to make some data spoofing attacks harder, are
now enabled by default. While this will hopefully improve the
security of most installations, it is technically a backwards
incompatible change; to disable these sysctls again, place the
following lines in /etc/sysctl.d/60-protected.conf or a similar file:
fs.protected_regular = 0
fs.protected_fifos = 0
Note that the similar hardlink and symlink protection has been
enabled since v199, and may be disabled likewise.
* The files read from the EnvironmentFile= setting in unit files now
parse backslashes inside quotes literally, matching the behaviour of
POSIX shells.
* udevadm trigger, udevadm control, udevadm settle and udevadm monitor
now automatically become NOPs when run in a chroot() environment.
* The tmpfiles.d/ "C" line type will now copy directory trees not only
when the destination is so far missing, but also if it already exists
as a directory and is empty. This is useful to cater for systems
where directory trees are put together from multiple separate mount
points but otherwise empty.
* A new function sd_bus_close_unref() (and the associated
sd_bus_close_unrefp()) has been added to libsystemd, that combines
sd_bus_close() and sd_bus_unref() in one.
* udevadm control learnt a new option for --ping for testing whether a
systemd-udevd instance is running and reacting.
Contributions from: Aaron Plattner, Alberts Muktupāvels, Alex Mayer,
Ayman Bagabas, Beniamino Galvani, Burt P, Chris Down, Chris Lamb, Chris
Morin, Christian Hesse, Claudius Ellsel, dana, Daniel Axtens, Daniele
Medri, Dave Reisner, David Santamaría Rogado, Diego Canuhe, Dimitri
John Ledkov, Evgeny Vereshchagin, Fabrice Fontaine, Filipe
Brandenburger, Franck Bui, Fra
Re: [systemd-devel] Delegate= on slice before v237
Hey Lennart, Thanks for the clarification. On Tue, Feb 12, 2019 at 2:17 AM Lennart Poettering wrote: > On Mo, 11.02.19 16:39, Filipe Brandenburger (filbran...@google.com) wrote: > > Before systemd v237 (when Delegate= was no longer allowed on slice > > units)... Did setting Delegate=yes on a slice have *any* effect at all? > > > > Or did it just do nothing (and a slice with Delegate=no or no setting > > behave just the same)? > > > > Reason I ask is: I want to scrap this code > > < > https://github.com/opencontainers/runc/blob/v1.0.0-rc6/libcontainer/cgroups/systemd/apply_systemd.go#L195 > > > > in libcontainer that tries to detect whether Delegate= is accepted in a > > slice unit. (I'll just default it to false, never try it.) > > > > I'd like to be able to say that Delegate=yes never really did anything at > > all on slice units... So I'm trying to confirm that is really the case > > before stating it. > > So, it wasn't supposed to do anything, and what it does differs on > cgroupsv2 and cgroupsv1. libcontainer is pretty much cgroupv1 only, so that's what I'm concerned about. > The fact it wasn't refused outright was an > accident, and because it was one I am not entirely sure what the > precise effect of allowing it was. However, I am pretty sure it at > least had two effects: > > 1. it would turn on all controllers for the cgroup > I don't *think* this is why libcontainer was trying to enable it, since a few lines down it's explicitly enabling all the controllers by setting MemoryAccounting, CPUAccounting and BlockIOAccounting during transient unit creation: https://github.com/opencontainers/runc/blob/v1.0.0-rc6/libcontainer/cgroups/systemd/apply_systemd.go#L275 > 2. it would stop systemd to ever migrating foreign processes below >that slice, which is primarily relevant only when changing cgroup >related props on the slice dynamically I guess. > I'm not sure I follow... Do you mean if libcontainer would write to memory.limit_in_bytes (or one of the other properties of the memory or other controller managed by systemd, such as cpu), then systemd would not end up overwriting this as it does some other operation on the cgroup? I'm not completely sure I understand what "migrate foreign processes" means, given slices don't really hold any pids directly... Do you mean to scope and service units below that slice? In any case, for now I'll probably leave that alone... Though as I revamp libcontainer support for unified hierarchy, I'll try to skip that check on that case, that might make this a legacy-only setting, so not that important to fully get rid of it for a while... Cheers! Filipe _______ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Missing PropertiesChanged signal for service start
Hi Lennart, I missed some details in the previous mail. This is seen on systemd 230. Unfortunately, I cannot do a systemd upgrade now. Subscribe() is done on org.freedesktop.systemd1 path =/org/freedesktop/systemd1 intf =org.freedesktop.systemd1.Manager. To make sure that the signal was not missed due to an error in the Subscribe() logic, I also ran a dbus-monitor script that runs "/usr/bin/dbus-monitor --system" and redirects it to a dbus-monitor log file. The dbus-monitor script is always guaranteed to run before the service in question so it doesn't miss any signal. I don't see any signal indicating active state in the dbus-monitor log file when the issue happens. Thanks Ashitha On Tue, Feb 12, 2019 at 2:14 AM Lennart Poettering wrote: > On Mo, 11.02.19 19:50, systemd Mailing List ( > systemd-devel@lists.freedesktop.org) wrote: > > > Hi, > > > > I have a service file as follows: > > > > [Unit] > > Description= "Daemon description" > > After=a.service > > < > https://opengrok-evo.juniper.net/source/s?path=mgd.service=EVO_TOT > > > > b.service < > https://opengrok-evo.juniper.net/source/s?path=mgd-api.service=EVO_TOT > > > > c.service < > https://opengrok-evo.juniper.net/source/s?path=jsd.service=EVO_TOT > > > > OnFailure=failure_handler@%p.service > > < > https://opengrok-evo.juniper.net/source/s?path=p.service=EVO_TOT> > > > > [Service] > > WorkingDirectory=/usr/sbin > > < > https://opengrok-evo.juniper.net/source/s?path=/usr/sbin=EVO_TOT> > > ExecStartPre=/bin/sleep > > < > https://opengrok-evo.juniper.net/source/s?path=/bin/sleep=EVO_TOT> > > 30 > > ExecStart= > > > > > > When this service starts I expected a signal indicating state=active. > > When I reboot the system multiple times, the signal indicating > > "active" is missing some times. > > > > I got the signal ActiveState=activating, SubState=start-pre at all > > times. But signal indicating ActiveState="active" and > > SubState="running" was missing for some reboots. > > > > The service is running and shows active state all the time. What is > > reason for missing signal? I am also checking if the sleep in the > > ExecStartPre is required for this > > > > service. I am wondering if that has something to do with the missing > signal. > > Have you called Subscribe() on the manager object? Unless there's at > least one client doing that (which hasn't dsiconnected yet) these > messages are not necessarily generated. > > Also, which systemd version is this? There have been some bugfixes in > this area in the past, hence make sure to run a current version of systemd. > > Lennart > > -- > Lennart Poettering, Red Hat > -- thanks Ashitha ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount a remote FS as a user
Hello, OK, thanks for the clarification. I was afraid that the situation is like you have described. Still it surprises me that even the sshfs case cannot be handled by user instance of systemd ... Do you have any information that the kernel is going to open autofs for unpriv clients? Or, could it be a way to write a d-bus capable daemon (or use/extend udisks or systemd capabilities?) which would handle the mounts for a particular user, i.e. a user would provide remote host+fs type+username+passwd+required mount point+access permissions and the daemon would mount it then for the user as required. Or has this way a security flow I don't see? Thanks, DT On Mon, Feb 11, 2019 at 6:27 PM Lennart Poettering wrote: > > On Mo, 11.02.19 15:59, Daniel Tihelka (dtihe...@gmail.com) wrote: > > > Hello, > > I can mount a shared file system (sshfs in particular) as an ordinary user. > > > > Now I would like to have it handled by systemd on-demand (automount). > > However, creating the automount unit and starting it fails with error: > > autofs (the kernel subsystem behin the .automount unit type) is > accessible to privileged clients only, and systemd --user is not > privileged in general. This means what you are trying to do is simply > not supported by the kernel. > > We could start supporting this if the kernel would open up autofs for > unpriv clients, like it did for fuse mounts. However, I don't see that > happening any time soon. > > Sorry! > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Missing PropertiesChanged signal for service start
Hi, I have a service file as follows: [Unit] Description= "Daemon description" After=a.service <https://opengrok-evo.juniper.net/source/s?path=mgd.service=EVO_TOT> b.service <https://opengrok-evo.juniper.net/source/s?path=mgd-api.service=EVO_TOT> c.service <https://opengrok-evo.juniper.net/source/s?path=jsd.service=EVO_TOT> OnFailure=failure_handler@%p.service <https://opengrok-evo.juniper.net/source/s?path=p.service=EVO_TOT> [Service] WorkingDirectory=/usr/sbin <https://opengrok-evo.juniper.net/source/s?path=/usr/sbin=EVO_TOT> ExecStartPre=/bin/sleep <https://opengrok-evo.juniper.net/source/s?path=/bin/sleep=EVO_TOT> 30 ExecStart= When this service starts I expected a signal indicating state=active. When I reboot the system multiple times, the signal indicating "active" is missing some times. I got the signal ActiveState=activating, SubState=start-pre at all times. But signal indicating ActiveState="active" and SubState="running" was missing for some reboots. The service is running and shows active state all the time. What is reason for missing signal? I am also checking if the sleep in the ExecStartPre is required for this service. I am wondering if that has something to do with the missing signal. Thanks Ashitha ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd.link MACAddress= matches OpenVPN tun device
Name : systemd (commit c38499d476026d999558a7eee9c95ca2fa41e115) Version : 239.2-1 I have a systemd.link file that gives my usb modem a more recognizable name. I saw some renaming errors in the journal and noticed that systemd also tried to rename my VPN device. This shouldn't happen and I investigated. Here's the result: It appears that the `50-usbmodem.link` file is being applied to the `tunvpn` device, even though the file has a MACAddress filter to match only the usbmodem. I have the following file: /etc/systemd/network/50-usbmodem.link [Match] MACAddress=aa:bb:cc:dd:ee:ff [Link] Name=usbmodem And by running the following command, it can be seen that the problem really occurs. $ udevadm test-builtin net_setup_link /sys/class/net/tunvpn/ calling: test-builtin Load module index Parsed configuration file /etc/systemd/network/50-usbmodem.link Created link configuration context. ID_NET_DRIVER=tun Config file /etc/systemd/network/50-usbmodem.link applies to device tunvpn link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. ID_NET_LINK_FILE=/etc/systemd/network/50-usbmodem.link ID_NET_NAME=usbmodem Unload module index Unloaded link configuration context. The tun device has no ethernet address, as it's a L3 interface, so the MACAddress really really shouldn't match. $ ip link show tunvpn xx: tunvpn: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100 link/none I fixed this temporarily by adding the following line to the [Match] section: Driver=huawei_cdc_ncm I'm not entirely sure, but this appears to be a bug. Maybe relevant section: https://github.com/systemd/systemd/blob/c38499d476026d999558a7eee9c95ca2fa41e115/src/udev/net/link-config.c#L218 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Allow acpi_index and index to be "0"
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20180928204605.55321-1-joe.hershberger%40ni.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] meson: use the host architecture compiler/linker for src/boot/efi
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20180927151736.GA17486%40alf.mars> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where does resolved takes its data from?
systemd-resolved has a DBUS API, which is used by network configuration managers such as systemd-networkd and NetworkManager to set the hostname resolution -related configuration to be used by systemd-resolved. You can see the runtime configuration of systemd-resolved by running `systemd-resolve --status`. To see what protocols (DNS, LLMNR, MDNS) are used to resolve a specific hostname, use `systemd-resolve somemachine.local`, for example. The protocols that are used during hostname resolution can be toggled per-interface using the same command, or they can be set via the DBUS API by some network configuration manager. Caution: The following is "as far as I know": Please note that the systemd-resolved DBUS API provides methods to do hostname resolution with more control over the resolution method than the functions provided by GNU C libraries. These latter functions inspect `hosts:` entry of `/etc/nsswitch.conf` to determine plugins that are used to do hostname resolution, one of which should be `resolve` to direct queries to systemd-resolved in case the GNU C hostname resolution API is used. Sorry if this veered into the territory of "I didn't ask this question". I just thought that clarifying the whole picture could help in better setting up hostname resolution. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V1] Add L3 cache allocation settings in systemd
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:561f901e-02c7-2212-bf5a-753952627b73%40huawei.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix strerror_r segfault on non-glibc systems
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20180329114130.14928-1-adi%40adirat.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20171129153842.14353-1-olaf%40aepfle.de> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH weston] doc/systemd: system service example
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:6ea0792d-6e90-af6e-195e-ffb42f8a0e62%40smile.fr> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] udev rules: add by-location symlinks to nvme devices
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20171128220027.11709-1-charles_rose%40dell.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH weston] doc/systemd: system service example
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20171128101429.22298-1-ppaalanen%40gmail.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev rules: add by-location symlinks to nvme devices
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20171103194329.17045-1-charles.rose%40dell.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM
Hi, I'm trying to figure out the right way of using an LUKS-encrypted LV with systemd-nspawn. I've got an LV called "containername" which is LUKS-encrypted, and I start the container using: systemd-nspawn --boot --image=/dev/vg/containername it asks me for the LUKS passphrase, and it seems to work OK on the command line. However, just a few questions: 1) is there any advantage to using a single-partition GPT instead of no partition and a filesystem? 2) machinectl list-images doesn't detect the images in LVs; am I supposed to (auto)mount them in /var/lib/machines/ ? 3) how do I best enable this on boot? "machinectl enable" won't work since it doesn't know which image to use. Is there an example of a systemd unit file for an image-based nspawn container? Thanks, -- M ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: load drivers only on "add" events
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20170911184738.GA11495%40dtor-ws> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: add statx(2) to @file-system syscall filter list
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20170902194754.529360-1-crrodriguez%40opensuse.org> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add handling for bind/unbind actions
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20170901015420.GA10661%40dtor-ws> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] 50-udev-default.rules.in: set correct group for mediaX/cecX
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:072f4734-5636-7a9d-2151-5fb95e48a262%40xs4all.nl> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add LIB_ARCH_TUPLE for tilegx-linux-gnu
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20170227155101.pp4wtshmqbnlgnus%40alf.mars> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hostnamed: regard convertible chassis type as laptop
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1487948412-19888-1-git-send-email-jani.nikula%40intel.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev rules: add udev rule to create /dev/ptp_kvm
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20170224012031.GA13192%40amt.cnet> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] ima: Write the policy filename into IMA's sysfs policy file
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1480360640-30704-2-git-send-email-stefanb%40linux.vnet.ibm.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] architecture: Add support for the RISC-V architecture.
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1475250301-26221-2-git-send-email-rjones%40redhat.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vconsole-setup: updates & fixes
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1467420836-32316-2-git-send-email-soltys%40ziu.info> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: block - add scm block devices to whitelist
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:alpine.LFD.2.20.1606092138070.1728%40schleppi> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] architecture: Add nios2
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1461978784-6374-1-git-send-email-marex%40denx.de> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHSET RE-RESEND] update unified hierarchy support
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20160325183400.GA5583%40htj.duckdns.org> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: mount new devpts instance for PrivateDevices=yes (was: PrivateDevices=yes and /dev/ptmx)
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:nc4cv9$qti$1%40ger.gmane.org> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix 'slave'/'private' confusion
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:nbplgr$to6$1%40ger.gmane.org> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] keymap: remap microphone mute keycode for Lenovo Thinkcentre M800z
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1452047873-6043-1-git-send-email-hui.wang%40canonical.com> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] basic: fix build on architectures with small long
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20151122074308.GA7173%40alf.mars> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] basic: fix build on architectures with small long
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: <https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20151119231310.GA16572%40alf.mars> -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
