Re: [systemd-devel] Systemd sessionid like `c508`
Thank you Mantas! On Tue, Jan 10, 2023 at 10:58 PM Mantas Mikulėnas wrote: > > The sessions listed in loginctl are created and their IDs assigned by > systemd-logind (when asked by pam_systemd). > > If /proc/*/loginuid and /proc/*/sessionid are available (set up by > pam_loginuid), then logind directly takes the audit session ID as logind > session ID. > > If those are not available (kernel audit support disabled), then logind > itself allocates a logind session ID and adds the "c" prefix to prevent > collisions with audit IDs. > > src/login/logind-dbus.c:870:if (asprintf(, "c%lu", > ++m->session_counter) < 0) > > On Wed, Jan 11, 2023, 05:58 hai wu wrote: >> >> Where is the systemd sessionid like `c508` being generated? If kernel >> auditd is disabled, then it seems systemd `loginctl list-sessions` >> command would list user session ids all with `c` character prefix >> instead. >> >> I could not find the source code where these session ids got >> generated. Are these session ids generated from systemd source code or >> from Linux kernel source code? >> >> systemd has this function `sd_pid_get_session` to get session id, it >> seems that's parsing `/proc/self/cgroup`, instead of generating such >> session ids.. >> >> Regards, >> Hai
Re: [systemd-devel] Systemd sessionid like `c508`
The sessions listed in loginctl are created and their IDs assigned by systemd-logind (when asked by pam_systemd). If /proc/*/loginuid and /proc/*/sessionid are available (set up by pam_loginuid), then logind directly takes the audit session ID as logind session ID. If those are not available (kernel audit support disabled), then logind itself allocates a logind session ID and adds the "c" prefix to prevent collisions with audit IDs. src/login/logind-dbus.c:870:if (asprintf(, "c%lu", ++m->session_counter) < 0) On Wed, Jan 11, 2023, 05:58 hai wu wrote: > Where is the systemd sessionid like `c508` being generated? If kernel > auditd is disabled, then it seems systemd `loginctl list-sessions` > command would list user session ids all with `c` character prefix > instead. > > I could not find the source code where these session ids got > generated. Are these session ids generated from systemd source code or > from Linux kernel source code? > > systemd has this function `sd_pid_get_session` to get session id, it > seems that's parsing `/proc/self/cgroup`, instead of generating such > session ids.. > > Regards, > Hai >
[systemd-devel] Systemd sessionid like `c508`
Where is the systemd sessionid like `c508` being generated? If kernel auditd is disabled, then it seems systemd `loginctl list-sessions` command would list user session ids all with `c` character prefix instead. I could not find the source code where these session ids got generated. Are these session ids generated from systemd source code or from Linux kernel source code? systemd has this function `sd_pid_get_session` to get session id, it seems that's parsing `/proc/self/cgroup`, instead of generating such session ids.. Regards, Hai
Re: [systemd-devel] Container restart issue: Failed to attach 1 to compat systemd cgroup
I omitted one piece of information about running with --cgroupns=private thinking it was unrelated, but actually it appears maybe it is related (and perhaps highlights a variant of the issue that is seen on first-boot, not only on container restart). Again (and what makes me think it's related), I can reproduce this on a Centos host but not on Ubuntu (still with SELinux in 'permissive' mode). [root@localhost ~]# podman run -it --name ubuntu --privileged --cgroupns private ubuntu-systemd systemd 245.4-4ubuntu3.19 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTI) Detected virtualization podman. Detected architecture x86-64. Welcome to Ubuntu 20.04.5 LTS! Set hostname to . *Couldn't move remaining userspace processes, ignoring: Input/output errorFailed to create compat systemd cgroup /system.slice: No such file or directoryFailed to create compat systemd cgroup /system.slice/system-getty.slice: No such file or directory* [ OK ] Created slice system-getty.slice. *Failed to create compat systemd cgroup /system.slice/system-modprobe.slice: No such file or directory*[ OK ] Created slice system-modprobe.slice. *Failed to create compat systemd cgroup /user.slice: No such file or directory*[ OK ] Created slice User and Session Slice. [ OK ] Started Dispatch Password Requests to Console Directory Watch. [ OK ] Started Forward Password Requests to Wall Directory Watch. This first warning is coming from one of the same areas of code I linked in my first email: https://github.com/systemd/systemd/blob/v245/src/core/cgroup.c#L2967. I see the same thing with '--cap-add sys_admin' instead of '--privileged', and again seen with both docker and podman. Thanks, Lewis On Tue, 10 Jan 2023 at 15:28, Lewis Gaul wrote: > I'm aware of the higher level of collaboration between podman and systemd > compared to docker, hence primarily raising this issue from a podman angle. > > In privileged mode all mounts are read-write, so yes the container has > write access to the cgroup filesystem. (Podman also ensures write access to > the systemd cgroup subsystem mount in non-privileged mode by default). > > On first boot PID 1 can be found in > /sys/fs/cgroup/systemd/machine.slice/libpod-.scope/init.scope/cgroup.procs, > whereas when the container restarts the 'init.scope/' directory does not > exist and PID 1 is instead found in the parent (container root) cgroup > /sys/fs/cgroup/systemd/machine.slice/libpod-.scope/cgroup.procs > (also reflected by /proc/1/cgroup). This is strange because systemd must be > the one to create this cgroup dir in the initial boot, so I'm not sure why > it wouldn't on subsequent boot? > > I can confirm that the container has permissions since executing a 'mkdir' > in /sys/fs/cgroup/systemd/machine.slice/libpod-.scope/ inside the > container succeeds after the restart, so I have no idea why systemd is not > creating the 'init.scope/' dir. I notice that inside the container's > systemd cgroup mount 'system.slice/' does exist, but 'user.slice/' also > does not (both exist on normal boot). Is there any way I can find systemd > logs that might indicate why the cgroup dir creation is failing? > > One final datapoint: the same is seen when using a private cgroup > namespace (via 'podman run --cgroupns=private'), although then the error is > then, as expected, "Failed to attach 1 to compat systemd cgroup > /init.scope: No such file or directory". > > I could raise this with the podman team, but it seems more in the systemd > area given it's a systemd warning and I would expect systemd to be creating > this cgroup dir? > > Thanks, > Lewis > > On Tue, 10 Jan 2023 at 14:48, Lennart Poettering > wrote: > >> On Di, 10.01.23 13:18, Lewis Gaul (lewis.g...@gmail.com) wrote: >> >> > Following 'setenforce 0' I still see the same issue (I was also >> suspecting >> > SELinux!). >> > >> > A few additional data points: >> > - this was not seen when using systemd v230 inside the container >> > - this is also seen on CentOS 8.4 >> > - this is seen under docker even if the container's cgroup driver is >> > changed from 'cgroupfs' to 'systemd' >> >> docker is garbage. They are hostile towards running systemd inside >> containers. >> >> podman upstream is a lot friendly, and apparently what everyone in OCI >> is going towards these days. >> >> I have not much experience with podman though, and in particular not >> old versions. Next step would probably be to look at what precisely >> causes the permission issue, via strace. >> >> but did you make sure your container actually gets write access to the >> cgroup trees? >> >> anyway, i'd recommend asking the podman community for help about this. >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> >
Re: [systemd-devel] Container restart issue: Failed to attach 1 to compat systemd cgroup
I'm aware of the higher level of collaboration between podman and systemd compared to docker, hence primarily raising this issue from a podman angle. In privileged mode all mounts are read-write, so yes the container has write access to the cgroup filesystem. (Podman also ensures write access to the systemd cgroup subsystem mount in non-privileged mode by default). On first boot PID 1 can be found in /sys/fs/cgroup/systemd/machine.slice/libpod-.scope/init.scope/cgroup.procs, whereas when the container restarts the 'init.scope/' directory does not exist and PID 1 is instead found in the parent (container root) cgroup /sys/fs/cgroup/systemd/machine.slice/libpod-.scope/cgroup.procs (also reflected by /proc/1/cgroup). This is strange because systemd must be the one to create this cgroup dir in the initial boot, so I'm not sure why it wouldn't on subsequent boot? I can confirm that the container has permissions since executing a 'mkdir' in /sys/fs/cgroup/systemd/machine.slice/libpod-.scope/ inside the container succeeds after the restart, so I have no idea why systemd is not creating the 'init.scope/' dir. I notice that inside the container's systemd cgroup mount 'system.slice/' does exist, but 'user.slice/' also does not (both exist on normal boot). Is there any way I can find systemd logs that might indicate why the cgroup dir creation is failing? One final datapoint: the same is seen when using a private cgroup namespace (via 'podman run --cgroupns=private'), although then the error is then, as expected, "Failed to attach 1 to compat systemd cgroup /init.scope: No such file or directory". I could raise this with the podman team, but it seems more in the systemd area given it's a systemd warning and I would expect systemd to be creating this cgroup dir? Thanks, Lewis On Tue, 10 Jan 2023 at 14:48, Lennart Poettering wrote: > On Di, 10.01.23 13:18, Lewis Gaul (lewis.g...@gmail.com) wrote: > > > Following 'setenforce 0' I still see the same issue (I was also > suspecting > > SELinux!). > > > > A few additional data points: > > - this was not seen when using systemd v230 inside the container > > - this is also seen on CentOS 8.4 > > - this is seen under docker even if the container's cgroup driver is > > changed from 'cgroupfs' to 'systemd' > > docker is garbage. They are hostile towards running systemd inside > containers. > > podman upstream is a lot friendly, and apparently what everyone in OCI > is going towards these days. > > I have not much experience with podman though, and in particular not > old versions. Next step would probably be to look at what precisely > causes the permission issue, via strace. > > but did you make sure your container actually gets write access to the > cgroup trees? > > anyway, i'd recommend asking the podman community for help about this. > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] Container restart issue: Failed to attach 1 to compat systemd cgroup
On Di, 10.01.23 13:18, Lewis Gaul (lewis.g...@gmail.com) wrote: > Following 'setenforce 0' I still see the same issue (I was also suspecting > SELinux!). > > A few additional data points: > - this was not seen when using systemd v230 inside the container > - this is also seen on CentOS 8.4 > - this is seen under docker even if the container's cgroup driver is > changed from 'cgroupfs' to 'systemd' docker is garbage. They are hostile towards running systemd inside containers. podman upstream is a lot friendly, and apparently what everyone in OCI is going towards these days. I have not much experience with podman though, and in particular not old versions. Next step would probably be to look at what precisely causes the permission issue, via strace. but did you make sure your container actually gets write access to the cgroup trees? anyway, i'd recommend asking the podman community for help about this. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] service dependencies
Thank you both for your replies and suggestions. I assume this one is related: https://github.com/systemd/systemd/issues/1312 And yes, I found a lot of posts about this, but no real solution. I will further read further details about 'Upholds' and 'PropagatesStopTo. The real use case I need to solve involves another service. test2 not only requires test1 but also test0. So, test2 should only be actived if test1 and test0 are activated. The optimal solution IMHO does not require to change test0 or test1. As test2 is the one with the requirements. I assume I can use WantedBy in the install section of test2, but this would require that the service is enabled / installed and not only started (for my use case okay, but IMHO not optimal).
Re: [systemd-devel] Container restart issue: Failed to attach 1 to compat systemd cgroup
Following 'setenforce 0' I still see the same issue (I was also suspecting SELinux!). A few additional data points: - this was not seen when using systemd v230 inside the container - this is also seen on CentOS 8.4 - this is seen under docker even if the container's cgroup driver is changed from 'cgroupfs' to 'systemd' Thanks, Lewis On Tue, 10 Jan 2023 at 11:12, Lennart Poettering wrote: > On Mo, 09.01.23 19:45, Lewis Gaul (lewis.g...@gmail.com) wrote: > > > Hi all, > > > > I've come across an issue when restarting a systemd container, which I'm > > seeing on a CentOS 8.2 VM but not able to reproduce on an Ubuntu 20.04 VM > > (both cgroups v1). > > selinux? > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] service dependencies
On Tue, Jan 10, 2023 at 2:48 PM Markus Rathgeb wrote: > > Hello, > > I have a question about service dependencies. > > Assume there are two services > * test1 > * test2 > > (for testing purpose only I am using user services) > > The test2 service requires that test1 service is active. > The test2 service cannot work if test1 is not active, so it should ensure > * test1 is started before test2 > * test2 is terminated if test1 terminates > > I tried this unit section for test2.service > > BindsTo=test1.service > After=test1.service > > (The point I do not understand is equal for `Requires` instead of `BindsTo`) > > If I start test2.service test1 is started and afterwards test2. > > systemctl --user start test2 > > Jan 10 11:46:59 tpt590 systemd[2552]: Started test1.service. > Jan 10 11:46:59 tpt590 systemd[2552]: Started test2.service. > > If I stop test1.service teset2 is stopped, too. > > systemctl --user stop test1 > > Jan 10 11:47:49 tpt590 systemd[2552]: Stopping test2.service... > Jan 10 11:47:49 tpt590 systemd[2552]: Stopped test2.service. > Jan 10 11:47:49 tpt590 systemd[2552]: Stopping test1.service... > Jan 10 11:47:49 tpt590 systemd[2552]: Stopped test1.service. > > Then I start test1.service again > > systemctl --user start test1 > > Jan 10 11:48:42 tpt590 systemd[2552]: Started test1.service. > > What I do not understand is, why `test2.service` is not started again. Because nothing tells systemd to start test2.service when test1.service is (requested to be) started. > Or how can I ensure test2 is started again? > Using Wants=test2.service in test1.service should work. > * test2 requires / binds to test1 > * test2 has been started explicit > * test1 is started as a dependency > * the dependency test1 is stopped explicit > * I would assume the service manager still is aware of the explicit start of > test2 but stopped it because the requirements / dependencies does not met. > * I would assume if test1 (the missing requirement / dependency) is started > again the service manager realize that now all dependencies are met and test2 > can be started again, too. > > Why is this wrong? > How can I declare test2 unit section to ensure it works as expected by me? > > Many thanks in advance, > Markus
Re: [systemd-devel] service dependencies
On Tue, Jan 10, 2023, at 06:47, Markus Rathgeb wrote: > > How can I declare test2 unit section to ensure it works as expected by me? > There are lots of StackOverflow posts about this... it's not as easy as it seems, so don't feel concerned that your attempt did not work :-) If you are using a new enough version of systemd, the 'Upholds' and 'PropagatesStopTo' settings for test1, referring to test2, will do what you want. When test1 is running, systemd will ensure that test2 is running as well (and will stop test1 is test2 cannot be started), and if test1 is stopped (for any reason) systemd will stop test2 as well. test2 will still need Requisite and After settings referring to test1.
[systemd-devel] service dependencies
Hello, I have a question about service dependencies. Assume there are two services * test1 * test2 (for testing purpose only I am using user services) The test2 service requires that test1 service is active. The test2 service cannot work if test1 is not active, so it should ensure * test1 is started before test2 * test2 is terminated if test1 terminates I tried this unit section for test2.service BindsTo=test1.service After=test1.service (The point I do not understand is equal for `Requires` instead of `BindsTo`) If I start test2.service test1 is started and afterwards test2. systemctl --user start test2 Jan 10 11:46:59 tpt590 systemd[2552]: Started test1.service. Jan 10 11:46:59 tpt590 systemd[2552]: Started test2.service. If I stop test1.service teset2 is stopped, too. systemctl --user stop test1 Jan 10 11:47:49 tpt590 systemd[2552]: Stopping test2.service... Jan 10 11:47:49 tpt590 systemd[2552]: Stopped test2.service. Jan 10 11:47:49 tpt590 systemd[2552]: Stopping test1.service... Jan 10 11:47:49 tpt590 systemd[2552]: Stopped test1.service. Then I start test1.service again systemctl --user start test1 Jan 10 11:48:42 tpt590 systemd[2552]: Started test1.service. What I do not understand is, why `test2.service` is not started again. Or how can I ensure test2 is started again? * test2 requires / binds to test1 * test2 has been started explicit * test1 is started as a dependency * the dependency test1 is stopped explicit * I would assume the service manager still is aware of the explicit start of test2 but stopped it because the requirements / dependencies does not met. * I would assume if test1 (the missing requirement / dependency) is started again the service manager realize that now all dependencies are met and test2 can be started again, too. Why is this wrong? How can I declare test2 unit section to ensure it works as expected by me? Many thanks in advance, Markus
Re: [systemd-devel] Container restart issue: Failed to attach 1 to compat systemd cgroup
On Mo, 09.01.23 19:45, Lewis Gaul (lewis.g...@gmail.com) wrote: > Hi all, > > I've come across an issue when restarting a systemd container, which I'm > seeing on a CentOS 8.2 VM but not able to reproduce on an Ubuntu 20.04 VM > (both cgroups v1). selinux? Lennart -- Lennart Poettering, Berlin
