有些事还是经历过了才知道“小心驶得万年船”的道理啊。最近笔者帮一个客户安装HDP2.6.5版本的大数据平台，最重要的是，这次安装的背景是生产环境的云平台迁移，不是普通的开发阶段或者上线阶段。

刚开始拿到系统，自然一片空白，因此有些掉以轻心了。由于是云平台且是新到位的环境，为了方便安装，便直接开了全部网络访问来安装。经过一两天的折腾(过程自不必详述，不是本文的重点)，终于完成一个master节点、一个standby节点+3个datanode节点的hdp安装。由于经验不足，加上工作疏忽，忘记了提醒客户调整网络策略，于是两天后悲剧就发生了。

最开始出现的症状是，mapreduce任务和hive任务都跑的巨慢，

深入看看，发现有两个问题，1.是yarn的nodemanger起不来，2是yarn资源管理上出现了一些奇怪的进程，如下：

很明显，看到dr.who这么异常的用户，我们马上感觉不对劲，各种百度找原因，最后确认我们中毒了。重点关注到的是下面的文章，但是很遗憾，没用给出对应的解决方案。

网上找了一些资源，一开始就是蒙的，只能求助于云平台。虽然工作很久了，但是以前的Linux环境大多都是内部网络，第一次接触到Linux中毒的情况。结果云平台又是断网查杀，又是重启，可是最终还是没能解决我们的问题，唯一给出的消息就是，经过诊断，三台datanode中毒了，另外两台maser节点没问题。当时距离迁移结束尚有四五天的时间，于是在苦恼两天以后，决定重新安装datanode。云平台给的建议也是重装系统。

经过一番苦战，我们把三台datanode节点下线以后，直接重置系统，全部清空。然后安装ambari-agent，让ambari-server和ambari-agent建立通信，在三个ambari-agent上初始化客户端+datanode+nodemaneger等。初始化完成以后，也遇到一个问题，这里也记录一下。需要执行hdfs hadoop  dfsadmin -safemode leave让集群离开安全模式，然后删除丢失文件的目录。重新安装以后，经过一番折腾，恢复数据和文件，终于把集群又运行起来了。

然而，命运总是喜欢开玩笑。在系统稳定运行一周后，由于云平台管理人员的失误，本应针对应用服务器开放8080端口的需求误操作成对所有云平台开放8080端口，于是已经在生成环境的服务器再次出现故障，nodemanger每次一启动就down掉。联系云厂商，再次杀掉，折腾了一台以后未见任何进展。我们利用周末时间翻遍了百度、谷歌、必应的各种文章以后，仍未找到合理的解决方案。

在周一即将到来、系统即将迎来大面积访问的关头，我们都做好了要再次重装datanode的准备，然而另外一位同事部署的kafka程序及spark程序不愿意再次配合修改，因此我们只能选择再推迟一天重装来解决此问题。

在周日的晚上十一点多，点的外卖到了一个多小时还没吃的时候，我最后一次尝试卸载一个节点的nodemanger然后重装，在启动的时候偶然遇到错误，提示里面有dr.who的错误，让我意识了这么多次nodemanger一启动就down掉并且不报错可能跟这个病毒有关。于是我开始在网上查找相关资料。

最有用的是下面这篇博文，https://www.cnblogs.com/daxiangfei/p/9198856.html，然而内容过于简单，只给了解题思路，没用给解题步骤。

参照本文的说明，我现实在yarn用户的crontab找到系统定时任务，虽然已经注释，但是我还是手动删掉了。

由于定时任务是yarn用户的，根据经验，我就开始查看yarn用户的进程，ps -ef|grep yarn，于是看到了四个很奇怪的进程，很明显，这就是所谓的挖矿程序。二话不说，我就kill掉了四个进程，然后再次启动nodemanger。在启动过程中我还不是查看yarn的用户的进程，想看看是不是有命令会杀掉nodemanger经常。

结果就看到了，挖矿程序是伴随这个nodemanger启动的，这是，我有两个怀疑，第一，这个挖矿程序修改了nodemanger启动脚本，嵌入到了nodemanger启动过程中；第二，nodemanger容器中包含挖矿程序，导致nodemanger一启动就要执行挖矿任务，“不堪重负累死了”。从表面上看第一个推理比较合理，于是我认真查找挖矿进程对应的脚本并且进行各种删除，但是多次重启以后还是存在挖矿程序同步启动的情况。于是只能尝试第二种思路，第二个设想从其它博文中看到一句命令后就验证了。yarn top命令可以查看yarn正在运行的进程。

这样问题请很清晰了，大量的dr.who的挖矿程序在yarn队列中是提交状态，所以nodemanger一启动就需要开始干活，资源不足或者被挖矿程序抢占了CPU资源所以导致nodemanger启动后马上就悄悄的死掉了。认识到来这一点，我开始查询yarn的其他命令行以及怎么杀死这些任务。

在尝试几次批量查杀后发现进程依然没有减少，于是网上百度查找yarn批量查杀进程的方法。

最后终于找到一个非常好用的命令。在我执行的时候，奇迹出现，dr.who的进程在一个一个得减少，慢慢的mapreduce就出现了，再到后来全部是mapreduce任务和hive任务。这个命令真的很神奇，杀了一堆有害进程，但是对合理的进程全部保留。

# 删除处于ACCEPTED状态的任务for i in  `yarn application  -list | grep -w  ACCEPTED | awk '{print $1}' | grep application_`; do yarn  application -kill $i; done

这是我终于看到了曙光。我在保障所有节点的yarn用户crontab里面没用定时任务以后，登录ambari开始启动nodemanger。正当我点开页面的时候，奇迹出现了，所有的nodemanger满血复活。

等我重新提交任务以后，yarn平台也正是恢复正常，tez和mapreduce任务正常执行。

于是，在产生更严重的生产事故之前，hdp平台就这样被我修复了。经过一天的稳定运行，平台也安然无恙。至此，我修复了一次重大的生成事故。

最后补充说一下，可能由于挖矿程序的升级，"检查/tmp和/var/tmp目录，删除java、ppc、w.conf等异常文件"这一条已经完全失效了，找不到任何对应的文件。        总结一下，远程木马通过yarn的8080端口提交了包含挖矿程序的shell脚本任务给yarn执行，yarn执行以后就产生了crontab定时任务和挖矿进程。由于木马一次性提交了大量(大概一两百个)的相同任务给yarn，所以杀死一两个并不能解决问题，只有全部杀死，才能再次启动nodemanger。

《数据中台研习社》微信群，请添加微信：laowang5244,备注【进群】

?分享、点赞、在看，给个三连击呗！?