https://bugzilla.suse.com/show_bug.cgi?id=1202821 https://bugzilla.suse.com/show_bug.cgi?id=1202821#c1 Michal Koutn� <mkoutny@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mkoutny@suse.com) | --- Comment #1 from Michal Koutn� <mkoutny@suse.com> --- (In reply to Fabian Vogt from comment #0)
On openqaworker1, there are four (pretty much identical) containers set up as services which run openQA tests.
What does it mean containers as services? (I assume it's from project [1], right?) Q1) Is there difference how the containers are started among the four? (I.e. from user session vs from a systemd service.)
Sometimes a container has a different issue regarding cgroups, where it looks like the assigned cgroup somehow disappeared.
What do you mean here? Is it the system.slice vs machine.slice discrepancy? Or anything else?
openqaworker1:~ # podman exec -i openqaworker1_container_102 su -P su: failed to create pseudo-terminal: Operation not permitted
This looks suspiciously similar to the bug 1178775, if it weren't Leap 15.4 with systemd v249 (where this should be fixed).
openqaworker1:~ # podman exec -i openqaworker1_container_103 su -P Error: exec failed: unable to start container process: error adding pid 10265 to cgroups: failed to write 10265: openat2
If it was process 10625 terminated earlier than it could have been migrated to scope cgroup, we'd get ESRCH. This is ENOENT, so the cgroup doesn't exist. So the *c1c0.scope doesn't exist from systemd's PoV.
It's visible that in the case of container 102, the device cgroup entries "b *:* m" and "c *:* m" got removed somehow and for container 103, the cgroup changed completely (system.slice/*.service instead of machine.slice/libpod-*).
Q2) What cgroup "driver" does podman use for these containers? (cgroupManager in podman lingo, cgroupfs vs systemd.)
bug 1178775 sounds similar. I guess systemd is somehow interfering with podman?
Or podman is interfering with systemd. :-) 1) Q3) Would it be too bold to ask to switch the host to the unified mode (system.cgroup_unified_hierarchy=1 to kernel cmdline)? (Issues with device controller and maintaining parallel hierarchies with systemd (and container runtime) would likely be gone with just the unified hierarchy.) [1] https://github.com/openSUSE/containers-systemd. -- You are receiving this mail because: You are on the CC list for the bug.