[
https://issues.apache.org/jira/browse/YARN-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458694#comment-16458694
]
Jim Brennan commented on YARN-8206:
-----------------------------------
[~eyang], [~jlowe], I'm not sure I see the advantage of using the docker API
for kill? We have the PID, so just killing it directly seems like the most
efficient method. [~ebadger] filed this issue after we ran into a case where
nodes were running out of memory and started to kill containers to free up
space, but it was taking too long so things just got worse and the linux OOM
kicked in and started killing processes as well. So in these cases where yarn
has decided to kill containers, I think we should make that path as efficient
as possible so we can recover more quickly.
[~eyang], can you clarify what advantage is gained by using docker kill in this
case?
> Sending a kill does not immediately kill docker containers
> ----------------------------------------------------------
>
> Key: YARN-8206
> URL: https://issues.apache.org/jira/browse/YARN-8206
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Eric Badger
> Assignee: Eric Badger
> Priority: Major
>
> {noformat}
> if (ContainerExecutor.Signal.KILL.equals(signal)
> || ContainerExecutor.Signal.TERM.equals(signal)) {
> handleContainerStop(containerId, env);
> {noformat}
> Currently in the code, we are handling both SIGKILL and SIGTERM as equivalent
> for docker containers. However, they should actually be separate. When YARN
> sends a SIGKILL to a process, it means for it to die immediately and not sit
> around waiting for anything. This ensures an immediate reclamation of
> resources. Additionally, if a SIGTERM is sent before the SIGKILL, the task
> might not handle the signal correctly, and will then end up as a failed task
> instead of a killed task. This is especially bad for preemption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
