<div dir="ltr">Hey Michal,<div><br></div><div>Thanks for the reply.</div><div><br></div><div>> I'd suggest looking at debug level logs from the hosts systemd around the time of the container restart.<span style="color:rgb(80,0,80)"><br></span></div><div><br></div><div>Could you suggest commands to run to do this?</div><div><br></div><div>> What is the host's systemd version and cgroup mode (legacy,hybrid,unified)? (I'm not sure what the distros in your original message referred to.)</div><div><br></div><div>The issue has been seen on Centos 8.2 and 8.4 host distro, but not seen on Ubuntu 20.04. The former has systemd v239 and appears to be in 'legacy' cgroup mode (no /sys/fs/cgroup/unified cgroup2 mount), whereas the latter has systemd v245 and is in what I believe you'd refer to as 'hybrid' mode (with the /sys/fs/cgroup/unified cgroup2 mount).</div><div><br></div><div>Should we be suspicious of the host systemd version and/or the fact that the host is in 'legacy' mode while the container (based on the systemd version being higher) is in 'hybrid' mode? Maybe we should try telling the container systemd to run in 'legacy' mode somehow?</div><div><br></div><div>Thanks,</div><div>Lewis</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 12 Jan 2023 at 13:12, Michal Koutný <<a href="mailto:mkoutny@suse.com" target="_blank">mkoutny@suse.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">Hello.<br>
<br>
On Tue, Jan 10, 2023 at 03:28:04PM +0000, Lewis Gaul <<a href="mailto:lewis.gaul@gmail.com" target="_blank">lewis.gaul@gmail.com</a>> wrote:<br>
> I can confirm that the container has permissions since executing a 'mkdir'<br>
> in /sys/fs/cgroup/systemd/machine.slice/libpod-<ctr-id>.scope/ inside the<br>
> container succeeds after the restart, so I have no idea why systemd is not<br>
> creating the 'init.scope/' dir.<br>
<br>
It looks like it could also be a race/deferred impact from host's systemd.<br>
<br>
> I notice that inside the container's systemd cgroup mount<br>
> 'system.slice/' does exist, but 'user.slice/' also does not (both<br>
> exist on normal boot). Is there any way I can find systemd logs that<br>
> might indicate why the cgroup dir creation is failing?<br>
<br>
I'd suggest looking at debug level logs from the hosts systemd around<br>
the time of the container restart.<br>
<br>
<br>
> I could raise this with the podman team, but it seems more in the systemd<br>
> area given it's a systemd warning and I would expect systemd to be creating<br>
> this cgroup dir?<br>
<br>
What is the host's systemd version and cgroup mode<br>
(legacy,hybrid,unified)? (I'm not sure what the distros in your original<br>
message referred to.)<br>
<br>
<br>
Thanks,<br>
Michal<br>
</blockquote></div>