浅谈HDFS当中的进程以及pid的剖析

1. 进程一般通过 jps 命令查看。但 jps 不是linux系统自带的。而是 JDK 组件之一。所以确切的说应该是$JAVA_HOME/bin/jps

HDFS 一般情况下有三个进程

namenode
datanode
secondarynamenode

2. 其各自进程会生成一个对应的pid文件

这里我们讲讲 Hadoop2.x 和 CDH4/5 的组件pid文件研究

1 pid 文件在 tmp 目录下

2 pid 文件存在，对应进程有两种情况（进程会生成对应的 pid 文件。所以提到 pid 就一定是和进程有关的）

1. 进程OK
2. 进程挂了，pid 文件残留。下次启动服务时，报 pid 存在。需要手工删除该 pid 文件。（pid 不光大数据当中有， mysql当中也有）

3 pid 文件当中存储的就是对应的进程号。（比如我们 利用 jps 查看是否启动进程时，每个进程前面的数字就是进程号。比如着当中的24583，22748等）

4 ps -ef|grep hadoop与jps打印出的是一致的，ps -ef打印出的更全

3. 是否有进程名称和pid它就是存活的，没有它就是不存活？

1. 并不是，比如上一次的进程死掉了，上一次的进程号是4339，那么这次重新启动该进程。进程号还是4339吗？答案是否定。这次生成的是一个新的进程号。所以会报pid存在，需要我们手工删除
2. 对应的进程标识和文件路径会因用户不同而不同

因为我们使用的是Hadoop用户启动的三进程，cd /tmp   /hsperfdata_hadoop，这个路径是hdfs进程对应的标识文件位置。这个文件实质是 /tmp/hsperfdata_进程用户名称 

hadoop用户jps查看到的结果：

root用户jps查看到的结果：
root用户能看所有用户的jps结果，普通用户只能看自己的（加上sudo权限后也能看所有）。

4. proces information unavailable(真真假假)

proces information unavailable这种情况在生产时有时会碰到，为什么说他真真假假呢？举个例子：

有一个生产脚本，判断大数据组件进程是否okay，当jps查看进程发生process information unavailable这个情况时，脚本认为这个进程是失败无效的，脚本尝试重启这个Hadoop进程；其实人家进程是好好的。

root用户下使用的jps命令查询到的三个进程不可用

真：ps -ef|grep 25293 //有可能是pid，强行写ps -ef|grep namenode，出来有进程，则证明这个进程是okay的；真正判断进程是否可用。

假：我们kill -9 25293， 后使用jps查看当前进程后显示process information unavailable；于是我们测试把其余两个进程都kill掉。!

问题：为什么root用户杀掉进程后，jps查看命令还有残留，而新开session切换为hadoop用户后无残留。
回答：在部署过程中，hadoop中hdfs组件使用的是hdfs用户；我们的脚本统一使用的是root用户或sudo权限的用户获取。

5. kill 进程命令（人为或自动）

自动：当进程在Linux看来是耗内存最大的，他会自行进行kill，Linux的特性叫 OOM killer

1、我们在root用户下kill -9 26428、26621
[root@hadoop004 ~]# jps
26915 Jps
26428 -- process information unavailable
26621 -- process information unavailable
26328 NameNode

2、rm -rf hsperfdata_hadoop        //删除hsperfdata_hadoop这个目录

3、我们在namenode进程未杀掉的情况下，直接把存放的进程标识文件给删除了，再次启动start-dfs.jps时，无NameNode进程；单独使用命令：hadoop-daemon.sh start namenode，提示进程正在运行，kill掉后再启动即可。

手动：kill -9 进程值

6. linux在/tmp目录下会定期删除此文件下的目录（这是一个小坑）

linux在tmp目录下，30天为周期会定期删除一些文件及文件夹。
大数据组件运行周期两三个月，我们先要知道/tmp目录下存放的是这三个进程的pid

测试hadoop004用户，进入 /tmp目录，删除hadoop-hadoop-namenode.pid目录。

删除目录后，我们使用jps、ps -ef|grep 27619、hdfs dfs -ls /、hdfs dfs -mkdir /g6 …这些命令都能完美运行，测试下来没有问题。

但是

当我们使用stop-dfs.sh时，会显示no namenode to stop；
当我们使用jps查看时，namenode还在。
那我们使用start-dfs.sh，进行重启（有可能进程异常崩溃、生产过程中参数变更），而NameNode的pid永远是旧的；即使进行N次重启，NameNode的pid都是旧的，相当于是无法生效。

7 除了proces information unavailable问题，还有一种 main class does not exist问题

遇到这些问题怎么办？

**解决办法：**

停止掉dataNode和NameNode

删除输出的data文件和logs文件

重新执行格式化

借鉴了很多 https://blog.csdn.net/zhikanj... 的内容