http://bugzilla.opensuse.org/show_bug.cgi?id=1183247 http://bugzilla.opensuse.org/show_bug.cgi?id=1183247#c43 --- Comment #43 from Eric van Blokland <ericvanblokland@gmail.com> --- In that case it is up to you (In reply to James Fehlig from comment #42)
(In reply to Eric van Blokland from comment #41)
Since my patch broke cgroups, it was reverted. On the mailinglist three possible fixes/workarounds were mentioned but upstream does not seem to care. I would like to see this fixed though. I would like to know which fix would be acceptable by the OpenSUSE maintainers, so I can implement that.
1. Skip obtaining the machine unit name during container startup 2. Let systemd launch the lxc controller process as a transient unit 3. Add a dummy controller to force some v2 logic
I'd be receptive to any fix that is isolated to the lxc driver. I'm less fond of a fix that touches common code, which could also affect the qemu driver.
In that case it's a trade off between maintainability and reliability. In lxc_process.c there are two calls that cause issues: virLXCDomainGetMachineName lxc_process.c:1465 virCgroupNewDetectMachine lxc_process.c:1473 The purpose of these calls is to abort the container initialization in an early stage if something goes wrong. More specifically, if issues occurred with machined registration and cgroup creation. Option 1: For easy maintenance I could make a condition to only call these when the cgroup v2 backend is available or when there is no systemd at the cost of some reliability. Option 2: Alter the signature of virCgroupNewDetectMachine to have a flag to optionally check the unit name. When called from lxc_process.c we pass the flag to not check the unit name when the cgroup v2 backend is not available and systemd is present. This way we keep some reliability at the cost of (probably) more maintenance. Option 3: Implement a function with the relevant parts of virCgroupNewDetectMachine directly in lxc_process.c as a fallback for when the cgroup v2 backend is not available and systemd is present. Some reliability, more maintenance. In my opinion option 1 is sufficient. Let me know if one of these solutions would be acceptable. -- You are receiving this mail because: You are on the CC list for the bug.