Thanks for your response steve, I was thinking that SliderAgent would receive 'stop' command from SliderAM to kill the components spawned by those agents. And yeah this might be specific to debian installation as others in the group are not facing this issue.
On Tue, May 12, 2015 at 1:50 PM, Steve Loughran <[email protected]> wrote: > > > On 12 May 2015, at 08:42, Chackravarthy Esakkimuthu < > [email protected]> wrote: > > > > Starting a new thread, > > > > already JIRA filed for the same by Gour, > > https://issues.apache.org/jira/browse/YARN-3561 > > > > Slider stop does not stop the components started by slider, instead it > > stops only SliderAM, and even SliderAgents did not receive 'stop' > command. > > (it happens with debian 7) and tested with 0.70.1 as well as 'develop' > > branch code. > > > > Today I just came across the following mail archive, > > > > > http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201503.mbox/%[email protected]%3E > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > *What is not implemented is an explicit call to "stop function in the > > python scripts". > > > > What I was referring to that an attempt is made by the Agent to call > > stop in the python script > > but it is not guaranteed. The reason it is not guaranteed is that the > > call to stop() and kill > > of the containers by YARN is not co-ordinated. > > > > In summary, the ability to call stop() functions in the python script > > is not implemented. > > Its in the plan though.* > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > Does this still exists? > > > the idea of stop|() command is to actually offer a best-effort clean > shutdown for containers. Currently the AM just directly tells YARN to > destroy a container. The agent doesn't get told, nor does the application > (that's implicit from the agent). > > YARN is expected to "kill" then, if there is no response, "kill -9" the > agent process. Which it does for the hosts we test on, linux, OSX and > windows. > > IF something is up with your YARN+debian installation, we believe that it > is related to whether those container kill events are coming out from the > node manager. >
