<div dir="ltr">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).<div><br><div><div><font face="monospace">[root@localhost ~]# podman run -it --name ubuntu --privileged --cgroupns private ubuntu-systemd<br>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)<br>Detected virtualization podman.<br>Detected architecture x86-64.<br><br>Welcome to Ubuntu 20.04.5 LTS!<br><br>Set hostname to <daca3bb894b7>.<br><b>Couldn't move remaining userspace processes, ignoring: Input/output error<br>Failed to create compat systemd cgroup /system.slice: No such file or directory<br>Failed to create compat systemd cgroup /system.slice/system-getty.slice: No such file or directory</b><br>[  OK  ] Created slice system-getty.slice.<br><b>Failed to create compat systemd cgroup /system.slice/system-modprobe.slice: No such file or directory<br></b>[  OK  ] Created slice system-modprobe.slice.<br><b>Failed to create compat systemd cgroup /user.slice: No such file or directory<br></b>[  OK  ] Created slice User and Session Slice.<br>[  OK  ] Started Dispatch Password Requests to Console Directory Watch.<br>[  OK  ] Started Forward Password Requests to Wall Directory Watch.</font><br></div></div></div><div><br></div><div>This first warning is coming from one of the same areas of code I linked in my first email: <a href="https://github.com/systemd/systemd/blob/v245/src/core/cgroup.c#L2967">https://github.com/systemd/systemd/blob/v245/src/core/cgroup.c#L2967</a>.</div><div><br></div><div>I see the same thing with '--cap-add sys_admin' instead of '--privileged', and again seen with both docker and podman.</div><div><br></div><div>Thanks,</div><div>Lewis</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 10 Jan 2023 at 15:28, Lewis Gaul <<a href="mailto:lewis.gaul@gmail.com">lewis.gaul@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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).<br></div><div><br></div><div>On first boot PID 1 can be found in /sys/fs/cgroup/systemd/machine.slice/libpod-<ctr-id>.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-<ctr-id>.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?</div><div><br></div><div>I can confirm that the container has permissions since executing a 'mkdir' in /sys/fs/cgroup/systemd/machine.slice/libpod-<ctr-id>.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?</div><div><br></div><div>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".</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Lewis</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 10 Jan 2023 at 14:48, Lennart Poettering <<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Di, 10.01.23 13:18, Lewis Gaul (<a href="mailto:lewis.gaul@gmail.com" target="_blank">lewis.gaul@gmail.com</a>) wrote:<br>
<br>
> Following 'setenforce 0' I still see the same issue (I was also suspecting<br>
> SELinux!).<br>
><br>
> A few additional data points:<br>
> - this was not seen when using systemd v230 inside the container<br>
> - this is also seen on CentOS 8.4<br>
> - this is seen under docker even if the container's cgroup driver is<br>
> changed from 'cgroupfs' to 'systemd'<br>
<br>
docker is garbage. They are hostile towards running systemd inside<br>
containers.<br>
<br>
podman upstream is a lot friendly, and apparently what everyone in OCI<br>
is going towards these days.<br>
<br>
I have not much experience with podman though, and in particular not<br>
old versions. Next step would probably be to look at what precisely<br>
causes the permission issue, via strace.<br>
<br>
but did you make sure your container actually gets write access to the<br>
cgroup trees?<br>
<br>
anyway, i'd recommend asking the podman community for help about this.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div>
</blockquote></div>