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

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

bq. 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.

Got it. Makes sense the way you have it.

bq. 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.

Got it. Thanks for the explanation.
                
> 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


Reply via email to