Skip to main content

is_oom_kill_of_command

start_command::exit_reason

Function is_oom_kill_of_command 

Source 
pub fn is_oom_kill_of_command(
    exit_code: Option<i32>,
    oom_killed: Option<bool>,
    oom_kills: Option<u64>,
) -> bool
Expand description

Can a container-wide OOM observation be blamed on the command itself?

Docker’s State.OOMKilled and the cgroup oom_kill counter are container-wide and sticky (moby/moby#43564): they turn on as soon as any process in the container is OOM-killed, e.g. one rustc child under cargo test, while the command keeps running and later exits on its own (issue #180). The OOM killer always sends SIGKILL, so the observation only explains the command’s exit when that exit is 137 (128 + SIGKILL) or there is no usable exit code at all (none, or the -1 of an unknown exit). This is the rule is_killed_exit already applies to --on-kill-resume (#178).