[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 key only accessible in the initrd, but not
Re: [systemd-devel] Is there a way to find out if Delegate=yes?
On Mon, Oct 24, 2022 at 06:07:39PM +0300, Yuri Kanivetsky wrote: > Hi, > > I'm experimenting with LXC containers: > > https://linuxcontainers.org/lxc/getting-started/ > > And there's a command I don't fully understand: > > systemd-run --unit=my-unit --user --scope -p "Delegate=yes" -- > lxc-start my-container > > It runs lxc-start in a transient user scope with Delegate=yes, but: > > $ systemctl show -p Delegate run-scope > Delegate=no You're not passing `--user` to systemctl(1). The output of `systemctl show` on a non-existent unit might be misleading. > > That's on an Ubuntu server. Locally on Arch Linux I don't need > systemd-run, lxc-start just works. > > How can I see the effect of systemd-run, and why systemd-run is not > needed on Arch Linux? signature.asc Description: PGP signature
[systemd-devel] Is there a way to find out if Delegate=yes?
Hi, I'm experimenting with LXC containers: https://linuxcontainers.org/lxc/getting-started/ And there's a command I don't fully understand: systemd-run --unit=my-unit --user --scope -p "Delegate=yes" -- lxc-start my-container It runs lxc-start in a transient user scope with Delegate=yes, but: $ systemctl show -p Delegate run-scope Delegate=no That's on an Ubuntu server. Locally on Arch Linux I don't need systemd-run, lxc-start just works. How can I see the effect of systemd-run, and why systemd-run is not needed on Arch Linux?
Re: [systemd-devel] Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
On Mon, Oct 24, 2022 at 1:24 PM Ulrich Windl wrote: > > > > > What do you call a "recursive start"? "systemctl start" simply tells > > starting multi-user.target via ExecStart=systemctl start starts all depending > units, and probably one of those starts the multi-user.target again. > That's what I call recursive. > > > systemd to queue the start job. If this job is already queued, nothing > > happens. If this job has already been completed (successfully), > > nothing happens. > > So I wonder why the command "ExecStart=systemctl start --no-block > multi-user.target" has any effect then. > Because it also recursively queues start jobs for all Want'ed or Require'd units even if multi-user.target itself is already started. This allows you to catch up on new dependencies.
Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
On Mo, 24.10.22 12:24, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Andrei Borzenkov schrieb am 24.10.2022 um 10:26 in > Nachricht > : > > On Mon, Oct 24, 2022 at 9:48 AM Ulrich Windl > > wrote: > >> > >> >>> Alex Aminoff schrieb am 21.10.2022 um 18:11 in > >> >>> Nachricht > >> : > >> > >> ... > >> > Just to close out this thread, I am happy to report that > >> > > >> > ExecStart=systemctl start --no-block multi-user.target > >> > > >> > worked great. > >> > >> Makes me wonder: How does systemd handle indirect recursive starts (like > >> the > > one shown)? > >> > > > > What do you call a "recursive start"? "systemctl start" simply tells > > starting multi-user.target via ExecStart=systemctl start starts all depending > units, and probably one of those starts the multi-user.target again. > That's what I call recursive. If you enqueue a unit for starting while it is already enqueued for starting this has no effect. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: Re: Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
>>> Andrei Borzenkov schrieb am 24.10.2022 um 10:26 in Nachricht : > On Mon, Oct 24, 2022 at 9:48 AM Ulrich Windl > wrote: >> >> >>> Alex Aminoff schrieb am 21.10.2022 um 18:11 in >> >>> Nachricht >> : >> >> ... >> > Just to close out this thread, I am happy to report that >> > >> > ExecStart=systemctl start --no-block multi-user.target >> > >> > worked great. >> >> Makes me wonder: How does systemd handle indirect recursive starts (like the > one shown)? >> > > What do you call a "recursive start"? "systemctl start" simply tells starting multi-user.target via ExecStart=systemctl start starts all depending units, and probably one of those starts the multi-user.target again. That's what I call recursive. > systemd to queue the start job. If this job is already queued, nothing > happens. If this job has already been completed (successfully), > nothing happens. So I wonder why the command "ExecStart=systemctl start --no-block multi-user.target" has any effect then. > > Where recursion come from? See above.
Re: [systemd-devel] Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
On Mon, Oct 24, 2022 at 9:48 AM Ulrich Windl wrote: > > >>> Alex Aminoff schrieb am 21.10.2022 um 18:11 in > >>> Nachricht > : > > ... > > Just to close out this thread, I am happy to report that > > > > ExecStart=systemctl start --no-block multi-user.target > > > > worked great. > > Makes me wonder: How does systemd handle indirect recursive starts (like the > one shown)? > What do you call a "recursive start"? "systemctl start" simply tells systemd to queue the start job. If this job is already queued, nothing happens. If this job has already been completed (successfully), nothing happens. Where recursion come from?
[systemd-devel] Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
>>> Alex Aminoff schrieb am 21.10.2022 um 18:11 in Nachricht : ... > Just to close out this thread, I am happy to report that > > ExecStart=systemctl start --no-block multi-user.target > > worked great. Makes me wonder: How does systemd handle indirect recursive starts (like the one shown)?
