Re: [systemd-devel] systemd-run --user when lingering is disabled.
On Mo, 09.09.24 13:12, Steve Traylen (steve.tray...@cern.ch) wrote: > > Example with lingering **disabled** > > root> systemd-run --service-type=exec --user --machine eric@.host > /usr/bin/sleep 1m > > With this > > The systemd --user instance is started for Eric and also the sleep is > started. > > However after < 10 seconds or so the transient unit and user service is all > shutdown taking the sleep with it. > > Logs: > > Sep 09 12:54:43 fedora systemd[1]: Created slice user-1001.slice - User > Slice of UID 1001. > Sep 09 12:54:43 fedora systemd[1]: Starting user-runtime-dir@1001.service - > User Runtime Directory /run/user/1001... > Sep 09 12:54:43 fedora systemd[1]: Finished user-runtime-dir@1001.service - > User Runtime Directory /run/user/1001. > Sep 09 12:54:43 fedora systemd[1]: Started user@1001.service - User Manager > for UID 1001. > > Sep 09 12:54:43 fedora dbus-broker-launch[5340]: Ready > Sep 09 12:54:43 fedora systemd[5318]: Starting run-u0.service - > /usr/bin/sleep 1m... > Sep 09 12:54:43 fedora systemd[5318]: Started run-u0.service - > /usr/bin/sleep 1m. > Sep 09 12:54:43 fedora (sd-pam)[5338]: pam_selinux(login:session): Setting > file context "unconfined_u:object_r:user_devpts_t:s0" failed for /dev/pts/1: > Operation not permitted > Sep 09 12:54:43 fedora systemd[1]: run-u262.service: Deactivated > successfully. > Sep 09 12:54:43 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 > ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=run-u262 > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? > res=success' > Sep 09 12:54:43 fedora (sd-pam)[5338]: pam_unix(login:session): session > closed for user eric > Sep 09 12:54:43 fedora systemd[1]: session-26.scope: Deactivated > successfully. > > ... > Sep 09 12:54:53 fedora systemd[1]: Stopping user@1001.service - User Manager > for UID 1001... > Sep 09 12:54:53 fedora systemd[5318]: Activating special unit exit.target... > > > I would have hoped the `systemd --user` instance to hang around as long as > systemd-run sleep invocation. Then use lingering. By default a user's service manager is stopped after their last session ends. (We do not act immediately on that however, but with a 10s delay, as you rmight notice, to optimize for cases where people quickly log out/log back in via ssh in scripts or suchlike). This is supposed to be a security feature to some degree: not allowing users to consume unbounded resources on a system without actually being logged in. If you actually want to allow this, then enable lingering, it's precisely the usecase it is intended for. Lennart -- Lennart Poettering, Berlin
[systemd-devel] systemd-run --user when lingering is disabled.
Example with lingering **disabled** root> systemd-run --service-type=exec --user --machine eric@.host /usr/bin/sleep 1m With this The systemd --user instance is started for Eric and also the sleep is started. However after < 10 seconds or so the transient unit and user service is all shutdown taking the sleep with it. Logs: Sep 09 12:54:43 fedora systemd[1]: Created slice user-1001.slice - User Slice of UID 1001. Sep 09 12:54:43 fedora systemd[1]: Starting user-runtime-dir@1001.service - User Runtime Directory /run/user/1001... Sep 09 12:54:43 fedora systemd[1]: Finished user-runtime-dir@1001.service - User Runtime Directory /run/user/1001. Sep 09 12:54:43 fedora systemd[1]: Started user@1001.service - User Manager for UID 1001. Sep 09 12:54:43 fedora dbus-broker-launch[5340]: Ready Sep 09 12:54:43 fedora systemd[5318]: Starting run-u0.service - /usr/bin/sleep 1m... Sep 09 12:54:43 fedora systemd[5318]: Started run-u0.service - /usr/bin/sleep 1m. Sep 09 12:54:43 fedora (sd-pam)[5338]: pam_selinux(login:session): Setting file context "unconfined_u:object_r:user_devpts_t:s0" failed for /dev/pts/1: Operation not permitted Sep 09 12:54:43 fedora systemd[1]: run-u262.service: Deactivated successfully. Sep 09 12:54:43 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=run-u262 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 09 12:54:43 fedora (sd-pam)[5338]: pam_unix(login:session): session closed for user eric Sep 09 12:54:43 fedora systemd[1]: session-26.scope: Deactivated successfully. ... Sep 09 12:54:53 fedora systemd[1]: Stopping user@1001.service - User Manager for UID 1001... Sep 09 12:54:53 fedora systemd[5318]: Activating special unit exit.target... I would have hoped the `systemd --user` instance to hang around as long as systemd-run sleep invocation. Enabling linger first and then all is good. Would rather not enable linger. Switching to `--service-type` one shot also works but then the systemd-run is sync rather than async. Motivation - Trying to move away from `echo "/usr/bin/sleep 1m" | su - eric - & `. Steve. Tested on fedora rawhide, systemd-256.5.
Re: [systemd-devel] systemd-coredump[25256]: AT_NULL terminator not found, cannot parse auxv structure.
On Tue, Aug 27, 2024 at 12:21 PM Windl, Ulrich wrote: > > Hi! > > > > I have an issue where Perl dumps core for no obvious reason, and I noticed > the line > > systemd-coredump[25256]: AT_NULL terminator not found, cannot parse auxv > structure. > It parses /proc/$PIF/auxv and apparently it was malformed. Look at "hexdump -C" or similar, it should end with the line full of zeroes. > In the journal. > > > > Can anybody explain what it actually means? System is SLES12 SP5 on x86_64 > (systemd-228-157.60.1.x86_64). > > > > Context is like this: > > > > Aug 27 10:41:11 abcdefgh systemd-coredump[25256]: Process 24393 (perl) of > user 1025 dumped core. > > > > Stack trace of thread 24393: > > #0 0x7f89eb457397 kill > (libc.so.6) > > #1 0x004fe592 > Perl_apply (perl) > > #2 0x004f2863 > Perl_pp_chown (perl) > > #3 0x004a4166 > Perl_runops_standard (perl) > > #4 0x004370c8 > Perl_call_sv (perl) > > #5 0x00493c24 > Perl_sighandler (perl) > > #6 0x7f89eb5d5ce0 > __restore_rt (libpthread.so.0) > > #7 0x004a47c0 > Perl_pp_const (perl) > > #8 0x004a4166 > Perl_runops_standard (perl) > > #9 0x0043e041 > perl_run (perl) > > #10 0x0041e9d3 main > (perl) > > #11 0x7f89eb442ac5 > __libc_start_main (libc.so.6) > > #12 0x0041ea0b > _start (perl)
[systemd-devel] systemd-coredump[25256]: AT_NULL terminator not found, cannot parse auxv structure.
Hi! I have an issue where Perl dumps core for no obvious reason, and I noticed the line systemd-coredump[25256]: AT_NULL terminator not found, cannot parse auxv structure. In the journal. Can anybody explain what it actually means? System is SLES12 SP5 on x86_64 (systemd-228-157.60.1.x86_64). Context is like this: Aug 27 10:41:11 abcdefgh systemd-coredump[25256]: Process 24393 (perl) of user 1025 dumped core. Stack trace of thread 24393: #0 0x7f89eb457397 kill (libc.so.6) #1 0x004fe592 Perl_apply (perl) #2 0x004f2863 Perl_pp_chown (perl) #3 0x004a4166 Perl_runops_standard (perl) #4 0x004370c8 Perl_call_sv (perl) #5 0x00493c24 Perl_sighandler (perl) #6 0x7f89eb5d5ce0 __restore_rt (libpthread.so.0) #7 0x004a47c0 Perl_pp_const (perl) #8 0x004a4166 Perl_runops_standard (perl) #9 0x0043e041 perl_run (perl) #10 0x0041e9d3 main (perl) #11 0x7f89eb442ac5 __libc_start_main (libc.so.6) #12 0x0041ea0b _start (perl)
Re: [systemd-devel] systemd v257 git: systemctl reboot and logged in users
On Thu, Aug 22, 2024 at 3:29 PM Lennart Poettering wrote: > > On Do, 08.08.24 13:56, Thorsten Kukuk (ku...@suse.com) wrote: > > > Hi, > > > > with current systemd v257 git, if I want to reboot as user with "run0 > > systemctl reboot" or "sudo systemctl soft-reboot", this is now > > prohibited because I'm still logged in: > > > > "User kukuk is logged in on pts/0. > > Please retry operation after closing inhibitors and logging out other > > users." > > > > Now this are remote machines where you cannot login directly as root > > for audit reasons. Nothing uncommon. > > How should this work? I'm afraid admins will quickly use "systemctl > > reboot -i" by default or make even an alias for this, which makes this > > idea/change void. > > > > Is this really wanted? Or is this behavior a bug and a normal user > > should be able to call systemctl reboot with run0/sudo without > > blocking it like as logged in as root? > > Could you file an issue about this, please? https://github.com/systemd/systemd/issues/34086 Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Re: [systemd-devel] systemd v257 git: systemctl reboot and logged in users
On Do, 08.08.24 13:56, Thorsten Kukuk (ku...@suse.com) wrote: > Hi, > > with current systemd v257 git, if I want to reboot as user with "run0 > systemctl reboot" or "sudo systemctl soft-reboot", this is now > prohibited because I'm still logged in: > > "User kukuk is logged in on pts/0. > Please retry operation after closing inhibitors and logging out other users." > > Now this are remote machines where you cannot login directly as root > for audit reasons. Nothing uncommon. > How should this work? I'm afraid admins will quickly use "systemctl > reboot -i" by default or make even an alias for this, which makes this > idea/change void. > > Is this really wanted? Or is this behavior a bug and a normal user > should be able to call systemctl reboot with run0/sudo without > blocking it like as logged in as root? Could you file an issue about this, please? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-journald persistent storage unkown file descriptor error
On Fr, 26.07.24 09:59, Gregory Gincley (rollenwi...@yahoo.com) wrote: > > To whom it may concern: > > I'm receiving the below error on every systemd-journald service > startup. > > While systemd-journald starts, it refuses to log to persistent storage > (/var/log/journal) despite this path existing. Additionally --user > shows no journal information. > > I've tried deleting/recreating /var/log/journal > > I've tried setting /etc/systemd/journald.conf 'Storage' setting to both > 'auto' and 'peristent' with the same result. > > https://github.com/systemd/systemd/blob/eef4cd51f94d837bd0e71512c831634a2902522d/src/journal/journald-server.c#L2764 > > FWIW I'm on Arch Linux. > > Any thoughts on what is preventing my logging from flushing to disk? > > Let me know if any additional information would be helpful. Always include relevant log output in reports like this. Always include information about systemd version. Otherwise, it's not an actionable report, sorry. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-measure in cross compile environment, and measured-uki vs tpm2 in ConditionSecurity?
On Fr, 09.08.24 14:49, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > Hi, > > After update from systemd 254 to 256 (and even 256.4) I had some failures > related to TPM related services depending on ConditionSecurity=measured-uki. > > I have basic ukify.py and sbsign signatures working in yocto cross compile > environment but I have doubts that systemd-measure will work there. > It looks like systemd-measure in src/boot/measure.c open TPM devices files > to calculate the PCR values and this doesn't work in cross compile > environment. > Thus it looks systemd-measure and ukify.py --measure will not work in > yocto, at least without qemu and swtpm hacks. Am I right on this? It should work fine in "offline" mode. It only talks to a TPM if you invoke it with the "status" verb. But you wouldn't do that for signing. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Systemd Boot Time Optimization
Hi Barry, Thanks for your reply. On 16/08/24 12:50 pm, Barry wrote: > [You don't often get email from ba...@barrys-emacs.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > >> On 18 Jul 2024, at 07:31, dharm...@microchip.com wrote: >> >> Is it possible to achieve faster boot times on arm v5 and cortex a5 >> these architectures similar to cortex a7 by tuning systemd? > > I expect you are see speeds that are I/O limited. > You have the tools with system-analyse to root cause this. Could you please shed some light on those tools? > Only you have the hardware and software to investigate this. Could you please comment on this as well ? root@sam9x60-curiosity-sd:~# systemd-analyze blame 6.984s dev-mmcblk0p2.device 5.120s systemd-udev-trigger.service 3.063s systemd-networkd.service 1.938s systemd-journald.service 1.850s systemd-timesyncd.service 1.826s systemd-resolved.service 995ms systemd-fsck-root.service Could you please let us know how to further breakdown the time taken by "dev-mmcblk0p2.device" as we don't get anything with systemd-analyze critical-chain dev-mmcblk0p2.device The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. dev-mmcblk0p2.device +6.984s > > Barry > -- With Best Regards, Dharma B.
Re: [systemd-devel] Systemd Boot Time Optimization
> On 18 Jul 2024, at 07:31, dharm...@microchip.com wrote: > > Is it possible to achieve faster boot times on arm v5 and cortex a5 > these architectures similar to cortex a7 by tuning systemd? I expect you are see speeds that are I/O limited. You have the tools with system-analyse to root cause this. Only you have the hardware and software to investigate this. Barry
[systemd-devel] systemd-measure in cross compile environment, and measured-uki vs tpm2 in ConditionSecurity?
Hi, After update from systemd 254 to 256 (and even 256.4) I had some failures related to TPM related services depending on ConditionSecurity=measured-uki. I have basic ukify.py and sbsign signatures working in yocto cross compile environment but I have doubts that systemd-measure will work there. It looks like systemd-measure in src/boot/measure.c open TPM devices files to calculate the PCR values and this doesn't work in cross compile environment. Thus it looks systemd-measure and ukify.py --measure will not work in yocto, at least without qemu and swtpm hacks. Am I right on this? As an alternative I can switch ConditionSecurity from measured-uki back to tpm2 which was working with v254 and backported tpm2.target. Without measured-uki, creating the TPM2 backed encrypted rootfs works[1] but just mounting it in initrd fails which is a bit odd. Would have expected that creating it with systemd-repart also fails if measured-uki isn't true. I guess in an environment where I rely on UEFI secure boot to cover full uki binary, measured-uki doesn't bring any benefits in addition to plain tpm2 in ConditionSecurity. What's the usecase then? [1] https://people.linaro.org/~mikko.rapeli/systemd_256_tpm2_rootfs_fail.txt Cheers, -Mikko
[systemd-devel] systemd v257 git: systemctl reboot and logged in users
Hi, with current systemd v257 git, if I want to reboot as user with "run0 systemctl reboot" or "sudo systemctl soft-reboot", this is now prohibited because I'm still logged in: "User kukuk is logged in on pts/0. Please retry operation after closing inhibitors and logging out other users." Now this are remote machines where you cannot login directly as root for audit reasons. Nothing uncommon. How should this work? I'm afraid admins will quickly use "systemctl reboot -i" by default or make even an alias for this, which makes this idea/change void. Is this really wanted? Or is this behavior a bug and a normal user should be able to call systemctl reboot with run0/sudo without blocking it like as logged in as root? Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Re: [systemd-devel] systemd accepts fix to stable releases
Hello. On Mon, Jul 22, 2024 at 12:41:18PM GMT, "Rajmohan. R" wrote: > Asking on doubtful that, whether fix will be accepted in systemd-stable (for > instance, version 255.4) release branch. That depends what the fix is (how "stable"), generally, refer to the docs here https://systemd.io/BACKPORTS/ HTH, Michal signature.asc Description: PGP signature
Re: [systemd-devel] Systemd Boot Time Optimization
Hi, Gentle reminder on this query. On 18/07/24 11:52 am, Dharma B wrote: > Hi Everyone, > > We have recently migrated from sysvinit to systemd on our platforms, > including sam9, sama5, and sama7 which feature various ARM architectures > such as ARMv5, Cortex-A5, and Cortex-A7. > > We observed different performance levels across these architectures, > detailed as follows: > > Performance comparison between three architectures using the > core-image-minimal recipe in Yocto Project with a high-speed HP 64GB XC > 100MB/s SD card. > > *** > > ARMv5 - sam9 > > Startup finished in 2.113s (kernel) + 14.090s (userspace) = 16.203s > multi-user.target reached after 14.080s in userspace > > Cortex-A5 - sama5 > > Startup finished in 2.254s (kernel) + 13.216s (userspace) = 15.470s > multi-user.target reached after 13.185s in userspace > > Cortex A7 - sama7 > > Startup finished in 1.967s (kernel) + 6.302s (userspace) = 8.270s > multi-user.target reached after 6.271s in userspace > > *** > > We noted that the following services take significantly longer on the > ARMv5 and Cortex-A5 architectures: > > root@sam9x60-curiosity-sd:~# systemd-analyze blame > 6.984s dev-mmcblk0p2.device > 5.120s systemd-udev-trigger.service > 3.063s systemd-networkd.service > 1.938s systemd-journald.service > 1.850s systemd-timesyncd.service > 1.826s systemd-resolved.service > 995ms systemd-fsck-root.service > > Could you please let us know how to further breakdown the time taken by > "dev-mmcblk0p2.device" > > as we don't get anything with > > systemd-analyze critical-chain dev-mmcblk0p2.device > The time when unit became active or started is printed after the "@" > character. > The time the unit took to start is printed after the "+" character. > > dev-mmcblk0p2.device +6.984s > > Is it possible to achieve faster boot times on arm v5 and cortex a5 > these architectures similar to cortex a7 by tuning systemd? > > > Best Regards, > Dharma B. -- With Best Regards, Dharma B.
Re: [systemd-devel] systemd-journald persistent storage unkown file descriptor error
For some reason the first time systemd-journald-flush is executed during boot, it logs a warning about files with insufficient privileges. However as soon as the system is booted to where I can login I'm able to run the service manually and it runs fine, flushing everything to disk and all journals, and user level journals are accessible. /var/log/journal is on the primary partition so it seems odd there would be some sort of race condition. I didn't see a way to output which files specifically had insufficient privileges. On Fri, 2024-07-26 at 09:59 -0400, Gregory Gincley wrote: > > To whom it may concern: > > I'm receiving the below error on every systemd-journald service > startup. > > While systemd-journald starts, it refuses to log to persistent > storage > (/var/log/journal) despite this path existing. Additionally --user > shows no journal information. > > I've tried deleting/recreating /var/log/journal > > I've tried setting /etc/systemd/journald.conf 'Storage' setting to > both > 'auto' and 'peristent' with the same result. > > https://github.com/systemd/systemd/blob/eef4cd51f94d837bd0e71512c831634a2902522d/src/journal/journald-server.c#L2764 > > FWIW I'm on Arch Linux. > > Any thoughts on what is preventing my logging from flushing to disk? > > Let me know if any additional information would be helpful. > > Thanks, > Greg
Re: [systemd-devel] "systemd-path systemd-search-user-unit" does not match reality
On Fri, 26 Jul 2024 at 12:50, Vladimir Panteleev wrote: > cat > ~/.config/systemd/user.conf < [Manager] > ManagerEnvironment="XDG_DATA_DIRS=%h/.nix-profile/share" > EOF Amendment - the above may break stuff (e.g. nautilus, eog), a better value is: ManagerEnvironment="XDG_DATA_DIRS=%h/.nix-profile/share:/usr/local/share:/usr/share" It looks like these variables are also inherited by some child processes.
Re: [systemd-devel] "systemd-path systemd-search-user-unit" does not match reality
On Fri, 26 Jul 2024 at 15:59, Dan Nicholson wrote: > ManagerEnvironment only affects the environment variables for the > systemd user process. Thank you; affecting the configuration of the systemd user process itself is exactly what is needed. DefaultEnvironment would not have affected the unit search path. Note that ManagerEnvironment does not exactly affect the environment variables (as in, the process's environment block), as mentioned.
Re: [systemd-devel] "systemd-path systemd-search-user-unit" does not match reality
On Fri, Jul 26, 2024 at 9:59 AM Dan Nicholson wrote: > > On Fri, Jul 26, 2024 at 6:50 AM Vladimir Panteleev > wrote: > > > > This seems to work: > > > > cat > ~/.config/systemd/user.conf < > [Manager] > > ManagerEnvironment="XDG_DATA_DIRS=%h/.nix-profile/share" > > EOF > > ManagerEnvironment only affects the environment variables for the > systemd user process. To propagate the environment variable to > processes spawned by the manager, use DefaultEnvironment. See > https://www.freedesktop.org/software/systemd/man/latest/systemd-user.conf.html. Another option here is a user environment generator. See https://www.freedesktop.org/software/systemd/man/latest/systemd.environment-generator.html. It even has an example of dynamically updating XDG_DATA_DIRS. -- Dan
Re: [systemd-devel] "systemd-path systemd-search-user-unit" does not match reality
On Fri, Jul 26, 2024 at 6:50 AM Vladimir Panteleev wrote: > > This seems to work: > > cat > ~/.config/systemd/user.conf < [Manager] > ManagerEnvironment="XDG_DATA_DIRS=%h/.nix-profile/share" > EOF ManagerEnvironment only affects the environment variables for the systemd user process. To propagate the environment variable to processes spawned by the manager, use DefaultEnvironment. See https://www.freedesktop.org/software/systemd/man/latest/systemd-user.conf.html. -- Dan
[systemd-devel] systemd-journald persistent storage unkown file descriptor error
To whom it may concern: I'm receiving the below error on every systemd-journald service startup. While systemd-journald starts, it refuses to log to persistent storage (/var/log/journal) despite this path existing. Additionally --user shows no journal information. I've tried deleting/recreating /var/log/journal I've tried setting /etc/systemd/journald.conf 'Storage' setting to both 'auto' and 'peristent' with the same result. https://github.com/systemd/systemd/blob/eef4cd51f94d837bd0e71512c831634a2902522d/src/journal/journald-server.c#L2764 FWIW I'm on Arch Linux. Any thoughts on what is preventing my logging from flushing to disk? Let me know if any additional information would be helpful. Thanks, Greg
Re: [systemd-devel] "systemd-path systemd-search-user-unit" does not match reality
On Thu, 25 Jul 2024 at 11:59, Mantas Mikulėnas wrote:
> The paths for user units and other user configuration depend on your
> XDG_{CONFIG,DATA}_{DIRS,HOME} environment variables.
>
> Since systemd-search-user-unit is running as part of your interactive session
> (and under your interactive shell) whereas systemd --user itself is not, they
> will likely have different lists of environment variables, especially if you
> have Nix set up a custom XDG_* through /etc/profile or similar.
Thank you for that pointer!
There is indeed an /etc/profile script which sets XDG_DATA_DIRS.
I was confused because I expected "systemd-path" to work like
"systemctl show-environment", i.e. fetch the variables from the
daemon.
I think a note in the systemd-path man page that it uses the invoker's
environment and not the daemon's environment would be a useful
addition.
> While systemd --user has a few ways to push environment variables into the
> services it starts, those all happen after initialization; there's no good
> equivalent for providing envvars for systemd itself. You would need to `sudo
> systemctl edit user@$UID` and add some [Service] Environment= definitions
> there.
This seems to work:
cat > ~/.config/systemd/user.conf <
Re: [systemd-devel] "systemd-path systemd-search-user-unit" does not match reality
On Thu, Jul 25, 2024 at 10:42 AM Vladimir Panteleev <
g...@vladimir.panteleev.md> wrote:
> It looks like "systemd-path systemd-search-user-unit" isn't accurate
> or does not correspond to the list of paths that systemd is looking
> in.
>
The paths for user units and other user configuration depend on your
XDG_{CONFIG,DATA}_{DIRS,HOME} environment variables.
Since systemd-search-user-unit is running as part of your interactive
session (and under your interactive shell) whereas systemd --user itself *is
not*, they will likely have different lists of environment variables,
especially if you have Nix set up a custom XDG_* through /etc/profile or
similar.
While systemd --user has a few ways to push environment variables into the
services it starts, those all happen after initialization; there's no good
equivalent for providing envvars for systemd itself. You would need to
`sudo systemctl edit user@$UID` and add some [Service] Environment=
definitions there.
(In the early days I used to edit the user@.service to invoke
`ExecStart=/bin/sh -l -c "exec systemd --user"` so that it would go through
the shell's ~/.profile processing, but I'm not sure if that works these
days.)
--
Mantas Mikulėnas
[systemd-devel] "systemd-path systemd-search-user-unit" does not match reality
Hi, Context: I'm trying to use home-manager, which extends the systemd user unit search path. However, though I can see the added path in "systemd-path systemd-search-user-unit", systemd still cannot find units there: - $ systemctl --user daemon-reload $ systemd-path systemd-search-user-unit | tr : '\n' /home/vladimir/.config/systemd/user.control /run/user/1000/systemd/user.control /run/user/1000/systemd/transient /run/user/1000/systemd/generator.early /home/vladimir/.config/systemd/user /etc/xdg/systemd/user /etc/systemd/user /run/user/1000/systemd/user /run/systemd/user /run/user/1000/systemd/generator /home/vladimir/.local/share/systemd/user /usr/local/share/systemd/user /usr/share/systemd/user /home/vladimir/.nix-profile/share/systemd/user /nix/var/nix/profiles/default/share/systemd/user /usr/local/lib/systemd/user /usr/lib/systemd/user /run/user/1000/systemd/generator.late $ cat /home/vladimir/.nix-profile/share/systemd/user/xdg-desktop-portal-gtk.service [Unit] Description=Portal service (GTK/GNOME implementation) [Service] Type=dbus BusName=org.freedesktop.impl.portal.desktop.gtk ExecStart=/nix/store/d84a85gghx9mr53wj78wy7rw5dmwf4i0-xdg-desktop-portal-gtk-1.15.1/libexec/xdg-desktop-portal-gtk $ systemctl --user cat xdg-desktop-portal-gtk.service No files found for xdg-desktop-portal-gtk.service. - It looks like "systemd-path systemd-search-user-unit" isn't accurate or does not correspond to the list of paths that systemd is looking in. What's missing to make systemd be able to find units in the "systemd-search-user-unit" list? I'm using systemd 256 (256.2-1-arch) on Arch Linux. Thanks!
[systemd-devel] systemd accepts fix to stable releases
Hi All, Asking on doubtful that, whether fix will be accepted in systemd-stable (for instance, version 255.4) release branch. Please let me know. Thank you Rajmohan This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.
[systemd-devel] Systemd Boot Time Optimization
Hi Everyone, We have recently migrated from sysvinit to systemd on our platforms, including sam9, sama5, and sama7 which feature various ARM architectures such as ARMv5, Cortex-A5, and Cortex-A7. We observed different performance levels across these architectures, detailed as follows: Performance comparison between three architectures using the core-image-minimal recipe in Yocto Project with a high-speed HP 64GB XC 100MB/s SD card. *** ARMv5 - sam9 Startup finished in 2.113s (kernel) + 14.090s (userspace) = 16.203s multi-user.target reached after 14.080s in userspace Cortex-A5 - sama5 Startup finished in 2.254s (kernel) + 13.216s (userspace) = 15.470s multi-user.target reached after 13.185s in userspace Cortex A7 - sama7 Startup finished in 1.967s (kernel) + 6.302s (userspace) = 8.270s multi-user.target reached after 6.271s in userspace *** We noted that the following services take significantly longer on the ARMv5 and Cortex-A5 architectures: root@sam9x60-curiosity-sd:~# systemd-analyze blame 6.984s dev-mmcblk0p2.device 5.120s systemd-udev-trigger.service 3.063s systemd-networkd.service 1.938s systemd-journald.service 1.850s systemd-timesyncd.service 1.826s systemd-resolved.service 995ms systemd-fsck-root.service Could you please let us know how to further breakdown the time taken by "dev-mmcblk0p2.device" as we don't get anything with systemd-analyze critical-chain dev-mmcblk0p2.device The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. dev-mmcblk0p2.device +6.984s Is it possible to achieve faster boot times on arm v5 and cortex a5 these architectures similar to cortex a7 by tuning systemd? Best Regards, Dharma B.
Re: [systemd-devel] systemd --user managers after systemd upgrade
On Sa, 29.06.24 14:57, Mike Gilbert (flop...@gentoo.org) wrote: > I recently added systemd v256 to Gentoo's ebuild repo. While testing > the upgrade process from v255, I have run into an issue. > > After the upgrade, my KDE Plasma session stopped working, and I was > unable to execute a reboot from the GUI. > > Looking at the journal, I see several messages like this one: > > Jun 29 14:21:30 naomi systemd[2387904]: > /usr/lib/systemd/systemd-executor (deleted): error while loading > shared libraries: libsystemd-core-255.so: cannot open shared object > file: No such file or directory > > It appears to be executing a deleted binary > (/usr/lib/systemd/systemd-executor), likely via /proc/1/fd/..., and > then fails when loading a deleted shared library > (libsystemd-core-255.so). > > The new versions of these files do exist on the filesystem. Also, I > was able to reboot the system by switching to a text console and > pressing ctrl-alt-delete. > > Any idea what happened here? I'm not sure if this is a systemd bug, or > if I missed something in my packaging script (ebuild). See this discussion: https://github.com/systemd/systemd/pull/33279 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd --user managers after systemd upgrade
On Sat, Jun 29, 2024 at 4:22 PM Luca Boccassi wrote: > > On Sat, 29 Jun 2024 at 21:16, Mike Gilbert wrote: > > > > I recently added systemd v256 to Gentoo's ebuild repo. While testing > > the upgrade process from v255, I have run into an issue. > > > > After the upgrade, my KDE Plasma session stopped working, and I was > > unable to execute a reboot from the GUI. > > > > Looking at the journal, I see several messages like this one: > > > > Jun 29 14:21:30 naomi systemd[2387904]: > > /usr/lib/systemd/systemd-executor (deleted): error while loading > > shared libraries: libsystemd-core-255.so: cannot open shared object > > file: No such file or directory > > > > It appears to be executing a deleted binary > > (/usr/lib/systemd/systemd-executor), likely via /proc/1/fd/..., and > > then fails when loading a deleted shared library > > (libsystemd-core-255.so). > > > > The new versions of these files do exist on the filesystem. Also, I > > was able to reboot the system by switching to a text console and > > pressing ctrl-alt-delete. > > > > Any idea what happened here? I'm not sure if this is a systemd bug, or > > if I missed something in my packaging script (ebuild). > > This is a known issue, your packaging scripts _must_ reexec both the > system instance and all user instances. For the latter you can just > do: > > systemctl kill --kill-whom='main' --signal='SIGRTMIN+25' 'user@*.service' Thanks to you and Mantas, this was exactly the sort of workaround I was looking for.
Re: [systemd-devel] systemd --user managers after systemd upgrade
On Sat, 29 Jun 2024 at 21:16, Mike Gilbert wrote: > > I recently added systemd v256 to Gentoo's ebuild repo. While testing > the upgrade process from v255, I have run into an issue. > > After the upgrade, my KDE Plasma session stopped working, and I was > unable to execute a reboot from the GUI. > > Looking at the journal, I see several messages like this one: > > Jun 29 14:21:30 naomi systemd[2387904]: > /usr/lib/systemd/systemd-executor (deleted): error while loading > shared libraries: libsystemd-core-255.so: cannot open shared object > file: No such file or directory > > It appears to be executing a deleted binary > (/usr/lib/systemd/systemd-executor), likely via /proc/1/fd/..., and > then fails when loading a deleted shared library > (libsystemd-core-255.so). > > The new versions of these files do exist on the filesystem. Also, I > was able to reboot the system by switching to a text console and > pressing ctrl-alt-delete. > > Any idea what happened here? I'm not sure if this is a systemd bug, or > if I missed something in my packaging script (ebuild). This is a known issue, your packaging scripts _must_ reexec both the system instance and all user instances. For the latter you can just do: systemctl kill --kill-whom='main' --signal='SIGRTMIN+25' 'user@*.service'
Re: [systemd-devel] systemd --user managers after systemd upgrade
v255 added a new systemd-executor binary – instead of direct fork/setup/exec, now it's fork/exec(executor)/setup/exec(service), to avoid doing too much stuff after fork. But the binary is executed off an open fd, so even though you've upgraded it on disk, the manager is still holding onto its old copy. I guess the latter ended up achieving the opposite of what it intended. I think asking systemd to reexec itself after the upgrade is how you're supposed to handle it – i.e. first "systemctl daemon-reexec" the system manager (or "telinit u" if you like), then "systemctl --user daemon-reexec", or a mass "systemctl kill -s SIGRTMIN-25 user@\*.service". (On Arch it's one of the very few daemon restarts that are automatically done via post-upgrade hooks.) On Sat, Jun 29, 2024, 22:05 Mike Gilbert wrote: > I recently added systemd v256 to Gentoo's ebuild repo. While testing > the upgrade process from v255, I have run into an issue. > > After the upgrade, my KDE Plasma session stopped working, and I was > unable to execute a reboot from the GUI. > > Looking at the journal, I see several messages like this one: > > Jun 29 14:21:30 naomi systemd[2387904]: > /usr/lib/systemd/systemd-executor (deleted): error while loading > shared libraries: libsystemd-core-255.so: cannot open shared object > file: No such file or directory > > It appears to be executing a deleted binary > (/usr/lib/systemd/systemd-executor), likely via /proc/1/fd/..., and > then fails when loading a deleted shared library > (libsystemd-core-255.so). > > The new versions of these files do exist on the filesystem. Also, I > was able to reboot the system by switching to a text console and > pressing ctrl-alt-delete. > > Any idea what happened here? I'm not sure if this is a systemd bug, or > if I missed something in my packaging script (ebuild). >
[systemd-devel] systemd --user managers after systemd upgrade
I recently added systemd v256 to Gentoo's ebuild repo. While testing the upgrade process from v255, I have run into an issue. After the upgrade, my KDE Plasma session stopped working, and I was unable to execute a reboot from the GUI. Looking at the journal, I see several messages like this one: Jun 29 14:21:30 naomi systemd[2387904]: /usr/lib/systemd/systemd-executor (deleted): error while loading shared libraries: libsystemd-core-255.so: cannot open shared object file: No such file or directory It appears to be executing a deleted binary (/usr/lib/systemd/systemd-executor), likely via /proc/1/fd/..., and then fails when loading a deleted shared library (libsystemd-core-255.so). The new versions of these files do exist on the filesystem. Also, I was able to reboot the system by switching to a text console and pressing ctrl-alt-delete. Any idea what happened here? I'm not sure if this is a systemd bug, or if I missed something in my packaging script (ebuild).
[systemd-devel] systemd-repart failure
Hi, I've got a systemd repart config for rootfs with TPM encryption: [Partition] Type=root Weight=100 Format=ext4 Encrypt=tpm2 FactoryReset=yes MakeDirectories=/boot /usr /home /home/root # copying etc from build time /usr image CopyFiles=/usr/etc:/etc /usr partition is a dm-verity one. But for some reason on AVA Developer Platform this is not working. The systemd has nvme storage for ESP and dm-verity paritions and plenty of space for the new rootfs, but it also has a separate sda disk which we use as rescue system with Debian on it. Non-verbose boot log https://ledge.validation.linaro.org/scheduler/job/89753 shows the partitions after flashing: sh-5.2# blkid Waiting for 'sh-(.*)#', 'Press Enter for maintenance' blkid /dev/nvme0n1p3: UUID="c11f0c5f-bb2e-4dbc-906d-6a6089634e82" TYPE="DM_verity_hash" PARTLABEL="verityhash" PARTUUID="dc8ec8c9-25fc-0390-25b4-93a55f09a971" /dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="7819-74F8" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="00112233-1234---000123456789" /dev/nvme0n1p2: UUID="729df0a0-beb0-4981-9d0f-c707ced22ba2" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="verityroot" PARTUUID="161608c4-eb17-2afb-f07c-1c2f0d2d07d1" /dev/mapper/usr: UUID="729df0a0-beb0-4981-9d0f-c707ced22ba2" BLOCK_SIZE="4096" TYPE="ext4" /dev/sda2: UUID="b60723a9-a342-401b-b0a4-194e661ccd0d" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="441849f4-4f6a-420d-9d85-95048f5a2fcf" /dev/sda1: SEC_TYPE="msdos" UUID="6AEA-E17B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="a3462a88-510c-4a58-9796-e2c7f04a83a6" and then systemd-repart is getting started but finishes without providing /dev/gpt-auto-root: Starting [0;1;39mRepartition Root Disk[0m... [[0;32m OK [0m] Reached target [0;1;39mSystem Initialization[0m. [[0;32m OK [0m] Reached target [0;1;39mTimer Units[0m. [[0;32m OK [0m] Listening on [0;1;39mD-Bus System Message Bus Socket[0m. [[0;32m OK [0m] Reached target [0;1;39mSocket Units[0m. [[0;32m OK [0m] Reached target [0;1;39mBasic System[0m. [[0;32m OK [0m] Finished [0;1;39mRepartition Root Disk[0m. Starting [0;1;39mD-Bus System Message Bus[0m... [[0;32m OK [0m] Started [0;1;39mD-Bus System Message Bus[0m. [ 11.736184] critical medium error, dev sda, sector 31266568 op 0x0:(READ) flags 0x80700 phys_seg 10 prio class 2 [ 11.781616] critical medium error, dev sda, sector 31266680 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 11.791360] Buffer I/O error on dev sda, logical block 3908335, async page read [[0m[0;31m* [0m] A start job is running for /dev/gpt-auto-root (5s / 1min 30s) M [K[[0;1;31m*[0m[0;31m*[0m] A start job is running for /dev/gpt-auto-root (5s / 1min 30s) M [K[[0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for /dev/gpt-auto-root (6s / 1min 30s) M [K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for /dev/gpt-auto-root (6s / 1min 30s) M [K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for /dev/gpt-auto-root (7s / 1min 30s) M [K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for /dev/gpt-auto-root (7s / 1min 30s) M [K[[0;31m*[0;1;31m*[0m] A start job is running for /dev/gpt-auto-root (8s / 1min 30s) M [K[ [0;31m*[0m] A start job is running for /dev/gpt-auto-root (9s / 1min 30s) M [K[[0;31m*[0;1;31m*[0m] A start job is running for /dev/gpt-auto-root (9s / 1min 30s) M [K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for /dev/gpt-auto-root (10s / 1min 30s) What could be breaking systemd-repart on this box? The two ESP partitions possibly, or the errors from sda? I fired a systemd debug output run in https://ledge.validation.linaro.org/scheduler/job/89755 and this shows a different looking error from systemd-repart: [0;38;5;245mChild 602 (systemd-repart) died (code=exited, status=1/FAILURE)[0m"} [0;38;5;245msystemd-repart.service: Child 602 belongs to systemd-repart.service.[0m"} [0;1;39msystemd-repart.service: Main process exited, code=exited, status=1/FAILURE[0m"} [ 105.387844] systemd-repart[602]: Failed to find TPM2 pcrlock policy file 'pcrlock.json': No such file or directory"} [ 105.387915] systemd-repart[602]: Reading EFI variable /sys/firmware/efi/efivars/FactoryReset-8cf2644b-4b0b-428f-9387-6d876050dc67."} [ 105.387970] systemd-repart[602]: open(\"/sys/firmware/efi/efivars/FactoryReset-8cf2644b-4b0b-428f-9387-6d876050dc67\") failed: No such file or directory"} [0;1;38;5;185msystemd-repart.service: Failed with result 'exit-code'.[0m"} [ 105.388047] systemd-repart[602]: Failed to determine backing device of /: No such file or directory"} [0;38;5;245msystemd-repart.service: Service will not restart (restart setting)[0m"} [0;38;5;245msystemd-repart.service: Changed start -> failed[0m"} >From what I can read the logs, the TPM2 devices is there, drivers are loaded >and working. But why is systemd-repart failing then? The same kernel, initramfs and rootfs combo
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 17.06.2024 18:20, Michal Koutný wrote: Hello. On Sat, Jun 15, 2024 at 04:49:33PM GMT, Andrei Borzenkov wrote: ... Which does not really solve the problem. So, once again: - nftables allow filtering based on cgroupv2 path - cgroupv2 path is resolved at the time rule is processed. It is impossible to configure rule for a future cgroup Can nftables accept non-leaf cgroup? (Of a .slice unit) To my best knowledge it does not care. cgroup is cgroup. So, no mantra about one ring to rule them all is going to help here as long as none of the following is possible - systemd (which puts processes in cgroups) will also add corresponding nftables rule that refers to this new transient cgroup I think systemd comes with its own filtering based on BPF (see systemd.resource-control(5), "Network Accounting and Control") or see NFTSet= in the same section, does that solve the issue? Yes, NFTSet effectively solves this for the system services (instead of matching for a literal cgroup you use map and systemd dynamically adds elements to this map). But it requires root and is not available for user services. - or- - systemd allows pre-creation of cgroups and *atomic* placement of processes in them systemd places process either via clone-migrate-exec or clone(CLONE_INTO_CGROUP) idioms, so the newly exec'd process starts in the desired cgroup. This is utilized with the .slice unit above (but it must be "pinned" into existence with some sibling unit). This may be a workaround, at least for some use cases. I am not sure if "slice" really fits here. Slice is about partitioning resources, there is no obvious reason why the same slice cannot contain programs allowed to access network and programs blocked from network. One more consideration (comparing with solutions like cgrulesengd) is who enforces restrictions. cgrulesengd configuration is managed by the administrator and user has no control over it, while here user is free to place any program in any slice under own hierarchy and cannot place program in any slice outside of it. (Migrating already running processes with their runtime state is nothing I'd recommend.) I did not mean it.
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
Hello. On Sat, Jun 15, 2024 at 04:49:33PM GMT, Andrei Borzenkov wrote: > ... > Which does not really solve the problem. So, once again: > > - nftables allow filtering based on cgroupv2 path > - cgroupv2 path is resolved at the time rule is processed. It is impossible > to configure rule for a future cgroup Can nftables accept non-leaf cgroup? (Of a .slice unit) > So, no mantra about one ring to rule them all is going to help here as long > as none of the following is possible > > - systemd (which puts processes in cgroups) will also add corresponding > nftables rule that refers to this new transient cgroup I think systemd comes with its own filtering based on BPF (see systemd.resource-control(5), "Network Accounting and Control") or see NFTSet= in the same section, does that solve the issue? > - or- > > - systemd allows pre-creation of cgroups and *atomic* placement of processes > in them systemd places process either via clone-migrate-exec or clone(CLONE_INTO_CGROUP) idioms, so the newly exec'd process starts in the desired cgroup. This is utilized with the .slice unit above (but it must be "pinned" into existence with some sibling unit). (Migrating already running processes with their runtime state is nothing I'd recommend.) Michal
Re: [systemd-devel] systemd 256 released
https://linuxunplugged.com/567
Den tis 11 juni 2024 kl 23:45 skrev systemd tag bot
:
>
> 🎆 A new, official systemd release has just 🎉 been 🎊 tagged 🍾. Please download
> the tarball here:
>
> https://github.com/systemd/systemd/archive/v256.tar.gz
>
> 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.
>
> * Support for System V service scripts is 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.
>
> * 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.
>
> * IPForward= setting in .network file is deprecated and replaced with
> IPv4Forwarding= and IPv6Forwarding= settings. These new settings are
> supported both in .network file and networkd.conf. If specified in a
> .network file, they control corresponding per-link settings. If
> specified in networkd.conf, they control corresponding global
> settings. Note, previously IPv6SendRA= and IPMasquerade= implied
> IPForward=, but now they imply the new per-link settings. One of the
> simplest ways to migrate configurations, that worked as a router
> with
> the previous version, is enabling both IPv4Forwarding= and
> IPv6Forwarding= in networkd.conf. See systemd.network(5) and
> networkd.conf(5) for more details.
>
> * 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_SESSIONS=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 ex
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 15/06/2024 4.37 pm, Andrei Borzenkov wrote: Not really. nftables checks the *socket* cgroup, not the *process* cgroup. The socket may have been created while process was in the old cgroup. I do not know whether kernel attempts to also move all process sockets to the new cgroup. I suspect not, but that is most certainly the question to the kernel folks. Hmm, that would make sense. I think I have to look for a place to ask this question, because if it was the case and they changed the behavior, it probably would fix the issue. See my other response about atomically placing a process to some pre-existing cgroup from the very beginning. Yes, I saw it, but to be honest, at the moment I have no idea what to do with it :)
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 15.06.2024 14:02, Mikhail Morfikov wrote: Otherwise there is such project as https://github.com/mk-fg/systemd-cgroup-nftables-policy-manager which dynamically adds nftables rules to match systemd cgroups (well, in principle it can match anything). It could be combined with "systemd-run --scope" or similar to place commands in specific scopes that will be matched by netfilter. I don't think the project is what I need. You need to classify packets according to which cgroup the sender is in. This project does exactly that. Instead of pre-creating rules and adjusting cgroups it adjusts rules as cgroups come and go. Of course, it also suffers from the race condition - there is window between creating cgroup and adding rules. See also https://lore.kernel.org/all/35c20ae1-fc79-9488-8a42-a405424d1...@gmail.com/t/
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 15.06.2024 16:58, Mikhail Morfikov wrote: On 15/06/2024 2.27 pm, Andrei Borzenkov wrote: On 15.06.2024 14:02, Mikhail Morfikov wrote: But there's no curl pids in /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.procs . To be more specific, there's no pids at all in this cgroup.procs file. The curl pids are under # cat /sys/fs/cgroup/morfikownia/user/curl/pids.current 1 # cat /sys/fs/cgroup/morfikownia/user/curl/cgroup.procs 44907 And this cgroup path (morfikownia/user/curl/) is permitted in nftables, and yet packets sometimes are visible like they had user.slice/user-1000.slice/user@1000.service/ path set. Why? Because curl starts in this hierarchy and attempts network connection before your daemon moves curl into different cgroup. It is just as good stab in the dark as any other. No, it's not like this. When curl attempts to access the internet, it sends SYN packet, which is dropped in nftables because of the wrong cgroup path. If what you say was true, then the next (or any other) SYN packet would be accepted, since the pid is in the right cgroup path now, which is permitted in nftabels. But when I watch the nftables logs, I see something like this: Jun 15 15:30:57 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52657 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96453BC00103030E) UID=1000 GID=1000 Jun 15 15:30:59 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52658 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96453FCB0103030E) UID=1000 GID=1000 Jun 15 15:31:00 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52659 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964543CB0103030E) UID=1000 GID=1000 Jun 15 15:31:01 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52660 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964547CB0103030E) UID=1000 GID=1000 Jun 15 15:31:02 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52661 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96454BCB0103030E) UID=1000 GID=1000 Jun 15 15:31:03 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52662 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96454FCB0103030E) UID=1000 GID=1000 Jun 15 15:31:05 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52663 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964557CB0103030E) UID=1000 GID=1000 Jun 15 15:31:09 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52664 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A9645678B0103030E) UID=1000 GID=1000 Jun 15 15:31:17 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52665 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964588CB0103030E) UID=1000 GID=1000 Pay attention to the timestamp. All the packets comes from the same curl connection. So we have beginning at 15:30:57 and end at 15:31:17 (20s window), and then was ctrl+c, because it's not going to work. So the pid is in the right cgroup path for sure before sending the SYN packets. If the very first SYN packet was dropped, that would make sense, I mean the theory with the app accessing net before cgrulesengd moves the pid. But we have 20s, the pid is in the right cgroup and sometimes it works, and sometimes it doesn't, I mean curl is able to access the net or not. And that's weird. Not really. nftables checks the *socket* cgroup, not the *process* cgroup. The socket may have been created while process was in the old cgroup. I do not know whether kernel attempts to also move all process sockets to the new cgroup. I suspect not, but that is most certainly the question to the kernel folks. See my other response about atomically placing a process to some pre-existing cgroup from the very beginning. It looks like the cgroup path isn't updated for some reason -- that's my blind guess, because the pid is in the right place, the nftables rule works, and ye
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 15/06/2024 2.27 pm, Andrei Borzenkov wrote: On 15.06.2024 14:02, Mikhail Morfikov wrote: But there's no curl pids in /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.procs . To be more specific, there's no pids at all in this cgroup.procs file. The curl pids are under # cat /sys/fs/cgroup/morfikownia/user/curl/pids.current 1 # cat /sys/fs/cgroup/morfikownia/user/curl/cgroup.procs 44907 And this cgroup path (morfikownia/user/curl/) is permitted in nftables, and yet packets sometimes are visible like they had user.slice/user-1000.slice/user@1000.service/ path set. Why? Because curl starts in this hierarchy and attempts network connection before your daemon moves curl into different cgroup. It is just as good stab in the dark as any other. No, it's not like this. When curl attempts to access the internet, it sends SYN packet, which is dropped in nftables because of the wrong cgroup path. If what you say was true, then the next (or any other) SYN packet would be accepted, since the pid is in the right cgroup path now, which is permitted in nftabels. But when I watch the nftables logs, I see something like this: Jun 15 15:30:57 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52657 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96453BC00103030E) UID=1000 GID=1000 Jun 15 15:30:59 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52658 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96453FCB0103030E) UID=1000 GID=1000 Jun 15 15:31:00 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52659 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964543CB0103030E) UID=1000 GID=1000 Jun 15 15:31:01 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52660 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964547CB0103030E) UID=1000 GID=1000 Jun 15 15:31:02 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52661 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96454BCB0103030E) UID=1000 GID=1000 Jun 15 15:31:03 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52662 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A96454FCB0103030E) UID=1000 GID=1000 Jun 15 15:31:05 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52663 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964557CB0103030E) UID=1000 GID=1000 Jun 15 15:31:09 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52664 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A9645678B0103030E) UID=1000 GID=1000 Jun 15 15:31:17 morfikownia kernel: * cgroup * IN= OUT=bond0 SRC=192.168.1.150 DST=212.77.98.9 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52665 DF PROTO=TCP SPT=41760 DPT=80 SEQ=3391855235 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40402080A964588CB0103030E) UID=1000 GID=1000 Pay attention to the timestamp. All the packets comes from the same curl connection. So we have beginning at 15:30:57 and end at 15:31:17 (20s window), and then was ctrl+c, because it's not going to work. So the pid is in the right cgroup path for sure before sending the SYN packets. If the very first SYN packet was dropped, that would make sense, I mean the theory with the app accessing net before cgrulesengd moves the pid. But we have 20s, the pid is in the right cgroup and sometimes it works, and sometimes it doesn't, I mean curl is able to access the net or not. And that's weird. It looks like the cgroup path isn't updated for some reason -- that's my blind guess, because the pid is in the right place, the nftables rule works, and yet the cgroup path "internally somewhere" is user.slice/user-1000.slice/user@1000.service/ instead of the right one, where the pid was moved. I bet there's a bug somewhere.
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 14.06.2024 11:20, Lennart Poettering wrote: On Fr, 14.06.24 10:06, Mikhail Morfikov (mmorfi...@gmail.com) wrote: -- Lennart Poettering, Berlin I don't need any warranty, I need a way to make this work. Yeah, but this is the wrong forum to ask for help then. What you are doing is strictly against how systemd and cgroup2 is designed. I mean, do what you want, but this is not supported, you are on your own. I'm not sure whether I understand the "single-writer rule", so correct me if I'm wrong. I don't want to write pids to systemd services using cgrulesengd. I just want to create my own cgroup tree, for instance /sys/fs/cgroup/morfikownia/ and I Yeah, that's not how this works. On systemd systems the top of the cgroup tree is managed by systemd. if you want to manage your own cgroups, then ask for a delegated subtree, and do your stuff there, but don't interfere with the top of tree, you'll step on systemd's feet then, and systemd will run over your feet all the time. want to place there all the processes managed by cgrulesengd (via the /etc/cgrules.conf file). So systemd won't be touching anything inside /sys/fs/cgroup/morfikownia/ and cgrulesengd won't be touching anything in the rest of the cgroup tree -- is this "single-writer rule" ? Yeah, sorry, that's not how this works. And you must delegate a subtree to other managers if a different manager shall also manage cgroups. How can this be done? There are so many docs around about this, you read them: https://systemd.io/CGROUP_DELEGATION Which does not really solve the problem. So, once again: - nftables allow filtering based on cgroupv2 path - cgroupv2 path is resolved at the time rule is processed. It is impossible to configure rule for a future cgroup So, no mantra about one ring to rule them all is going to help here as long as none of the following is possible - systemd (which puts processes in cgroups) will also add corresponding nftables rule that refers to this new transient cgroup - or- - systemd allows pre-creation of cgroups and *atomic* placement of processes in them The former is https://github.com/systemd/systemd/issues/7327 which is rejected The latter is not possible bor@bor-Latitude-E5450:~/src/systemd$ systemd-run --user --scope --unit network.scope cat /proc/self/cgroup Failed to start transient scope unit: Unit network.scope already exists. bor@bor-Latitude-E5450:~/src/systemd$ The only way currently to move processes in some scope is not atomic and has the same race condition as using e.g. cgrulesengd. Just look at https://unix.stackexchange.com/questions/594798/how-do-i-run-a-command-in-a-different-already-existing-systemd-scope-or-sessio $ systemd-run --user --scope --unit="app-sleep" --property=Delegate=yes sleep & $ disown $ sleep & $ pid=$(jobs -p) $ busctl --user call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager AttachProcessesToUnit ssau "app-sleep.scope" / 1 "$pid" Are there ways to do it atomically?
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 15.06.2024 14:02, Mikhail Morfikov wrote: But there's no curl pids in /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.procs . To be more specific, there's no pids at all in this cgroup.procs file. The curl pids are under # cat /sys/fs/cgroup/morfikownia/user/curl/pids.current 1 # cat /sys/fs/cgroup/morfikownia/user/curl/cgroup.procs 44907 And this cgroup path (morfikownia/user/curl/) is permitted in nftables, and yet packets sometimes are visible like they had user.slice/user-1000.slice/user@1000.service/ path set. Why? Because curl starts in this hierarchy and attempts network connection before your daemon moves curl into different cgroup. It is just as good stab in the dark as any other.
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 15/06/2024 8.15 am, Andrei Borzenkov wrote: On 14.06.2024 18:49, Mikhail Morfikov wrote: On 14/06/2024 5.26 pm, Demi Marie Obenour wrote: On Fri, Jun 14, 2024 at 10:06:34AM +0200, Mikhail Morfikov wrote: On 13/06/2024 10.27 pm, Lennart Poettering wrote: On Do, 13.06.24 21:38, Mikhail Morfikov (mmorfi...@gmail.com) wrote: I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and nftables) work together, but I think I'm missing something. Is "cgrulesengd" interfering with the cgroup tree? Sorry, but that's simply not supported. cgroupv2 has a single-writer rule, i.e. every part of the tree has only a single writer, a single manager. And you must delegate a subtree to other managers if a different manager shall also manage cgroups. Hence, if you have something that just takes systemd managed processes and moves them elsewhere, it's simply not supported. Sorry, you voided your warranty. Lennart -- Lennart Poettering, Berlin I don't need any warranty, I need a way to make this work. I don't know anything about cgrulesengd, but from your post it seems that it relies on scanning all processes and moving them to cgroups based on information about them. This isn't compatible with systemd. There are a few options that will work: 1. Change cgrulesengd to use systemd's D-Bus API to manage cgroups. 2. Run everything in a container that doesn't use systemd. 3. Stop using cgrulesengd, and instead use systemd units to define cgroups. Then use other approaches (such as wrapper scripts) to ensure that programs are launched in the correct systemd units. There's no way I'm going to wrap every command in systemd's service/unit file... The question isn't really whether cgrulesengd + systemd is supported or not, but why the terminal apps have issues. GUI apps work well and the network packets of all the GUI apps can be matched in nftables based on the cgroup path. So the setup works well except for the terminal apps. It is still unclear why you are asking this on systemd list. I'm asking because with cgroupsv1 everything was working just fine, i.e. net_cls class + nftables + cgrulesengd + systemd. It was working well for many years, but recently systemd started to bully my system with this 30s boot delay when it detects that cgroupsv1 is used (I was using it only for this net_cls). So where else should I ask the question why does systemd+cgroupsv2+cgrulesengd work only partially? I had pretty decent firewall config that was filtering INPUT/OUTPUT of all individual user (and system too) apps, but now some part of it is broken, and I try to figure out why and how to fix it. From your description it sounds like a race condition between cgrulesengd and netfilter. GUI apps generally are "heavier" and take more time to startup which may explain it. The best place to ask would be cgrulesengd. If you have any evidence that systemd somehow interferes here, you did not present them. The evidence could be the cgroup path. For instance, the curl processes should be added via cgrulesengd to morfikownia/user/curl/ , and they are added each single time I type curl in a terminal, or when curl is called from some script. But when I checked why the network packets are dropped, I found out that the following rule can catch them: socket cgroupv2 level 1 "user.slice/" When I dug deeper: socket cgroupv2 level 3 "user.slice/user-1000.slice/user@1000.service/" But there's no curl pids in /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.procs . To be more specific, there's no pids at all in this cgroup.procs file. The curl pids are under # cat /sys/fs/cgroup/morfikownia/user/curl/pids.current 1 # cat /sys/fs/cgroup/morfikownia/user/curl/cgroup.procs 44907 And this cgroup path (morfikownia/user/curl/) is permitted in nftables, and yet packets sometimes are visible like they had user.slice/user-1000.slice/user@1000.service/ path set. Why? Would GUI apps vs. terminal apps explain this? Maybe there's some problems with nftables (or nftables+systemd), I don't know, maybe I could ask at nftables ML about this case (I probably will anyway). Otherwise there is such project as https://github.com/mk-fg/systemd-cgroup-nftables-policy-manager which dynamically adds nftables rules to match systemd cgroups (well, in principle it can match anything). It could be combined with "systemd-run --scope" or similar to place commands in specific scopes that will be matched by netfilter. I don't think the project is what I need.
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 14.06.2024 18:49, Mikhail Morfikov wrote: On 14/06/2024 5.26 pm, Demi Marie Obenour wrote: On Fri, Jun 14, 2024 at 10:06:34AM +0200, Mikhail Morfikov wrote: On 13/06/2024 10.27 pm, Lennart Poettering wrote: On Do, 13.06.24 21:38, Mikhail Morfikov (mmorfi...@gmail.com) wrote: I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and nftables) work together, but I think I'm missing something. Is "cgrulesengd" interfering with the cgroup tree? Sorry, but that's simply not supported. cgroupv2 has a single-writer rule, i.e. every part of the tree has only a single writer, a single manager. And you must delegate a subtree to other managers if a different manager shall also manage cgroups. Hence, if you have something that just takes systemd managed processes and moves them elsewhere, it's simply not supported. Sorry, you voided your warranty. Lennart -- Lennart Poettering, Berlin I don't need any warranty, I need a way to make this work. I don't know anything about cgrulesengd, but from your post it seems that it relies on scanning all processes and moving them to cgroups based on information about them. This isn't compatible with systemd. There are a few options that will work: 1. Change cgrulesengd to use systemd's D-Bus API to manage cgroups. 2. Run everything in a container that doesn't use systemd. 3. Stop using cgrulesengd, and instead use systemd units to define cgroups. Then use other approaches (such as wrapper scripts) to ensure that programs are launched in the correct systemd units. There's no way I'm going to wrap every command in systemd's service/unit file... The question isn't really whether cgrulesengd + systemd is supported or not, but why the terminal apps have issues. GUI apps work well and the network packets of all the GUI apps can be matched in nftables based on the cgroup path. So the setup works well except for the terminal apps. It is still unclear why you are asking this on systemd list. From your description it sounds like a race condition between cgrulesengd and netfilter. GUI apps generally are "heavier" and take more time to startup which may explain it. The best place to ask would be cgrulesengd. If you have any evidence that systemd somehow interferes here, you did not present them. Otherwise there is such project as https://github.com/mk-fg/systemd-cgroup-nftables-policy-manager which dynamically adds nftables rules to match systemd cgroups (well, in principle it can match anything). It could be combined with "systemd-run --scope" or similar to place commands in specific scopes that will be matched by netfilter.
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 14/06/2024 5.26 pm, Demi Marie Obenour wrote: On Fri, Jun 14, 2024 at 10:06:34AM +0200, Mikhail Morfikov wrote: On 13/06/2024 10.27 pm, Lennart Poettering wrote: On Do, 13.06.24 21:38, Mikhail Morfikov (mmorfi...@gmail.com) wrote: I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and nftables) work together, but I think I'm missing something. Is "cgrulesengd" interfering with the cgroup tree? Sorry, but that's simply not supported. cgroupv2 has a single-writer rule, i.e. every part of the tree has only a single writer, a single manager. And you must delegate a subtree to other managers if a different manager shall also manage cgroups. Hence, if you have something that just takes systemd managed processes and moves them elsewhere, it's simply not supported. Sorry, you voided your warranty. Lennart -- Lennart Poettering, Berlin I don't need any warranty, I need a way to make this work. I don't know anything about cgrulesengd, but from your post it seems that it relies on scanning all processes and moving them to cgroups based on information about them. This isn't compatible with systemd. There are a few options that will work: 1. Change cgrulesengd to use systemd's D-Bus API to manage cgroups. 2. Run everything in a container that doesn't use systemd. 3. Stop using cgrulesengd, and instead use systemd units to define cgroups. Then use other approaches (such as wrapper scripts) to ensure that programs are launched in the correct systemd units. There's no way I'm going to wrap every command in systemd's service/unit file... The question isn't really whether cgrulesengd + systemd is supported or not, but why the terminal apps have issues. GUI apps work well and the network packets of all the GUI apps can be matched in nftables based on the cgroup path. So the setup works well except for the terminal apps.
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On Fri, Jun 14, 2024 at 10:06:34AM +0200, Mikhail Morfikov wrote: > On 13/06/2024 10.27 pm, Lennart Poettering wrote: > > On Do, 13.06.24 21:38, Mikhail Morfikov (mmorfi...@gmail.com) wrote: > > > > > I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and > > > nftables) > > > work together, but I think I'm missing something. > > > > Is "cgrulesengd" interfering with the cgroup tree? > > > > Sorry, but that's simply not supported. cgroupv2 has a single-writer > > rule, i.e. every part of the tree has only a single writer, a single > > manager. And you must delegate a subtree to other managers if a > > different manager shall also manage cgroups. > > > > Hence, if you have something that just takes systemd managed processes > > and moves them elsewhere, it's simply not supported. Sorry, you voided > > your warranty. > > > > Lennart > > > > -- > > Lennart Poettering, Berlin > > I don't need any warranty, I need a way to make this work. I don't know anything about cgrulesengd, but from your post it seems that it relies on scanning all processes and moving them to cgroups based on information about them. This isn't compatible with systemd. There are a few options that will work: 1. Change cgrulesengd to use systemd's D-Bus API to manage cgroups. 2. Run everything in a container that doesn't use systemd. 3. Stop using cgrulesengd, and instead use systemd units to define cgroups. Then use other approaches (such as wrapper scripts) to ensure that programs are launched in the correct systemd units. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On Fr, 14.06.24 10:06, Mikhail Morfikov (mmorfi...@gmail.com) wrote: > > -- > > Lennart Poettering, Berlin > > I don't need any warranty, I need a way to make this work. Yeah, but this is the wrong forum to ask for help then. What you are doing is strictly against how systemd and cgroup2 is designed. I mean, do what you want, but this is not supported, you are on your own. > I'm not sure whether I understand the "single-writer rule", so correct me if > I'm > wrong. I don't want to write pids to systemd services using cgrulesengd. I > just > want to create my own cgroup tree, for instance > /sys/fs/cgroup/morfikownia/ and I Yeah, that's not how this works. On systemd systems the top of the cgroup tree is managed by systemd. if you want to manage your own cgroups, then ask for a delegated subtree, and do your stuff there, but don't interfere with the top of tree, you'll step on systemd's feet then, and systemd will run over your feet all the time. > want to place there all the processes managed by cgrulesengd (via the > /etc/cgrules.conf file). So systemd won't be touching anything inside > /sys/fs/cgroup/morfikownia/ and cgrulesengd won't be touching anything in the > rest of the cgroup tree -- is this "single-writer rule" ? Yeah, sorry, that's not how this works. > > And you must delegate a subtree to other managers if a > > different manager shall also manage cgroups. > > How can this be done? There are so many docs around about this, you read them: https://systemd.io/CGROUP_DELEGATION Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On 13/06/2024 10.27 pm, Lennart Poettering wrote: On Do, 13.06.24 21:38, Mikhail Morfikov (mmorfi...@gmail.com) wrote: I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and nftables) work together, but I think I'm missing something. Is "cgrulesengd" interfering with the cgroup tree? Sorry, but that's simply not supported. cgroupv2 has a single-writer rule, i.e. every part of the tree has only a single writer, a single manager. And you must delegate a subtree to other managers if a different manager shall also manage cgroups. Hence, if you have something that just takes systemd managed processes and moves them elsewhere, it's simply not supported. Sorry, you voided your warranty. Lennart -- Lennart Poettering, Berlin I don't need any warranty, I need a way to make this work. I'm not sure whether I understand the "single-writer rule", so correct me if I'm wrong. I don't want to write pids to systemd services using cgrulesengd. I just want to create my own cgroup tree, for instance /sys/fs/cgroup/morfikownia/ and I want to place there all the processes managed by cgrulesengd (via the /etc/cgrules.conf file). So systemd won't be touching anything inside /sys/fs/cgroup/morfikownia/ and cgrulesengd won't be touching anything in the rest of the cgroup tree -- is this "single-writer rule" ? And you must delegate a subtree to other managers if a different manager shall also manage cgroups. How can this be done?
Re: [systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
On Do, 13.06.24 21:38, Mikhail Morfikov (mmorfi...@gmail.com) wrote: > I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and nftables) > work together, but I think I'm missing something. Is "cgrulesengd" interfering with the cgroup tree? Sorry, but that's simply not supported. cgroupv2 has a single-writer rule, i.e. every part of the tree has only a single writer, a single manager. And you must delegate a subtree to other managers if a different manager shall also manage cgroups. Hence, if you have something that just takes systemd managed processes and moves them elsewhere, it's simply not supported. Sorry, you voided your warranty. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Systemd, cgrupsv2, cgrulesengd, and nftables
I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and nftables) work together, but I think I'm missing something. Basically what I want to achieve is the filtering of OUTPUT packets in nftables in the case of all user apps. System services work well either with systemd+cgrupsv2+nftables or cgrulesengd+cgrupsv2+nftables. User GUI apps also work well with cgrulesengd+cgrupsv2+nftables. There's some issue with terminal apps, like ssh, ping, curl, mount, etc -- they sometimes work and sometimes don't. What do I mean by "work"? When I *ssh ...* , the request sometimes is blocked in nftables. Here's the example: # egrep -i ssh /etc/cgrules.conf *:sshfs cpu,memory,pids morfikownia/user/ssh/ *:sshcpu,memory,pids morfikownia/user/ssh/ So when I type *ssh ...* in a terminal, the pid of this command should be visible under /sys/fs/cgroup/morfikownia/user/ssh/ , and I can see it's there: # ps aux | grep ssh morfik 21746 0.0 0.0 18088 8064 pts/11 S+ 21:16 0:00 ssh root@192.168.1.1 # for i in $(cat /sys/fs/cgroup/morfikownia/user/ssh/cgroup.procs); do ls -ald /proc/$i/exe; done lrwxrwxrwx 1 morfik morfik 0 2024-06-13 21:16:42 /proc/21746/exe -> /usr/bin/ssh* When I can connect to the remote SSH server, the packets pass through nftables via the following rule: # nft list table inet filter | grep ssh socket cgroupv2 level 3 "morfikownia/user/ssh" meta l4proto tcp counter packets 5 bytes 300 accept So what's the problem? The problem is that the command *ssh ...* (and other terminal commands) often fail because of I have no idea what. Everything seems to be just fine. The pid is in the right place, but the packets can't be picked up by the nftables rule. So the pid is under: # egrep -ir 21746 /sys/fs/cgroup ... /sys/fs/cgroup/morfikownia/user/ssh/cgroup.procs:21746 /sys/fs/cgroup/morfikownia/user/ssh/cgroup.threads:21746 ... But the ssh network packets are dropped because it seems they have different path set and that's why they can't be matched in nftables, which is weird because the pid is in the right place. So how can it be for a pid to have at the same time the right cgroup path and the wrong cgroup path? So what's going on here and how can this be fixed?
[systemd-devel] systemd 256 released
🎆 A new, official systemd release has just 🎉 been 🎊 tagged 🍾. Please download
the tarball here:
https://github.com/systemd/systemd/archive/v256.tar.gz
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.
* Support for System V service scripts is 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.
* 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.
* IPForward= setting in .network file is deprecated and replaced with
IPv4Forwarding= and IPv6Forwarding= settings. These new settings are
supported both in .network file and networkd.conf. If specified in a
.network file, they control corresponding per-link settings. If
specified in networkd.conf, they control corresponding global
settings. Note, previously IPv6SendRA= and IPMasquerade= implied
IPForward=, but now they imply the new per-link settings. One of the
simplest ways to migrate configurations, that worked as a router with
the previous version, is enabling both IPv4Forwarding= and
IPv6Forwarding= in networkd.conf. See systemd.network(5) and
networkd.conf(5) for more details.
* 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_SESSIONS=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.
* systemd.crash_reboot and related settings are deprecated in favor of
systemd.crash_action=.
General Changes and New Features:
* Various programs will now attempt to load the main configuration file
fro
Re: [systemd-devel] systemd-umount doesn't unmount LVM volumes
On Fr, 07.06.24 08:31, Vladimir Mokrozub (m...@mfc.tambov.gov.ru) wrote: > > > Uh, LVM is simply nothing anyone here tests, it's not really where the > > future is. Please reproduce with a current systemd version (i.e. 252 > > is two years old, an eternity in Linux), and file a bug, and maybe > > someone with an interest in LVM will look into, but don't hold your breath. > > Sorry for offtopic but why do you say there is no future for LVM? What's > wrong with it? I am pretty sure the future is with multi-device file systems. btrfs, bcachefs (even zfs if it weren't for that license fuckup). Conceptually, faking block device is just a silly approach. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-umount doesn't unmount LVM volumes
Uh, LVM is simply nothing anyone here tests, it's not really where the future is. Please reproduce with a current systemd version (i.e. 252 is two years old, an eternity in Linux), and file a bug, and maybe someone with an interest in LVM will look into, but don't hold your breath. Lennart -- Lennart Poettering, Berlin Sorry for offtopic but why do you say there is no future for LVM? What's wrong with it? -- Regards, Vladimir Mokrozub
[systemd-devel] systemd prerelease 256-rc4
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v256-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 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.
* Support for System V service scripts is 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.
* 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.
* IPForward= setting in .network file is deprecated and replaced with
IPv4Forwarding= and IPv6Forwarding= settings. These new settings are
supported both in .network file and networkd.conf. If specified in a
.network file, they control corresponding per-link settings. If
specified in networkd.conf, they control corresponding global
settings. Note, previously IPv6SendRA= and IPMasquerade= implied
IPForward=, but now they imply the new per-link settings. One of the
simplest ways to migrate configurations, that worked as a router with
the previous version, is enabling both IPv4Forwarding= and
IPv6Forwarding= in networkd.conf. See systemd.network(5) and
networkd.conf(5) for more details.
* 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.
* systemd.crash_reboot
Re: [systemd-devel] systemd-umount doesn't unmount LVM volumes
On Mi, 05.06.24 09:12, Vladimir Mokrozub (m...@mfc.tambov.gov.ru) wrote: > Hello, > > OS: Debian 12 > systemd: 252 > > Could someone please explain why systemd-umount doesn't unmount LVM volumes > by device: > > $ systemd-mount /dev/vg0/lv0 /mnt/lvm/ > Started unit mnt-lvm.mount for mount point: /mnt/lvm > > $ findmnt -n /mnt/lvm > /mnt/lvm /dev/mapper/vg0-lv0 ext4 rw,relatime > > $ systemctl list-units '*.mount' > mnt-lvm.mount loaded active mounted /mnt/lvm > > $ systemd-umount /dev/vg0/lv0 > $ systemd-umount /dev/mapper/vg0-lv0 > $ systemd-umount /dev/dm-0 > > None of the above commands unmount LVM volume. They don't produce any output > and the exit status is zero. > On the other hand, unmounting by the mountpoint works fine: > > $ systemd-umount /mnt/lvm/ > Stopped unit mnt-lvm.mount for mount point: /mnt/lvm > > This only happens with LVM, not with regular block devices. > Is this a bug or a feature? Uh, LVM is simply nothing anyone here tests, it's not really where the future is. Please reproduce with a current systemd version (i.e. 252 is two years old, an eternity in Linux), and file a bug, and maybe someone with an interest in LVM will look into, but don't hold your breath. Lennart -- Lennart Poettering, Berlin
[systemd-devel] systemd-umount doesn't unmount LVM volumes
Hello, OS: Debian 12 systemd: 252 Could someone please explain why systemd-umount doesn't unmount LVM volumes by device: $ systemd-mount /dev/vg0/lv0 /mnt/lvm/ Started unit mnt-lvm.mount for mount point: /mnt/lvm $ findmnt -n /mnt/lvm /mnt/lvm /dev/mapper/vg0-lv0 ext4 rw,relatime $ systemctl list-units '*.mount' mnt-lvm.mount loaded active mounted /mnt/lvm $ systemd-umount /dev/vg0/lv0 $ systemd-umount /dev/mapper/vg0-lv0 $ systemd-umount /dev/dm-0 None of the above commands unmount LVM volume. They don't produce any output and the exit status is zero. On the other hand, unmounting by the mountpoint works fine: $ systemd-umount /mnt/lvm/ Stopped unit mnt-lvm.mount for mount point: /mnt/lvm This only happens with LVM, not with regular block devices. Is this a bug or a feature? -- Regards, Vladimir Mokrozub
Re: [systemd-devel] systemd appears to lock up
For future reference, The issue was hyper-v reclaiming memory. Robert Landers Software Engineer Utrecht NL On Thu, May 30, 2024 at 11:19 AM Robert Landers wrote: > > Hello systemd developers, > > On WSL2 + Ubuntu 24, I'm seeing systemd locking up. There doesn't > appear to be any log messages once it locks up, it stops reaping > zombie/defunct processes and responding to socket requests. I can > reliably reproduce it (just wait about 10 minutes), but I haven't the > slightest clue on how to attach gdb to it in order to see what is > going on. > > Does anyone have any tips or documentation that I can take a look at > to help me debug this? > > Robert Landers > Software Engineer > Utrecht NL
[systemd-devel] systemd appears to lock up
Hello systemd developers, On WSL2 + Ubuntu 24, I'm seeing systemd locking up. There doesn't appear to be any log messages once it locks up, it stops reaping zombie/defunct processes and responding to socket requests. I can reliably reproduce it (just wait about 10 minutes), but I haven't the slightest clue on how to attach gdb to it in order to see what is going on. Does anyone have any tips or documentation that I can take a look at to help me debug this? Robert Landers Software Engineer Utrecht NL
Re: [systemd-devel] systemd-shutdown disarms hardware watchdog when finished
On Wed, 29 May 2024 at 11:01, Andreas Svensson wrote: > > Hello, > > I have a system that should keep the hardware watchdog active while > rebooting the system. It has worked fine up to systemd version v254. > > I noticed that since systemd version v254 my system stops the hardware > watchdog after systemd-shutdown completes. I think it's the > watchdog_free_device function that's responsible. > > The watchdog_free_device function will call watchdog_set_device(NULL) > from watchdog.h. Since commit f81048f8 the watchdog will be disarmed and > stopped if changed in watchdog_set_device. > > There's a comment just above watchdog_free_device in shutdown.c that > contradicts what's actually happening right now: "Note that the watchdog > is explicitly not stopped here". > > Is this the intended behavior? Anything I can do to get my system back > to its behavior before version v254 where my hardware watchdog is still > active/running after systemd-shutdown has finished? Use the Reboot/KexecWatchdog settings: https://www.freedesktop.org/software/systemd/man/latest/systemd-system.conf.html#RuntimeWatchdogSec=
Re: [systemd-devel] systemd-shutdown disarms hardware watchdog when finished
On 5/29/24 11:22, Lennart Poettering wrote: On Mi, 29.05.24 10:51, Andreas Svensson (andreas.svens...@axis.com) wrote: Hello, I have a system that should keep the hardware watchdog active while rebooting the system. It has worked fine up to systemd version v254. I noticed that since systemd version v254 my system stops the hardware watchdog after systemd-shutdown completes. I think it's the watchdog_free_device function that's responsible. The watchdog_free_device function will call watchdog_set_device(NULL) from watchdog.h. Since commit f81048f8 the watchdog will be disarmed and stopped if changed in watchdog_set_device. There's a comment just above watchdog_free_device in shutdown.c that contradicts what's actually happening right now: "Note that the watchdog is explicitly not stopped here". Is this the intended behavior? Anything I can do to get my system back to its behavior before version v254 where my hardware watchdog is still active/running after systemd-shutdown has finished? Yes, this is a bug and a regression. Can you file an issue on github about this please? (even better provide a PR that fixes this) Lennart -- Lennart Poettering, Berlin Ok, I will file a new issue on github in that case. Thanks! Best regards, Andreas
Re: [systemd-devel] systemd-shutdown disarms hardware watchdog when finished
On Mi, 29.05.24 10:51, Andreas Svensson (andreas.svens...@axis.com) wrote: > Hello, > > I have a system that should keep the hardware watchdog active while > rebooting the system. It has worked fine up to systemd version v254. > > I noticed that since systemd version v254 my system stops the hardware > watchdog after systemd-shutdown completes. I think it's the > watchdog_free_device function that's responsible. > > The watchdog_free_device function will call watchdog_set_device(NULL) from > watchdog.h. Since commit f81048f8 the watchdog will be disarmed and stopped > if changed in watchdog_set_device. > > There's a comment just above watchdog_free_device in shutdown.c that > contradicts what's actually happening right now: "Note that the watchdog is > explicitly not stopped here". > > Is this the intended behavior? Anything I can do to get my system back to > its behavior before version v254 where my hardware watchdog is still > active/running after systemd-shutdown has finished? Yes, this is a bug and a regression. Can you file an issue on github about this please? (even better provide a PR that fixes this) Lennart -- Lennart Poettering, Berlin
[systemd-devel] systemd-shutdown disarms hardware watchdog when finished
Hello, I have a system that should keep the hardware watchdog active while rebooting the system. It has worked fine up to systemd version v254. I noticed that since systemd version v254 my system stops the hardware watchdog after systemd-shutdown completes. I think it's the watchdog_free_device function that's responsible. The watchdog_free_device function will call watchdog_set_device(NULL) from watchdog.h. Since commit f81048f8 the watchdog will be disarmed and stopped if changed in watchdog_set_device. There's a comment just above watchdog_free_device in shutdown.c that contradicts what's actually happening right now: "Note that the watchdog is explicitly not stopped here". Is this the intended behavior? Anything I can do to get my system back to its behavior before version v254 where my hardware watchdog is still active/running after systemd-shutdown has finished? Best regards, Andreas Svensson
[systemd-devel] systemd prerelease 256-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v256-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 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.
* Support for System V service scripts is 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.
* 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.
* systemd.crash_reboot and related settings are deprecated in favor of
systemd.crash_action=.
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
support
[systemd-devel] systemd-run unset OnFailure property
I'm trying to add a global OnFailure= to all the services and excluding some non important services with /dev/null symlinks Now when using systemd-run in some cases I also don't want to run the OnFailure handler I tried (and multiple small variations) ``` systemd-run --unit=test --service-type=oneshot --property=OnFailure= --no-block -- /bin/false ``` it starts but it also run the OnFailure service Any ideas / workaround ? This is on Alma 9.3 (systemd-252-18.el9.x86_64) and Fedora 40 (systemd-255.6-1.fc40.x86_64) ``` cat > /usr/lib/systemd/system/onfailure-handler.service <<'EOF' [Unit] Description=onfailure handler [Service] Type=oneshot ExecStart=/usr/bin/echo fail EOF mkdir -p /usr/lib/systemd/system/service.d/ cat > /usr/lib/systemd/system/service.d/10-onfailure.conf <<'EOF' [Unit] OnFailure=onfailure-handler.service EOF ```
[systemd-devel] systemd prerelease 256-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v256-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 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.
* Support for System V service scripts is 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.
* 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.
* systemd.crash_reboot and related settings are deprecated in favor of
systemd.crash_action=.
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
support
Re: [systemd-devel] systemd prerelease 256-rc1
On Fr, 26.04.24 09:49, Neal Gompa (ngomp...@gmail.com) wrote: > > Well, people moved off split-usr quite successfully, which is a bigger > > feat than cleaning up the /boot/efi/ mess I'd say. > > > > Fedora is currently merging /usr/bin/ and /usr/sbin/, which I am pretty > > sure is a bigger change too. > > Neither of those involved screwing with mountpoints and changing code > around bootloaders. > > >From a distribution perspective, UsrMerge and the bin+sbin merge are > significantly simpler things. Well, believe what you want. But even in Fedora it's probably <= 15 packages that care about the EFI mount point. the sbin/bin merge and the usr merge otoh touched pretty much *every* package in the repo. I think the reproducible build stuff currently being in fedora is also going to be a harder thing to do. But anyway, we can certainly agree that we have different concepts/metrics of "hard" or "easy" tasks. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Fr, 26.04.24 09:47, Neal Gompa (ngomp...@gmail.com) wrote: > > > > * 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). > > > > > > This is not obsolete. Please do not say it is when it is not true. > > > > Uh, we mark outdated concepts as obsolete all the time. You might > > disagree with that, but that doesn't change the fact that from our PoV > > /boot/efi/ is obsolete, just like split /usr/, or cgroupv1. > > > > Nesting /efi/ in /boot/ is bad for plenty reasons, as has been widely > > discussed, so I am not going to repeat this here. And this has been > > communicated for multiple years now, and all the automatisms in > > systemd do not work for such a setup, hence I think saying that this > > setup is obsolete by now is not an understatement. > > > > I know that Fedora is sadly behind on boot loader topics, but that's > > no reason for changing our stance from systemd upstream on these > > things. > > There are fewer distros using /efi than /boot/efi, and no major > distributions that use /boot/efi. > > Complaining about it being a Fedora thing (which I guess I need to > remind this audience that I am involved in more than Fedora, and every > distribution I work on does use /boot/efi instead of /efi) is weird > since it's not just Fedora. It's pretty much everyone. Yeah, as the NEWS entry says, /boot/efi/ is commonly found. So? Doesn't change the fact it's a bad idea and from systemd's PoV an obsolete concept. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Fri, Apr 26, 2024 at 9:46 AM Lennart Poettering wrote: > > On Fr, 26.04.24 10:39, Dan Nicholson (d...@endlessos.org) wrote: > > > On Fri, Apr 26, 2024 at 10:11 AM Adrian Vovk wrote: > > > > > > Perhaps Fedora can be adjusted to follow the BLS's recommended mount > > > points? > > > > The problem with all of these type of "we've realized a better way and > > the old way is obsolete" is that it's left as someone else's issue to > > actually change existing users from the obsolete way. I've written > > code to migrate away from some old setup several times at Endless and > > it's always scary that you're going to screw a whole class of users > > and the only way out of that will be manual intervention. That's > > doubly so for something like this where it's touching critical boot > > files. Doing something wrong there may make someone's system unusable. > > > > So, while I do agree with the sentiment that /boot/efi is a bad idea > > and should not be done anymore, I have a lot of sympathy for Fedora > > continuing to use it. > > Well, people moved off split-usr quite successfully, which is a bigger > feat than cleaning up the /boot/efi/ mess I'd say. > > Fedora is currently merging /usr/bin/ and /usr/sbin/, which I am pretty > sure is a bigger change too. > Neither of those involved screwing with mountpoints and changing code around bootloaders. >From a distribution perspective, UsrMerge and the bin+sbin merge are significantly simpler things. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] systemd prerelease 256-rc1
On Fri, Apr 26, 2024 at 9:41 AM Lennart Poettering wrote: > > On Do, 25.04.24 18:52, Neal Gompa (ngomp...@gmail.com) wrote: > > > > * 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). > > > > This is not obsolete. Please do not say it is when it is not true. > > Uh, we mark outdated concepts as obsolete all the time. You might > disagree with that, but that doesn't change the fact that from our PoV > /boot/efi/ is obsolete, just like split /usr/, or cgroupv1. > > Nesting /efi/ in /boot/ is bad for plenty reasons, as has been widely > discussed, so I am not going to repeat this here. And this has been > communicated for multiple years now, and all the automatisms in > systemd do not work for such a setup, hence I think saying that this > setup is obsolete by now is not an understatement. > > I know that Fedora is sadly behind on boot loader topics, but that's > no reason for changing our stance from systemd upstream on these > things. > There are fewer distros using /efi than /boot/efi, and no major distributions that use /boot/efi. Complaining about it being a Fedora thing (which I guess I need to remind this audience that I am involved in more than Fedora, and every distribution I work on does use /boot/efi instead of /efi) is weird since it's not just Fedora. It's pretty much everyone. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] systemd prerelease 256-rc1
On Fr, 26.04.24 10:39, Dan Nicholson (d...@endlessos.org) wrote: > On Fri, Apr 26, 2024 at 10:11 AM Adrian Vovk wrote: > > > > Perhaps Fedora can be adjusted to follow the BLS's recommended mount points? > > The problem with all of these type of "we've realized a better way and > the old way is obsolete" is that it's left as someone else's issue to > actually change existing users from the obsolete way. I've written > code to migrate away from some old setup several times at Endless and > it's always scary that you're going to screw a whole class of users > and the only way out of that will be manual intervention. That's > doubly so for something like this where it's touching critical boot > files. Doing something wrong there may make someone's system unusable. > > So, while I do agree with the sentiment that /boot/efi is a bad idea > and should not be done anymore, I have a lot of sympathy for Fedora > continuing to use it. Well, people moved off split-usr quite successfully, which is a bigger feat than cleaning up the /boot/efi/ mess I'd say. Fedora is currently merging /usr/bin/ and /usr/sbin/, which I am pretty sure is a bigger change too. Noone here has any illusions, this is not going to be fixed from today to tomorrow, just like the usr-merge wasn't done in a day or the sbin-merge doesn't happen in a single day either. But I am very sure we shouldn't let the Linux platform stagnate like this. I think it really should be time to clean up /boot/efi/, we don't want that people get bored after the sbin-merge is complete, after all! Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Do, 25.04.24 18:52, Neal Gompa (ngomp...@gmail.com) wrote: > > * 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). > > This is not obsolete. Please do not say it is when it is not true. Uh, we mark outdated concepts as obsolete all the time. You might disagree with that, but that doesn't change the fact that from our PoV /boot/efi/ is obsolete, just like split /usr/, or cgroupv1. Nesting /efi/ in /boot/ is bad for plenty reasons, as has been widely discussed, so I am not going to repeat this here. And this has been communicated for multiple years now, and all the automatisms in systemd do not work for such a setup, hence I think saying that this setup is obsolete by now is not an understatement. I know that Fedora is sadly behind on boot loader topics, but that's no reason for changing our stance from systemd upstream on these things. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Fri, Apr 26, 2024 at 10:11 AM Adrian Vovk wrote: > > Perhaps Fedora can be adjusted to follow the BLS's recommended mount points? The problem with all of these type of "we've realized a better way and the old way is obsolete" is that it's left as someone else's issue to actually change existing users from the obsolete way. I've written code to migrate away from some old setup several times at Endless and it's always scary that you're going to screw a whole class of users and the only way out of that will be manual intervention. That's doubly so for something like this where it's touching critical boot files. Doing something wrong there may make someone's system unusable. So, while I do agree with the sentiment that /boot/efi is a bad idea and should not be done anymore, I have a lot of sympathy for Fedora continuing to use it. -- Dan Nicholson | Endless OS Foundation
Re: [systemd-devel] systemd prerelease 256-rc1
systemd has been recommending against an arrangement like that for a long
time now. These partitions are often fragile (read from bootloader code, or
worse firmware! VFAT has no data integrity), and they really have no reason
to be mounted unless they're about to be accessed. Stacking the mount
points like that requires /boot to be mounted to mount /efi, which is just
unnecessary
So systemd & the Boot Loader Standard (
https://uapi-group.org/specifications/specs/boot_loader_specification/#mount-points)
document separate /efi and /boot mount points, and recommend against
/boot/efi. In all of systemd's code, /boot/efi is treated as a fallback of
last resort, as a special case in the partition lookup logic, kept around
for backwards compatibility with distros that haven't changed their layout
to the recommended way. It's not even all that well supported/tested - it's
been broken in gpt-auto-generator and warranted a breaking change to fix
it. And systemd, left to its own devices, will never create such a mount
layout (i.e. w/ gpt-auto-generator and root=tmpfs)
So yes, in systemd /boot/efi is treated and thought of as obsolete. Distros
not following systemd's recommendations doesn't make the layout any less
deprecated from systemd's perspective.
Perhaps Fedora can be adjusted to follow the BLS's recommended mount points?
Best,
Adrian
On Thu, Apr 25, 2024, 21:53 Neal Gompa wrote:
> On Thu, Apr 25, 2024 at 6:15 PM systemd tag bot
> wrote:
> >
> > 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).
> >
>
> This is not obsolete. Please do not say it is when it is not true.
>
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>
Re: [systemd-devel] systemd prerelease 256-rc1
On Thu, Apr 25, 2024 at 6:15 PM systemd tag bot
wrote:
>
> 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).
>
This is not obsolete. Please do not say it is when it is not true.
--
真実はいつも一つ！/ Always, there's only one truth!
[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 user.
* New comman
[systemd-devel] systemd-oomd kill a lot of process instead of one service
Hello, I am running an uptodate archlinux, with gnome desktop. Please find the logs attached. In those logs we see that systemd-oomd is triggered, and select this scope for killing: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/tmux-spawn-c9dc150a-603e-4815-b501-1863913b09a4.scope But it also kills a lot of other processes on other scopes. Why ? >From what I understand, it should selecte "A" (one) cgroup and kill it… not >multiple process in multiple cgroups. https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#ManagedOOMSwap=auto%7Ckill > systemd-oomd will select a descendant cgroup and send SIGKILL to all of the > processes under it. Thank you in advance. -- Regards Maxime de Roucy mars 04 15:41:09 systemd[1407]: amazon-music.service: systemd-oomd killed some process(es) in this unit. mars 04 15:41:09 systemd-oomd[884]: Considered 93 cgroups for killing, top candidates were: mars 04 15:41:09 systemd-oomd[884]: Path: /user.slice/user-1000.slice/user@1000.service/app.slice/amazon-music.service mars 04 15:41:09 systemd-oomd[884]: Memory Pressure Limit: 0.00% mars 04 15:41:09 systemd-oomd[884]: Pressure: Avg10: 11.79 Avg60: 3.60 Avg300: 0.82 Total: 6s mars 04 15:41:09 systemd-oomd[884]: Current Memory Usage: 767.6M mars 04 15:41:09 systemd-oomd[884]: Memory Min: 0B mars 04 15:41:09 systemd-oomd[884]: Memory Low: 0B mars 04 15:41:09 systemd-oomd[884]: Pgscan: 5938984 mars 04 15:41:09 systemd-oomd[884]: Last Pgscan: 5787930 mars 04 15:41:09 systemd-oomd[884]: Path: /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-firefox\x2dw-43368.scope mars 04 15:41:09 systemd-oomd[884]: Memory Pressure Limit: 0.00% mars 04 15:41:09 systemd-oomd[884]: Pressure: Avg10: 0.00 Avg60: 0.00 Avg300: 0.00 Total: 213ms mars 04 15:41:09 systemd-oomd[884]: Current Memory Usage: 3.7G mars 04 15:41:09 systemd-oomd[884]: Memory Min: 0B mars 04 15:41:09 systemd-oomd[884]: Memory Low: 0B mars 04 15:41:09 systemd-oomd[884]: Pgscan: 446008 mars 04 15:41:09 systemd-oomd[884]: Last Pgscan: 446008 mars 04 15:41:09 systemd-oomd[884]: Path: /user.slice/user-1000.slice/user@1000.service/app.slice/slack.service mars 04 15:41:09 systemd-oomd[884]: Memory Pressure Limit: 0.00% mars 04 15:41:09 systemd-oomd[884]: Pressure: Avg10: 0.00 Avg60: 0.00 Avg300: 0.00 Total: 689ms mars 04 15:41:09 systemd-oomd[884]: Current Memory Usage: 1.2G mars 04 15:41:09 systemd-oomd[884]: Memory Min: 0B mars 04 15:41:09 systemd-oomd[884]: Memory Low: 0B mars 04 15:41:09 systemd-oomd[884]: Pgscan: 366303 mars 04 15:41:09 systemd-oomd[884]: Last Pgscan: 366303 mars 04 15:41:09 systemd-oomd[884]: Path: /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.gnome.Evolution-5266.scope mars 04 15:41:09 systemd-oomd[884]: Memory Pressure Limit: 0.00% mars 04 15:41:09 systemd-oomd[884]: Pressure: Avg10: 0.00 Avg60: 0.00 Avg300: 0.00 Total: 405ms mars 04 15:41:09 systemd-oomd[884]: Current Memory Usage: 652.3M mars 04 15:41:09 systemd-oomd[884]: Memory Min: 0B mars 04 15:41:09 systemd-oomd[884]: Memory Low: 0B mars 04 15:41:09 systemd-oomd[884]: Pgscan: 92829 mars 04 15:41:09 systemd-oomd[884]: Last Pgscan: 92829 mars 04 15:41:09 systemd-oomd[884]: Path: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/tmux-spawn-c9dc150a-603e-4815-b501-1863913b09a4.scope mars 04 15:41:09 systemd-oomd[884]: Memory Pressure Limit: 0.00% mars 04 15:41:09 systemd-oomd[884]: Pressure: Avg10: 0.00 Avg60: 0.00 Avg300: 0.00 Total: 2ms mars 04 15:41:09 systemd-oomd[884]: Current Memory Usage: 633.1M mars 04 15:41:09 systemd-oomd[884]: Memory Min: 0B mars 04 15:41:09 systemd-oomd[884]: Memory Low: 0B mars 04 15:41:09 systemd-oomd[884]: Pgscan: 276 mars 04 15:41:09 systemd-oomd[884]: Last Pgscan: 276 mars 04 15:41:09 systemd-oomd[884]: Path: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/tmux-spawn-1058a64d-7fc6-4566-ba25-660c5ea5cde9.scope mars 04 15:41:09 systemd-oomd[884]: Memory Pressure Limit: 0.00% mars 04 15:41:09 systemd-oomd[884]: Pressure: Avg10: 0.00 Avg60: 0.00 Avg300: 0.00 Total: 120us mars 04 15:41:09 systemd-oomd[884]: Current Memory Usage: 210.8M mars 04 15:41:09 systemd-oomd[884]: Memory Min: 0B mars 04 15:41:09 systemd-o
[systemd-devel] systemd journal remote filling disk with supposedly corrupted files
Hello, I'm trying to use systemd journal remote. Occasionally the system goes crazy, spams errors like this: systemd-journal-remote[]: File /var/log/journal/remote//remote-.journal corrupted or uncleanly shut down, renaming and replacing. When this happens, this leads to tens of 8MB .journal~ files per second, which usually ends badly. journalctl --verify says "PASS" for those files. I've been searching for answers and solutions for months. Tried various systemd versions from Debian bullseye, bookworm and backports (247, ... , 252). What can i do? Wolfgang
Re: [systemd-devel] systemd-pcrlock Failed to submit super PCR policy
On Mo, 05.02.24 09:24, Dominick Grift (dominick.gr...@defensec.nl) wrote: Please run "SYSTEMD_LOG_LEVEL=debug systemd-pcrlock make-policy" from the command line, then file a github issue about this, and pastethe output there. Lennart -- Lennart Poettering, Berlin
[systemd-devel] systemd-pcrlock Failed to submit super PCR policy
systemd v255 Debian Testing Linux nimbus 6.6.13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1 (2024-01-20) x86_64 GNU/Linux systemd-pcrlock Feb 04 20:00:02 nimbus audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=sys.id:sys.role:sys.subj:s0 msg='unit=systemd-pcrlock-make-policy comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Feb 04 20:00:02 nimbus systemd[1]: Failed to start systemd-pcrlock-make-policy.service - Make TPM2 PCR Policy. Feb 04 20:00:02 nimbus systemd[1]: systemd-pcrlock-make-policy.service: Failed with result 'exit-code'. Feb 04 20:00:02 nimbus systemd[1]: systemd-pcrlock-make-policy.service: Main process exited, code=exited, status=1/FAILURE Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Failed to submit super PCR policy: State not recoverable Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Failed to add OR policy to TPM: tpm:parameter(1):value is out of range or is not correct for the context Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: ERROR:esys:src/tss2-esys/api/Esys_PolicyOR.c:100:Esys_PolicyOR() Esys Finish ErrorCode (0x01c4) Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: WARNING:esys:src/tss2-esys/api/Esys_PolicyOR.c:286:Esys_PolicyOR_Finish() Received TPM Error Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting OR Branch #1: a36d5b482f1c0ff2c57737c7e8c671d88f0bb2cf52140034ec4b67774eb47e87 Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting OR Branch #0: 2cacf1f3ded4eead1044bd14c4e519a4614c6af51a4781a89126834b7830e81b Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting OR policy. Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: PolicyPCR calculated digest: a36d5b482f1c0ff2c57737c7e8c671d88f0bb2cf52140034ec4b67774eb47e87 Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: PolicyPCR calculated digest: 2cacf1f3ded4eead1044bd14c4e519a4614c6af51a4781a89126834b7830e81b Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Session policy digest: b117275cc6ee990f9c572b80e67a98f133cd092029b450eda445fb1ff2454886 Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Acquiring policy digest. Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting PCR hash policy. Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting PCR/OR policy for PCR 1 Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Session policy digest: 6cc828077856fbe4333c4372ec374df31f6c3a36b2e63b778d2e2ae6b3ef532a Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Acquiring policy digest. Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting OR Branch #1: 940dbe9fc9a5c4cb73e30e6454b659f8f635ebc0b6d4b327c4f98fad9bc56ccf Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting OR Branch #0: eeec8aadd13fef1af29067b499a8e9eeb82215a32a2bc838b5d5e4984c4d7100 Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Submitting OR policy. Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: PolicyPCR calculated digest: 940dbe9fc9a5c4cb73e30e6454b659f8f635ebc0b6d4b327c4f98fad9bc56ccf Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: PolicyPCR calculated digest: eeec8aadd13fef1af29067b499a8e9eeb82215a32a2bc838b5d5e4984c4d7100 Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Session policy digest: eeec8aadd13fef1af29067b499a8e9eeb82215a32a2bc838b5d5e4984c4d7100 Feb 04 20:00:02 nimbus systemd-pcrlock[35974]: Acquiring policy digest. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Submitting PCR hash policy. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Submitting PCR/OR policy for PCR 0 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Session policy digest: af31ab03c1d2d596f518acc44424bfa26c777400bc7c4e60f883663512a84988 Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Acquiring policy digest. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Submitting PCR hash policy. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Including PCR 14 in single value PolicyPCR expression Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Including PCR 13 in single value PolicyPCR expression Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Including PCR 12 in single value PolicyPCR expression Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Starting policy session. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Retrieving PIN from sealed data. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Starting HMAC encryption session. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x0005 property 0x count 1. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x0008 property 0x count 508. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x0002 property 0x011f count 256. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Getting TPM2 capability 0x property 0x0001 count 127. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: TPM successfully started up. Feb 04 20:00:01 nimbus systemd-pcrlock[35974]: Loaded TCTI module 'tcti-device' (TCTI module for communication with Linux kernel interface.) [Version 2] Feb 04 20:00:01 nimbus systemd-pcrlock[35974]
Re: [systemd-devel] Systemd units complains about cgroup with 5.15.x kernel
Dear Lennart, thanks for the tips. The distro is buildroot, that compiles systemd with " -Ddefault-hierarchy=unified ". Should I consider that the named kernel has incomplete cgroupsv2 support ? (How can I check that ?). I would need to cleanup the log before pasting it in a mail, but what I can see is that some services start (NetworkManager), other not (sshd), without being able to guess what makes them to fail or not. I will obviously try to recompile with "-Ddefault-hierarchy=hybrid" today to check if that makes a change. Best regards Thierry Le 01/02/2024 à 22:27, Lennart Poettering a écrit : On Do, 01.02.24 16:30, Thierry Bultel (thierry.bul...@linatsea.fr) wrote: Hi, I am using systemd v255, and currently using a kernel vendor branch : g...@github.com:varigit/linux-imx.git lf-5.15.y_var01 imx_v7_defconfig I had no issue with the older 5.4 kernel. I have verified that the kernel has the following options: CONFIG_DEVTMPFS=y CONFIG_CGROUPS=y CONFIG_INOTIFY_USER=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EPOLL=y CONFIG_UNIX=y CONFIG_SYSFS=y CONFIG_PROC_FS=y CONFIG_FHANDLE=y CONFIG_NET_NS=y CONFIG_SYSFS_DEPRECATED is not set CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y ---> systemd is failing to start some units: systemd[1]: wpa_supplicant.service: Failed to create cgroup /system.slice/wpa_supplicant.service: No such file or directory and also; (agetty)[217]:serial-getty@ttymxc0.service: Failed to attach to cgroup /system.slice/system-serial\x2dgetty.slice/serial-getty@ttymxc0.service: No medium found ... and I do not have a serial console. I am currently digging into systemd code to find out what is possibly wrong .. but if anyone gets a clue, I would appreciate ! Educated guess, you have no cgroupvs2 or so? Would make sense to provide logs?, use strace to check what precisely fails? Ask you distro for help? Lennart -- Lennart Poettering, Berlin -- Re: test www.linatsea.fr -- www.linatsea.fr
Re: [systemd-devel] Systemd units complains about cgroup with 5.15.x kernel
On Do, 01.02.24 16:30, Thierry Bultel (thierry.bul...@linatsea.fr) wrote: > Hi, > > I am using systemd v255, > and currently using a kernel vendor branch : > > g...@github.com:varigit/linux-imx.git > lf-5.15.y_var01 > imx_v7_defconfig > > I had no issue with the older 5.4 kernel. > > I have verified that the kernel has the following options: > > CONFIG_DEVTMPFS=y > CONFIG_CGROUPS=y > CONFIG_INOTIFY_USER=y > CONFIG_SIGNALFD=y > CONFIG_TIMERFD=y > CONFIG_EPOLL=y > CONFIG_UNIX=y > CONFIG_SYSFS=y > CONFIG_PROC_FS=y > CONFIG_FHANDLE=y > > CONFIG_NET_NS=y > > CONFIG_SYSFS_DEPRECATED is not set > > CONFIG_AUTOFS_FS=y > CONFIG_AUTOFS4_FS=y > CONFIG_TMPFS_POSIX_ACL=y > CONFIG_TMPFS_XATTR=y > > ---> > > systemd is failing to start some units: > > systemd[1]: wpa_supplicant.service: Failed to create cgroup > /system.slice/wpa_supplicant.service: No such file or directory > and also; > (agetty)[217]: serial-getty@ttymxc0.service: Failed to attach to cgroup > /system.slice/system-serial\x2dgetty.slice/serial-getty@ttymxc0.service: No > medium found > > ... and I do not have a serial console. > > I am currently digging into systemd code to find out what is possibly wrong > .. but if anyone gets a clue, I would appreciate ! Educated guess, you have no cgroupvs2 or so? Would make sense to provide logs?, use strace to check what precisely fails? Ask you distro for help? Lennart -- Lennart Poettering, Berlin
[systemd-devel] Systemd units complains about cgroup with 5.15.x kernel
Hi, I am using systemd v255, and currently using a kernel vendor branch : g...@github.com:varigit/linux-imx.git lf-5.15.y_var01 imx_v7_defconfig I had no issue with the older 5.4 kernel. I have verified that the kernel has the following options: CONFIG_DEVTMPFS=y CONFIG_CGROUPS=y CONFIG_INOTIFY_USER=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EPOLL=y CONFIG_UNIX=y CONFIG_SYSFS=y CONFIG_PROC_FS=y CONFIG_FHANDLE=y CONFIG_NET_NS=y CONFIG_SYSFS_DEPRECATED is not set CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y ---> systemd is failing to start some units: systemd[1]: wpa_supplicant.service: Failed to create cgroup /system.slice/wpa_supplicant.service: No such file or directory and also; (agetty)[217]: serial-getty@ttymxc0.service: Failed to attach to cgroup /system.slice/system-serial\x2dgetty.slice/serial-getty@ttymxc0.service: No medium found ... and I do not have a serial console. I am currently digging into systemd code to find out what is possibly wrong .. but if anyone gets a clue, I would appreciate ! Thanks ! Thierry -- Re: test
Re: [systemd-devel] Systemd-nspawn single process
Hello, Thanks for the tip, I've taken a more recent version of systemd-nspawn and it now works. I now have another question: I want to set up a signle process. I have a problem on the network side, I want to launch my signle process by connecting it to a bridge. In the .nspawn file, in the network section, I specified the use of the bridge. Then systemd-nspawn, when the container is launched, will create a pair of veths, one inside the container (host0) and the other on my host connected to the bridge. I want my host0 interface, which is inside the container, to take a static IP and the interface to be up directly when I launch my container. To do this I've created a process1.network configuration file in /etc/systemd/network [Match] Virtualization=container Driver=veth Host=process1 [Network] Address=10.10.0.15/23 Gateway=10.10.0.1 I also tried mounting this file in /etc/systemd/network in my container host0.network [Match] #Virtualization=container Name=host0 [Network] Address=10.10.0.15/23 Gateway=10.10.0.1 Despite these two approaches, I can't manage to allocate a static IP address to host0 when the container is launched, so I have to do it manually in the container using the : ip addr add 10.10.0.15/23 dev host0 ip link set host0 up Shouldn't we be able to specify the container ip directly in the process1.nspawn file? Thanks. Le ven. 1 déc. 2023 à 22:22, Lennart Poettering a écrit : > On Fr, 01.12.23 14:03, Warex61 YTB (thomasdabou...@gmail.com) wrote: > > > Hello, > > I would like to use systemd-nspawn to create a container that can launch > a > > single process as pid 1 and mount its configuration files. I want the > > container to be as light as possible. Is there any way of creating a > > container using nspawn without using bootstrap ? > > > > For example, using this command, without using a bootstrap > > > > systemd-nspawn -M process -D /etc/systemd/nspawn/process > > /etc/systemd/nspawn/process.nspawn > > I get the following error > > > > Directory /etc/systemd/nspawn/process doesn't look like it has an OS > tree. > > Refusing. > > What are the conditions for nspawn to consider an OS tree in > > /etc/systemd/nspawn/process ? > > You are using an ancient version of nspawn. Since 2y or so the message > reads: > > Directory %s doesn't look like it has an OS tree (/usr/ directory > is missing). Refusing. > > And that's your explanation: you need an /usr/ directory. > > Lennart > > -- > Lennart Poettering, Berlin >
[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 images (sysext) can now set EXTENSION_RELOAD_MANAGER=1 in th
[systemd-devel] systemd-pcrlock: what prevents unauthorized changes to the NV index?
What prevents unauthorized changes to the NV index used by systemd-pcrlock? Is the secret key itself stored in the NV index, with the policy deciding who can read the key? Or does the policy on the NV index require that the policy established by systemd-pcrlock is itself satisfied before the NV index can be changed? In the latter case, does this mean that the index can be "leaked" in certain error conditions? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] systemd: questions about dbus dependency service
On Mo, 04.12.23 13:01, Pintu Agarwal (pintu.p...@gmail.com) wrote: > Hi, > Any comments or suggestions on the below ? I already replied. https://lists.freedesktop.org/archives/systemd-devel/2023-November/049706.html Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd: questions about dbus dependency service
Hi, Any comments or suggestions on the below ? On Tue, 28 Nov 2023 at 22:48, Pintu Agarwal wrote: > > Hi, > > I need some clarification about systemd services that are dependent on dbus > service. > > We have a service that depends on dbus.service, so our service has to be > started after dbus.socket and dbus.service. > But dbus.service comes after local-fs.target and sysinit.target. > However, our service needs to be started very early on boot-up, maybe within > local-fs target itself, otherwise it is causing regression in our boot KPI. > > How can we solve this issue in the most efficient way? > > We are using Linux Kernel 5.15 with arm64 and a high speed quad-core > processor. > Also, the storage type is NAND with limited speed (12.5 MBPS). > The filesystem is UBI + squashfs volumes. > > Thanks, > Pintu
[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 to be skipped in the final SIGTERM/SIGKILL spree on shutdown.
Re: [systemd-devel] Systemd-nspawn single process
On Fr, 01.12.23 14:03, Warex61 YTB (thomasdabou...@gmail.com) wrote: > Hello, > I would like to use systemd-nspawn to create a container that can launch a > single process as pid 1 and mount its configuration files. I want the > container to be as light as possible. Is there any way of creating a > container using nspawn without using bootstrap ? > > For example, using this command, without using a bootstrap > > systemd-nspawn -M process -D /etc/systemd/nspawn/process > /etc/systemd/nspawn/process.nspawn > I get the following error > > Directory /etc/systemd/nspawn/process doesn't look like it has an OS tree. > Refusing. > What are the conditions for nspawn to consider an OS tree in > /etc/systemd/nspawn/process ? You are using an ancient version of nspawn. Since 2y or so the message reads: Directory %s doesn't look like it has an OS tree (/usr/ directory is missing). Refusing. And that's your explanation: you need an /usr/ directory. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Systemd-nspawn single process
Hello, I would like to use systemd-nspawn to create a container that can launch a single process as pid 1 and mount its configuration files. I want the container to be as light as possible. Is there any way of creating a container using nspawn without using bootstrap ? For example, using this command, without using a bootstrap systemd-nspawn -M process -D /etc/systemd/nspawn/process /etc/systemd/nspawn/process.nspawn I get the following error Directory /etc/systemd/nspawn/process doesn't look like it has an OS tree. Refusing. What are the conditions for nspawn to consider an OS tree in /etc/systemd/nspawn/process ? Thanks.
Re: [systemd-devel] systemd: questions about dbus dependency service
On Di, 28.11.23 22:48, Pintu Agarwal (pintu.p...@gmail.com) wrote: > Hi, > > I need some clarification about systemd services that are dependent on dbus > service. > > We have a service that depends on dbus.service, so our service has to be > started after dbus.socket and dbus.service. It's usually a good idea to not wait for dbus.sevice. Waiting for dbus.socket is sufficient, it makes sure clients can connect to D-Bus (even if dbus needs to finish starting up to respond to it). This will increase parallelization during boot. > But dbus.service comes after local-fs.target and sysinit.target. > However, our service needs to be started very early on boot-up, maybe > within local-fs target itself, otherwise it is causing regression in our > boot KPI. dbus is not a suitable IPC for early boot services, unless you speak the dbus protocol directly between client and service, without involving the broker. But that's messy. systemd's PID 1 does this (i.e. dbus without a broker), because it must be accessible early on, but I hate that code, and I'd rather kill it. In new code that must run in early boot we usually use a different IPC (varlink), that does not involve any broker, and thus always works. Lennart -- Lennart Poettering, Berlin
[systemd-devel] systemd: questions about dbus dependency service
Hi, I need some clarification about systemd services that are dependent on dbus service. We have a service that depends on dbus.service, so our service has to be started after dbus.socket and dbus.service. But dbus.service comes after local-fs.target and sysinit.target. However, our service needs to be started very early on boot-up, maybe within local-fs target itself, otherwise it is causing regression in our boot KPI. How can we solve this issue in the most efficient way? We are using Linux Kernel 5.15 with arm64 and a high speed quad-core processor. Also, the storage type is NAND with limited speed (12.5 MBPS). The filesystem is UBI + squashfs volumes. Thanks, Pintu
[systemd-devel] Systemd-logind StopIdleSessionSec option ignored for multiplexed (control master) ssh sessions?
Hi, not sure if this is the right place to ask. If it's not then just ignore this post. systemd-logind has recently introduced an option StopIdleSessionSec which has become available in Rocky 8.7 and onward as well as in Rocky 9. >From logind.conf(5): StopIdleSessionSec= Specifies a timeout in seconds, or a time span value after which systemd-logind checks the idle state of all sessions. Every session that is idle for longer then the timeout will be stopped. Defaults to “infinity” (systemd-logind is not checking the idle state of sessions). For details about the syntax of time spans, see systemd.time(7). This works as expected for regular ssh sessions. However, multiplexed (control master) ssh sessions that exceed the configured timeout are *not* being terminated. Steps to reproduce: On remote system (as root): * Configure StopIdleSessionSec=300 in /etc/systemd/logind.conf * Run systemctl restart systemd-logind.service On local system: Open control master ssh session to remote system (initial master connection) * mkdir -p ~/.ssh/controlmasters * ssh -M -S ~/.ssh/controlmasters/%r@%h:%p user@remote On local system (from another terminal): Open subsequent slave ssh connection to remote system via control socket of the master connection established above * ssh -S ~/.ssh/controlmasters/%r@%h:%p user@remote On remote system (as root): Observe IDLE time of both user sessions increasing beyond configured timeout of 300 seconds * watch w Note that both ssh sessions remain alive when their IDLE time exceeds the configured timeout of 300 seconds. I did expect that multiplexed control master ssh sessions that are idle for longer than StopIdleSessionSec timeout would have been terminated as well much like regular (non multiplexed) ssh sessions. But that does not seem to be the case. Is that expected/intended behaviour? Or a bug? Or am I missing something? Best regards Jürgen
[systemd-devel] systemd-networkd code design documentation?
Hi, As I start looking at the code, is there any design documentation for developers that describes systemd-networkd? Specifically, I'm looking for an overview of the data-flow when an IPv6 Router Advertisement is received, where it is processed and where it generates the reply. I'm slowly building a picture of this flow, but if someone has already been down this path and is willing to share, then it will save me some time. Thanks, Matt.
[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 to be skipped in the final SIGTERM/SIGKILL spree on shutdown.
[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 automatically reload the service manager (PID 1) when merging/refre
[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 automatically reload the service manager (PID 1) when merging/refre
Re: [systemd-devel] systemd-resolve and name servers order
> In the past prior to systemd-resolve as a default solution the order I > think was followed. From what I understand windows > https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows- > server-2008-R2-and-2008/dd197552(v=ws.10) > prefers first server on the list (it doesn't prefer secondary over > tertiary but first one is preferred) so people got used to it. Now > systemd-resolve doesn't seem to care about the order. Formally that > might be a correct approach but this is a change to what we used to have > in the past. So I think having possibility to follow the order would be > something nice to have. I also do not really get sometimes the design changes. I am having different orders in resolv.conf to spread the load over nameservers. So having this done automatically is sort of nice and better. I do not think there will be much support this use case. I think you can only extend this situation a bit, but at some point you need to rethink this architecture. I am here to complain about logging, systemd duplicates the required iops in certain cases (can't even remember exactly). Now I am stuck with no reporting at all on services that start/stop. To be honest I am to busy with other things to familiarize myself with systemd and criticize things.
Re: [systemd-devel] systemd-resolve and name servers order
> > Obviously there are other solutions to the problem described above (eg > having multiple internal servers, although my experience was in the SOHO > environment where that would be excessive). If as Rafał says Windows > prioritises the first DNS option then I'm pretty sure that wasn't always > the case, but it's been well over a decade since I got out of Windows IT > support! For now I would think of disabling systemd resolving (uninstall systemd-resolved) and maybe networkmanager, so you can have the resolv.conf back. I can also think of maybe doing something with dnsmasq, it is quite simple and maybe offers this.
Re: [systemd-devel] systemd-resolve and name servers order
On Wed, 11 Oct 2023 at 09:37, Marc wrote: > Having 3 different nameservers reporting different results? > An example I have seen quite frequently is where there is an internal DNS which resolves local (internal) server resources and forwards anything else to an external server such as 8.8.8.8. When the internal DNS fails (typically because it's been taken down for server updates) it would be useful for clients to still have access to the external DNS - even if they can't access local resources they can still access external ones, and in reality they probably already had the internal resource IPs cached anyway. So having client DNS configured as 192.168.x.x (primary) and 8.8.8.8 (secondary) makes sense. But as you say this isn't how resolv.conf was designed (nor other DNS clients in my experience), and configuring a client that way will cause a lot of internal requests to fail even when the local DNS is operational. It's a shame that DNS clients can't have server configurations much like MX records where a random choice is made between servers of the same priority, but lower priority options can be configured too (as that would also allow load balancing of requests across multiple servers as now). I don't know of any clients that do this, though. Obviously there are other solutions to the problem described above (eg having multiple internal servers, although my experience was in the SOHO environment where that would be excessive). If as Rafał says Windows prioritises the first DNS option then I'm pretty sure that wasn't always the case, but it's been well over a decade since I got out of Windows IT support! But there are certainly use cases for allowing DNS server prioritisation in this way. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0344 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
Re: [systemd-devel] systemd-resolve and name servers order
> > I hope this is the right mailing list to ask that kind of question. I'm > following what is recommended on github issue tracker: > https://github.com/systemd/systemd/issues/new/choose > If it's not - feel free to point me to a different place. > > I use azure ubuntu 20.04 build with nameservers obtained by DHCP (there > are three custom nameservers assigned to Azure private Vnet and they are > owned by my company). > These three nameservers are not equal. So the first server provides > different answers than the second and the third server. I think this is not how resolv.conf was designed to be used. Are you 100% sure this is the only way to solve your issue? Having 3 different nameservers reporting different results? Can't you do something with views and sorting? What about just giving your server 3 different ip's and configure the nameservers with specific views for that?
Re: [systemd-devel] systemd-resolve and name servers order
W dniu 2023-10-11 09:50, Marc napisał(a): I think this is not how resolv.conf was designed to be used. Are you 100% sure this is the only way to solve your issue? Having 3 different nameservers reporting different results? Can't you do something with views and sorting? What about just giving your server 3 different ip's and configure the nameservers with specific views for that? Three different nameservers reporting different results is not my design. It's something myself as end user I have been given and I have to live with. Whole company has to live with it. The solution you are describing is probably technically possible but that's not just one server - it's plenty of servers that are managed by different configuration systems that simply receive network settings via DHCP. Assigning three different IP addresses and configuring views (bind views I'm assuming?) adds massive complexity so I hoped some simpler solution will be possible. In the past prior to systemd-resolve as a default solution the order I think was followed. From what I understand windows https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197552(v=ws.10) prefers first server on the list (it doesn't prefer secondary over tertiary but first one is preferred) so people got used to it. Now systemd-resolve doesn't seem to care about the order. Formally that might be a correct approach but this is a change to what we used to have in the past. So I think having possibility to follow the order would be something nice to have.
