Re: [systemd-devel] After= and Wants= doesn't seem to have an effect
On 20.12.2021 17:05, Christopher Wong wrote: >> # /etc/systemd/system/iris-detection.service >> [Unit] >> Description=Iris detection >> PartOf=opticsd.service > > > How can you tell that it is a loop? iris-detection.service doesn't have any > After= as you stated below. Yes, sorry, you are right. > Is it due to the PartOf=opticsd.service? > I do not think so. Still, loop is possible due to some other dependencies, it is also possible that actual unit definitions are different (e.g. units files have been changed after systemd read them). Running with debig log level may give some more hints. > > Best Regards, > > Christopher Wong > > > From: systemd-devel on behalf > of Andrei Borzenkov > Sent: Monday, December 20, 2021 1:27:42 PM > To: systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] After= and Wants= doesn't seem to have an effect > > On 20.12.2021 15:06, Christopher Wong wrote: >> # /etc/systemd/system/iris-detection.service >> After=temperature-controller.service >> >> # /usr/lib/systemd/system/temperature-controller.service >> After=iris-detection.service > > This is loop and systemd is free to break it by ignoring some dependency. >
[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. * When showing unit status
Re: [systemd-devel] After= and Wants= doesn't seem to have an effect
> # /etc/systemd/system/iris-detection.service > [Unit] > Description=Iris detection > PartOf=opticsd.service How can you tell that it is a loop? iris-detection.service doesn't have any After= as you stated below. Is it due to the PartOf=opticsd.service? Best Regards, Christopher Wong From: systemd-devel on behalf of Andrei Borzenkov Sent: Monday, December 20, 2021 1:27:42 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] After= and Wants= doesn't seem to have an effect On 20.12.2021 15:06, Christopher Wong wrote: > # /etc/systemd/system/iris-detection.service > After=temperature-controller.service > > # /usr/lib/systemd/system/temperature-controller.service > After=iris-detection.service This is loop and systemd is free to break it by ignoring some dependency.
Re: [systemd-devel] the need for a discoverable sub-volumes specification
On Fr, 10.12.21 12:25, Chris Murphy (li...@colorremedies.com) wrote: > On Thu, Nov 11, 2021 at 12:28 PM Lennart Poettering > wrote: > > > That said: naked squashfs sucks. Always wrap your squashfs in a GPT > > wrapper to make things self-descriptive. > > Do you mean the image file contains a GPT, and the squashfs is a > partition within the image? Does this recommendation apply to any > image? Let's say it's a Btrfs image. And in the context of this > thread, the GPT partition type GUID would be the "super-root" GUID? Yes, I'd always add a GPT wrapper around disk images. It's simple, extensible and first and foremost self-descriptive: you know what you are looking at, safely, before parsing the fs. It opens the door for adding verity data in a very natural way, and more. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] After= and Wants= doesn't seem to have an effect
On 20.12.2021 15:06, Christopher Wong wrote: > # /etc/systemd/system/iris-detection.service > After=temperature-controller.service > > # /usr/lib/systemd/system/temperature-controller.service > After=iris-detection.service This is loop and systemd is free to break it by ignoring some dependency.
Re: [systemd-devel] Q: When will WorkingDirectory be checked?
On Fr, 17.12.21 08:11, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > I have a simple question: When will WorkingDirectory be checked? > Specifically: Will it be checked before ExecStartPre? I could not > get it form the manual page. What do you mean by "checked"? Lennart -- Lennart Poettering, Berlin
[systemd-devel] After= and Wants= doesn't seem to have an effect
Hi, I got a case were After= and Wants= doesn't seem to have an effect for the opticsd.service. ./info.log.1:2021-12-17T21:30:02.684+00:00 [ INFO] systemd[1]: Starting Iris detection... ./info.log.1:2021-12-17T21:30:02.884+00:00 [ INFO] systemd[1]: Starting Wiper power manager... ./info.log.1:2021-12-17T21:30:02.886+00:00 [ INFO] systemd[1]: Starting Optics daemon... ./info.log.1:2021-12-17T21:30:02.888+00:00 [ INFO] systemd[1]: Started Optics daemon. ./info.log.1:2021-12-17T21:30:02.890+00:00 [ INFO] systemd[1]: Started Wiper power manager. ./info.log.1:2021-12-17T21:30:02.890+00:00 [ INFO] systemd[1]: Starting Temperature controller... ./info.log.1:2021-12-17T21:30:02.895+00:00 [ INFO] systemd[1]: Started Temperature controller. # /usr/lib/systemd/system/coco-wiper-manager.service [Unit] Description=Wiper power manager Before=temperature-controller.service wiper-service.service ... [Install] WantedBy=temperature-controller.service wiper-service.service # /etc/systemd/system/opticsd.service [Unit] Description=Optics daemon ... After=iris-detection.service Wants=iris-detection.service After=temperature-controller.service Wants=temperature-controller.service ... [Install] WantedBy=multi-user.target # /etc/systemd/system/iris-detection.service [Unit] Description=Iris detection PartOf=opticsd.service # /usr/lib/systemd/system/wiper-service.service [Unit] Description=Wiper Service Wants=temperature-controller.service After=temperature-controller.service # /usr/lib/systemd/system/temperature-controller.service [Unit] Description=Temperature controller ... After=iris-detection.service Wants=iris-detection.service Is it possible that After= is ignored, even if Wants= is specified? Best Regards, Christopher Wong
