hadoop 关闭进程时报错no 进程
- ITeye博客
博客分类：
原创，转载请注明出处
& 前两天和朋友李天王吃饭的时候，聊到了一个hadoop的运维的很简单问题，感觉很有意思，以前也没有注意过，现在加以重现和整理。
& 感谢李天王的分享。。。。
& 翻看了yarn-deamon.sh stop部分的脚本：
if [ -f $pid ]; then
TARGET_PID=`cat $pid`
if kill -0 $TARGET_PID & /dev/null 2&&1; then
echo stopping $command
kill $TARGET_PID
sleep $YARN_STOP_TIMEOUT
if kill -0 $TARGET_PID & /dev/null 2&&1; then
echo "$command did not stop gracefully after $YARN_STOP_TIMEOUT seconds: killing with kill -9"
kill -9 $TARGET_PID
echo no $command to stop
echo no $command to stop
根据上面代码。在关闭hadoop的进程的时候，会首先TARGET_PID=`cat $pid`，后面的操作都
针对这个TARGET_PID。
首先发送kill -0 TARGET_PID来检测这个pid存在不存在，若存在那么就使用kill& TARGET_PID 来关闭进程。
第二个 kill -0 $TARGET_PID，意思是第一次删除失败的时候，则执行kill -9 $TARGET_PID。
&
& 在默认情况下，hadoop会使用/tmp目录作为临时文件存放地点，包括pid的文件：
[hadoop@hadoop2 hadoop]$ cat
Jetty_0_0_0_0_50075_datanode____hwtdwq/ orbit-gdm/
Jetty_0_0_0_0_8042_node____19tj0x/
pulse-oVhJlALLtsum/
[color=red]hadoop-hadoop-datanode.pid
Jetty_0_0_0_0_8480_journal____.8g4awa/
pulse-rZOxQTGmpouA/
[color=red]hadoop-hadoop-journalnode.pid[/color]
Jetty_hadoop2_50070_hdfs____.roo38u/
pulse-v2bO3KgmFqB6/
[color=red]hadoop-hadoop-namenode.pid [/color]
Jetty_hadoop2_8088_cluster____2k46ah/
ssh-ZAuFHp2599/
hadoop-hadoop-zkfc.pid
keyring-5PcL7q/
hsperfdata_hadoop/
keyring-DGU27L/
.X11-unix/
.ICE-unix/
keyring-prSBtx/
[color=red][color=orange]yarn-hadoop-nodemanager.pid[/color][/color]
Jetty_0_0_0_0_50070_hdfs____w2cu08/
keyring-wrTBmk/
[color=darkred]yarn-hadoop-resourcemanager.pid[/color]
& 由于/tmp会定期清除（以前认为只有在重启的时候，tmp才会清除，后来李天王提到由于tmpwatch的作用，会定期每隔240小时删除tmp的内容），会将pid清除，pid不存在的时候，就会报no *** to stop
[hadoop@hadoop2 hadoop]$ cat
/tmp/yarn-hadoop-resourcemanager.pid
[hadoop@hadoop2 hadoop]$ rm /tmp/yarn-hadoop-resourcemanager.pid
[hadoop@hadoop2 hadoop]$ yarn-daemon.sh
stop resourcemanager
no resourcemanager to stop
那么此时该怎么做呢，我之前的做法就是很粗暴的kill -9 pid关闭进程，幸亏由于hadoop的editlog日志机制，保证了数据不会丢失，若是其他。。。
& 学习一下脚本，可以看出hadoop在关闭进程的时候是采取了比较保险妥当的方式。首先使用kill 而不是使用kill -9 来关闭进程。
& 另外朋友们在平时运维的时候要首先使用kill TARGET_PID。kill -9的这种比较粗暴的方式，还是少用，之前使用在hadoop 升级实验的时候，在hdfs namenode -upgrade 之后，就直接使用kill -9 pid，居然java 虚拟机抛出了致命错误。
& 虚拟机日志我作为附件放上去，希望有虚拟机方面的大牛能给我分析。。。
总结：1.修改你的hadoop的hdfs以及yarn的tmp目录，都要修改哦。
& 2.关闭hadoop的时候请尽量使用kill 。
下载次数: 14
浏览: 177913 次
来自: 苏州
引用引用[u][i][b][b][u]引用[list]
这两天又用了Jmeter，发送json，发现中文乱，也设置了c ...
就这样啦？没有教人怎么看执行计划啊。。。。
成功了，不过如果能在zkEnv.sh最前边加一句ZOO_LOG ...
wo bu zhuan zai赞助商链接
这是来自Dave Banister的博文Blog，将反对NodeJS在企业中应用的陈旧观点逐一批驳，这篇文章主要是针对微软阵营的程序员。摘要如下，原文请点按标题：1995年大约有40万人在互联网上，但到2011年有近45亿。电脑已经变得如此之快，我的手机比我的第一个网站服务器有更强的处理能力。互联网连接提高了这么多，购买任何媒体的拷贝(如电影光盘)似乎比较愚蠢。 Web服务现在已经是一个商业化网站必要的功能。弹性计算使得扩展缩放变得如此精妙。随着这些变化，网络的发展已经转移。每次技术换挡，基础客户端技术必须适应，而我们现在正处于这样一个换档节点，这迫使大多数应用程序的功能转移到浏览器中，这不是可能不可能的问题，如果你想跟上竞争，应该认为这是必要的。在JavaScript过去的二十年中，JS框架、工具和模式不断在进化和发展。JavaScript从一个只有必要时才使用的可以被亵渎的语言已经演变到Web开发中的一个完全充满活力的一等公民。随着Node.js近年来的兴起，在服务器端使用JavaScript似乎是一个很大的阻力，甚至更多的阻力来自Node.js自身。在我看来，这种阻力是基于不同程度的误解，很多都是一些古老的观点。在这篇文章中，我打算展示所有的反对在企业中使用Node.js的主要论点。我不是一个JavaScript开发。我是一名软件开发人员。 JavaScript不是我所选择的语言，我在合适的地方会使用它，就像所有其他的语言一样。我完全熟悉主流的SQL，当我编写C/ C + +代码的时候。net走入了我的世界，我甚至使用一些内联汇编，使用新的CPU指令只是为了好玩。我已经涉足ObjectC和Java原生移动应用程序，我想我可能是享受喜欢编写正则表达式唯一的人。重要的是要明白，我不是一些JavaScript传道者那样挂羊头卖狗肉。我只是基于近20年的开发经验看到Node.JS在构建Web应用程序上的价值。误解：为什么我们要使用其他服务器？首先， Node.js不是一个服务器。这是一个阻止在在企业中应用的根本误解。我用Node.js的每一天中，我很少将它作为一个服务器使用。没有JavaScript的提示prompt是无法运行NodeJS的，该提示prompt可以基于另一个shell的系统上。 将Node.js作为外壳shell，shell脚本其实提供了Node.js究竟是什么的更好的解释。我觉得Node.js的脚本更象bash或PowerShell脚本。如果使用这些脚本启动起来一个Web服务器，那么这个脚本就是一个Web服务器。我们将NodeJS看成脚本而不是服务器有不少优点。是什么让Node.js成为比其他的shell更好的替代？是NPM。NPM包管理器可以让我在拉包，几乎无所不能。这些模块包括数据访问库，编译器，服务器，以及其他一切。其次， Node.js并不仅限于HTTP / S 它有TCP和UDP支持。人们已经建立了如DNS和SMTP服务器等一些疯狂的事情。这很重要，因为我不再去关心任何人在使用IIS实施DNS服务器。只有这种级别的灵活性才能创造这么多的选择，这是当前其他企业服务器的选择无法比拟的。第三， 带有IS插件Node.js是一个平台。开箱即用， Node.js包含HTTP监听者 ，但它不包含一个真正的服务器。这让开发人员编写自己的服务器，或者使用NPM来拉一把。在Node.js上一切工作方式相同。 Node.js所提供的简约API提供了构建几乎任何东西的工具。在巨大的包库中提供了几乎所有的东西的实现。误解：JS真的不像一个真正语言avaScript已经长大了。在ECMA 6规范包括类，接口，和所有通常流行的面向对象语言相关的好东西。这些功能虽然是未来，但在此期间，TypeScript 已经提供了这些功能在编译时的检查。即使没有这些功能， JavaScript开发人员都使用原型继承。 JavaScript支持单元测试，依赖注入，错误处理，以及所有的其他企业真正关心的功能。....误解：JS不能进行编译检查JavaScript并没有一个编译器，所有不会进行错误检查，但是静态代码分析和单元测试是验证你的代码更好的手段((banq注：IDE等提供了静态代码分析，如)。)静态代码分析应该弥补JavaScript基于语法编译时的错误；单元测试弥补JavaScript基于代码中的错误测试。如果你认为编译器输出仍然是重要的，TypeScript的编译器应该给你这些需求。误解：NodeJS是单线程Node.js使用C编写的libuv为I/O管理自己的线程，包括网络 文件系统等，libuv 必要时会为I/O创建一个线程池，V*事件循环是另外一个单独的线程，专门处于队列中事件，这些事件数据映射到JS的可执行函数，这就是Node.JS的异步I/O原理。这个对于每个处理进程的单个V8事件循环，意味着Node.JS提供一个集群的API，允许主Node.js进程生成子进程，这个集群API也能用于跨进程通讯，每个进程都接受它自己的 V8事件循环，也就是拥有自己的javaScript线程，这就是传统多线程能够在Node.JS中实现原理。Node.js有可扩展模块可以实现本地原生代码。原生代码可以生成线程。已经有模块提供产生的后台和工作线程。现在一个现代Web应用程序中，大多数的正常请求的时间都花在等待一个数据库调用、REST API请求或文件操作的完成。异步I / O采用通过发出一个外部呼叫的不同方法，当调用完成，它就会被扔进事件循环。主线程就不会处于永远等待。传统的多线程技术有额外消耗，比如内存或上下文切换等。异步I / O的方式是如此引人注目，异步和等待的关键字将被引入到C＃ NET 4.5，异步控制器将引入在ASP.NET MVC 4中。这里是Uber从传统的LAMP堆栈切换到Node.JS的，能看跨多核扩展集群，也能够通过基于云的弹性计算扩展。完，其他一些不重要的误解可参考原文。
赞助商链接
赞助商链接
最佳分辨率
OpenSource
Code & 2002-20Node.js中防止错误导致的进程阻塞的方法
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了Node.js中防止错误导致的进程阻塞的方法，非常不错，具有参考借鉴价值，需要的朋友可以参考下
在Node.js中，当某个回调函数发生了错误，整个进程都会崩溃，影响后面的代码执行。
Node.js这样处理，是因为在发生未被捕获的错误时，进程的状态就不确定。之后也就无法正常工作了。如果错误始终不处理的话，就回一直抛出意料之外的错误，这样不利于调试。
防止错误导致的进程阻塞的方法主要有如下两种：
一. try-catch
try-catch允许进行异常捕获，并让代码继续执行下去：
当函数抛出错误时，代码就停止执行了：
(function() {
var a = 0;
console.log("get here."); // 不执行
使用try-catch进行错误处理后，代码仍可继续执行：
(function() {
var a = 0;
} catch (e) {
console.log(e);
console.log("get here."); // get here.
try-catch不能捕获未来执行函数错误
要捕获未来才执行到的函数所抛出的错误时不可能的。这会直接抛出未捕获的异常，并且catch代码块永远都不会被执行：
setTimeout(function() {
throw new Error("here");
} catch(e) {
console.log(e);
这就是为什么在Node.js中，每步豆芽正确进行错误处理的原因。
添加uncatchException处理器
若添加了 uncatchException 处理器，当函数抛出错误时，进程也不会退出。
process.on("uncatchException", function(e) {
console.log(e);
process.exit(1);
以上所述是小编给大家介绍的Node.js中防止错误导致的进程阻塞的方法，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持！
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具node发生错误后会自动退出,如何让他不退出呢
node发生错误后会自动退出.当然如果写好了代码就不会发生了,但是如果发生,如何让他一直不退出,除非你手动.
http://www.oschina.net/question/960
这里有比较详细的回答。请采纳～。
引用来自“kakakakaka”的评论 http://www.oschina.net/question/960
这里有比较详细的回答。请采纳～。 ok