Comment # 12 on bug 1202821 from
(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.


You are receiving this mail because: