hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roman Shaposhnik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8353) hadoop-daemon.sh and yarn-daemon.sh can be misleading on stop
Date Thu, 10 May 2012 16:06:52 GMT

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

Roman Shaposhnik commented on HADOOP-8353:


bq. Perhaps we should make the message more verbose 

Agreed. I'll modify the patch to make it more obvious

bq. "YARN_STOP_TIMEOUT" in the MR job history serve

The unfortunate truth there is that *everything* else in that script has a YARN_ prefix (I
suspect because it was copied from the yarn-daemon.sh). I'd rather keep things consistent,
but if you really think this lonely var should be MR_ prefixed -- please let me know.

bq. Do similar changes not need to be made for the HDFS daemons?

HDFS daemons use hadoop-daemon.sh In fact at this point it can be safely called hdfs-daemon.sh
since I don't think anything else is really using it.
> 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


View raw message