[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Catching kill due to oom



Hey Andrew,  It is true that we don't generate a pod level event when
a container in the pod is OOM killed.   There is a container status in
the pod status that indicates with OOM with status.state.reason set to
OOMKilled.

status:
...
  containerStatuses:
  - containerID:
docker://f2389dccd11a6575aeccbc12d360bc02eb0d2cf67c0f8d439fda57637e916628
...
    state:
      terminated:
        containerID:
docker://f2389dccd11a6575aeccbc12d360bc02eb0d2cf67c0f8d439fda57637e916628
        exitCode: 1
        finishedAt: 2017-07-03T15:08:40Z
        reason: OOMKilled
        startedAt: 2017-07-03T15:08:40Z

Since builds have a restartPolicy: Never, the status isn't changed on
a restart, and you can see this in on the Pods tab in the Status
column in the web console.

Thanks,
Seth





On Sun, Jul 2, 2017 at 7:23 PM, Andrew Lau <andrew andrewklau com> wrote:
> Hi,
>
> I'm often seeing issues where builds are getting killed due to oom. I'm
> hoping to get some ideas on ways we could perhaps catch the OOM for the
> purpose of displaying some sort of useful message.
>
> Based on what I am seeing, a SIGKILL is being sent to the container, so it's
> not possible to catch anything like a SIGTERM from within the container to
> at least display an error message in the logs. Users are often left confused
> wondering why their build suddenly died.
>
> It's also not currently possible to configure the memory limit for the
> buildconfig in the web console.
>
> _______________________________________________
> users mailing list
> users lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]