-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pod hangs when container in ContainerSet is OOM Killed #10063
Comments
Looking at the controller logs, I can see that it detects the container was killed, but the Pod and Workflow remain in the "Running" phase.
(workflow name is different from the example I shared) more relevant log lines
|
This comment was marked as resolved.
This comment was marked as resolved.
This issue is still happening |
@rajaie-sg Do you like to submit PR for this issue? |
Hi @sarabala1979 , it looks like there was a fix for this issue but it was reverted at some point? #8456 (comment) |
This comment was marked as resolved.
This comment was marked as resolved.
This is still an issue (comment to avoid the stale tag) |
I've noticed this same issue on v3.4.7 using the emissary executor |
I think there are two issues;
|
Signed-off-by: Alex Collins <[email protected]>
Signed-off-by: Alex Collins <[email protected]>
…nly (#11757) Signed-off-by: Alex Collins <[email protected]> Signed-off-by: Isitha Subasinghe <[email protected]> Co-authored-by: Alex Collins <[email protected]>
…3.4.11 only (argoproj#11757) Signed-off-by: Alex Collins <[email protected]> Signed-off-by: Isitha Subasinghe <[email protected]> Co-authored-by: Alex Collins <[email protected]> Signed-off-by: Dillen Padhiar <[email protected]>
Pre-requisites
:latest
What happened/what you expected to happen?
I have a containerSet with 2 containers. The first container runs a script that results in it being OOM Killed. I expect the Pod and Workflow to fail at that point, but they just hang in the "Running" state until they reach their timeoutSeconds deadline.
I found this related issue #8680 but I am on 3.4.3 and still running into it.
I am using the emissary executor
Version
v3.4.3
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
The text was updated successfully, but these errors were encountered: