I have found that when running into an out-of-memory OOM situation, my linux box UI freezes completely for a very long time.
I have setup the magic-sysrq-key then using
echo 1 | tee /proc/sys/kernel/sysrq and encountering a OOM->UI-unresponsive situation was able to press
Alt-Sysrq-f which as
dmesg log showed causes the OOM to terminate/kill a process and by this resolve the OOM situation.
My question is now. Why does linux become unresponsive as much as the GUI froze, however did seem not to trigger the same OOM-Killer, which I did trigger manually via
Alt-Sysrq-f key combination?
Considering that in the OOM "frozen" situation the system is so unresponsive as to not even allow a timely (< 10sec) response to hitting the
Ctrl-Alt-F3(switch to tty3), I would have to assume the kernel must be aware its unresponsiveness, but still did not by itself invoke the
Alt-Sysrq-f OOM-Killer , why?
These are some settings that might have an impact on the described behaviour.
$> mount | grep memory cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) $> cat /sys/fs/cgroup/memory/memory.oom_control oom_kill_disable 0 under_oom 0 oom_kill 0
which while as I understand states that the memory cgroup does not have OOM neithe activated nor disabled (evidently there must be a good reason to have the OOM_kill active and disabled, or maybe I cannot interpret correctly the output, also the
under_oom 0 is somewhat unclear, still)