hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8353) hadoop-daemon.sh and yarn-daemon.sh can be misleading on stop
Date Wed, 09 May 2012 21:53:48 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271851#comment-13271851
] 

Aaron T. Myers commented on HADOOP-8353:
----------------------------------------

Patch looks pretty good to me. A few questions:

# Perhaps we should make the message more verbose in the event we fall back to `kill -9' ?
I'm thinking something along the lines of "Daemon did not stop gracefully after signaling
it X seconds ago. Trying `kill -9 $TARGET_PID'"
# Does it definitely make sense to call the env var "YARN_STOP_TIMEOUT" in the MR job history
server? Should it not be "MR_STOP_TIMEOUT" ?
# Do similar changes not need to be made for the HDFS daemons?
                
> hadoop-daemon.sh and yarn-daemon.sh can be misleading on stop
> -------------------------------------------------------------
>
>                 Key: HADOOP-8353
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8353
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: scripts
>    Affects Versions: 0.23.1
>            Reporter: Roman Shaposhnik
>            Assignee: Roman Shaposhnik
>             Fix For: 2.0.0
>
>         Attachments: HADOOP-8353.patch.txt
>
>
> The way that stop actions is implemented is a simple SIGTERM sent to the JVM. There's
a time delay between when the action is called and when the process actually exists. This
can be misleading to the callers of the *-daemon.sh scripts since they expect stop action
to return when process is actually stopped.
> I suggest we augment the stop action with a time-delay check for the process status and
a SIGKILL once the delay has expired.
> I understand that sending SIGKILL is a measure of last resort and is generally frowned
upon among init.d script writers, but the excuse we have for Hadoop is that it is engineered
to be a fault tolerant system and thus there's not danger of putting system into an incontinent
state by a violent SIGKILL. Of course, the time delay will be long enough to make SIGKILL
event a rare condition.
> Finally, there's always an option of an exponential back-off type of solution if we decide
that SIGKILL timeout is short.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message