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 <[email protected]> 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
> [email protected]
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
