On 25/12/17 23:09, Ben Hutchings wrote:
> On Sat, 2017-12-23 at 12:42 +, Chris Boot wrote:
>> Severity: serious
>> Justification: kernel panic
>>
>> I experimented a little and disabled cgroupv2 on that server. Because I
>> had some issues during boot I attempted to enable
>> NetworkManager-wait-online.service using systemd, but that instantly
>> resulted in the following kernel panic:
> [...]
>> I don't know that this is the same bug at all, but I'm keeping it on
>> this report for now as it seems at least related somehow.
>
> The log messages don't look even slightly related, so please move this
> to a separate bug report.
I'm still not so certain - both sets of stack dumps fall somewhere
within cgroup space, and disabling systemd's cgroup accounting (not
enabled by default) avoids these conditions.
I like to run this system with the following all enabled in
/etc/systemd/system.conf:
DefaultCPUAccounting=yes
DefaultIOAccounting=yes
DefaultBlockIOAccounting=yes
DefaultMemoryAccounting=yes
These are useful for tools like systemd-cgtop for example.
With cgroupv2, I can avoid the error by disabling
DefaultMemoryAccounting. I was running for nearly 48 hours with this
configuration before rebooting to try without cgroupv2.
Without cgroupv2, it's DefaultCPUAccounting I need to disable to avoid
the panics when I run 'systemd daemon-reload'. I have yet to run into
the warning or OOM killer with memory accounting enabled but I'll let
you know if it happens.
What makes me suspicious that these are related is that neither happens
with a 4.13 kernel, but I get both of these cgroup-related problems with
4.14.
I wouldn't mind trying to bisect this, but I haven't done that for many
years. Is there a nice way to do this with the Debian packaging or am I
better off seeing if I can reproduce with vanilla upstream kernels and
bisecting that? Or shall I give 4.15~rc5 from experimental a whirl instead?
Thanks,
Chris
--
Chris Boot
bo...@debian.org
