On 10/28/19 6:41 AM, Maximilian Philipps wrote: > hi, > > I am currently investigating a bug with libvirt lxc. Whenever I do a > systemctl daemon-reload on the host, my container loses his memory limit > and then reports having access to 8 exabyte of memory. > > I have tracked the issue down to two parts: > > memory.limit_in_bytes jumps from the correct value to 9223372036854771712. > > libvirt lxc appears to set the memory limit in transient way without > writing a config for systemd. I can't prevent memory.limit_in_bytes > changing by setting the correct value through systemctl set-property > --runtime <scope> MemoryLimit= > > tasks in the memory cgroup gets cleaned up. > > After starting the container the cgroup contains 3 pid. The pid of the > libvirt_lxc process, the pid of the init process in the container and > third unknown pid that doesn't exists in /proc/. > > After a demon-reload only the init process remains in the cgroup and > unless I move the libvirt_lxc process into the cgroup the memory limit > isn't enforced. > > I have also noticed that when starting libvirtd it complains about > GetMachineByPID failing for the libvirt_lxc process. > > > This leaves me with one big question, the the emulator process > libvirt_lxc supposed to be part of the container's cgroup or not? The > leader of the container is the init process in the container. I am > unsure on how the additional emulator process is supposed to be registered. > CCing danpb who likely knows best You may want to give latest libvirt a shot though, there was a lot of cgroup changes since 5.0.0 release. It may actually make things worse with lxc driver though, but it will be another data point at least - Cole _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
