原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://liuqunying.blog.51cto.com/3984207/1716678
一个杀不死的小强，kill进程无效的原因
记录故障排查过程中kill进程无效的分析过程
今天在处理一个机器异常负载（1000+）的问题，碰到了一个从未碰到过的情况，遇到了一个异常顽固的分子。我使用了所能想到的所有杀进程的方法，却始终无法干掉这个顽固分子，最后终于在谷歌大神的指引下，干掉了这个令我郁闷至极的顽固分子。
1.问题描述：
系统：内核 2.6.32.43
机器：web A web+NFS B
机器负载超高，但是却可以正常登录，响应也很快
分析过程：
1.通过top查看，发现CPU和内存都正常，swap使用过大
A机器:/usr/local # toptop - 11:01:29 up 1051 days, 16:55, 3 users, load average: 1694.36, 1694.26, 1679.68Tasks: 5367 total, 1 running, 5366 sleeping, 0 stopped, 0 zombie Cpu(s): 9.1%us, 19.6%sy, 0.0%ni, 50.0%id, 21.3%wa, 0.0%hi, 0.1%si, 0.0%stMem: 8049196k total, 7985004k used, 64192k free, 4080k buffers Swap: 2104504k total, 2067308k used, 37196k free, 3381972k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1896 root 20 0 16840 15m 468 S 6 0.2 95:41.71 sap1002 9393 root 20 0 268m 4572 252 S 6 0.1 3650:16 newoctopusd 27609 root 20 0 9648 5300 876 R 4 0.1 0:00.55 top 13737 root 20 0 61072 58m 58m S 1 0.7 0:02.77 sqm_agent
2.free -m查看磁盘使用情况，主要是为了看swap的使用情况
A机器:/usr/local # free -m total used free shared buffers cached Mem: 7860 6611 1249 0 10 2134-/+ buffers/cache: 4466 3394 Swap: 2055 2045 10
3.揪出罪魁祸首 top +f+p,通过swap栏找出使用swap最多的程序，每个httpd使用4M，好像也不多嘛。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND 5135 root 20 0 266m 788 432 S 6 0.0 0:26.68 265m newoctopusd 5082 root 20 0 61072 58m 58m S 1 0.7 0:02.62 1276 sqm_agent 16796 root 20 0 5796 1484 880 R 1 0.0 0:00.09 4312 top 5186 root 20 0 30616 21m 472 S 0 0.3 0:01.21 9112 dnsagent 5831 root 20 0 5288 2060 1320 S 0 0.0 0:00.06 3228 sshd 1 root 20 0 788 304 256 S 0 0.0 0:29.38 484 init 2 root 20 0 0 0 0 S 0 0.0 0:00.00 0 kthreadd
4.由于机器是从其他部门转交过来的，所以想当然认为httpd没啥问题，不过还是随手一个命令，然后就惊呆了，502个进程。
ps axu |grep http|wc -l
502 这是要闹哪样啊，有这么启动进程的？
5. 于是自信满满的killall httpd，/usr/local/apache2/bin/apachectl -k start等着释放资源，发现启动失败，端口占用。
于是查看httpd进程，发现有一个顽固分子残留，好吧，干脆点，killall -9 httpd，/usr/local/apache2/bin/apachectl -k start，加9了不信还有问题，结果可是依旧端口占用。
ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 29211 3398 0 11:02 pts/3 00:00:00 grep http kill 16295 ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 29625 3398 0 11:02 pts/3 00:00:00 grep http kill -9 16295 ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 30112 3398 0 11:02 pts/3 00:00:00 grep http kill -TERM 16295 ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 30112 3398 0 11:03 pts/3 00:00:00 grep http
是不是有什么冤情呢？那就来查看下这个进程的状态，看看有何原因：
ps axopid,comm,wchan | grep 16295
16295 httpd nfs_wait_bit_uninterruptible原来冤情在这里：谷歌了下，确认是2.6.33.1内核之前的一个NFS bug
nfs_wait_bit_uninterruptible:
https://bugzilla.kernel.org/show_bug.cgi?id=15552
验证：
机器磁盘情况：
A机器:/usr/local # df -hFilesystem Size Used Avail Use% Mounted on/dev/sda1 9.9G 1.8G 7.6G 20% /udev 3.9G 296K 3.9G 1% /dev/dev/sda3 20G 13G 6.4G 67% /usr/local/dev/sda4 103G 28G 70G 29% /data B机器:/xx/htdocs 103G 30G 68G 31% /xx/admin/htdocs
访问挂载的目录，无法访问，长时间无响应
访问远程NFS服务机器B，发现机器超高，基本失去响应了，于是重启机器。
重启B机器 NFS机器后发现，A机器这台机器负载也恢复了。
查看顽固分子16295，发现已经消失了。
root 18012 1 1 11:14 ? 00:00:01 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18168 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18169 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18171 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18173 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18175 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k start