(In reply to Dennis Glindhart from comment #6) > I had a similar problem with podman containers started via systemd-services > after installation of some newer version of systemd (in Tumbleweed). > > I found I could reproduce the problem executing *systemctl daemon-reload* - > after which the problem would occur. I guess some cgroups where bound to the > systemd daemon somehow. > > Can that help getting a reliable reproduce? Yep, even with unified cgroups v2! openqaworker1:~ # podman exec -i openqaworker1_container_102 su -P openqaworker1_container:/ # exit openqaworker1:~ # systemctl daemon-reload openqaworker1:~ # podman exec -i openqaworker1_container_102 su -P su: failed to create pseudo-terminal: Operation not permitted openqaworker1:~ # (In reply to Michal Koutn��� from comment #7) > (In reply to Fabian Vogt from comment #4) > > Should we focus on that or testing with cgroups v2? > > v2 should be a workaround if you need the worker up 'n running quickly > (hopefully). > > For SP4 when no v2-specific feature [1] is required, we should fix that (as > you wrote). So tracking it down with a reproducer is still helpful. > > [1] FTR, I'd count unprivileged containers among those too (have the source > services User!=root?). Nope, started as root. The process inside the container runs as non-root though.