本文约2900字,今天遇到一个问题,设备出现故障,调试时发现kill/kill -9都杀不掉主进程,杀完变成僵尸进程了。后面排查是只有我的板子有问题,相同的程序在其他硬件上没有问题。因项目赶进度,暂时搁置没有继续追查具体原因。下班回家了,好好查询整理一下kill/killall命令的深层原理。
关注公众号, 即可获得与Linux相关的电子书籍以及常用开发工具,文末有文档清单
核心问题:为什么有时
kill杀不死进程?为什么kill -9反而会产生僵尸?killall和kill到底有什么区别?相同程序在不同设备上表现为何不同?本文将彻底讲清信号机制、僵尸成因、工具差异及实战排查方法。
kill PID | 可捕获、可忽略、可阻塞 | |||
kill -9 PID | 不可捕获、不可忽略、不可阻塞 | |||
kill -15 PID | kill 完全等价 | |||
kill -2 PID | ||||
kill -3 PID |
误区一:kill -9 是万能杀手,一定能杀掉任何进程
真相: 进程处于 D 状态(不可中断睡眠) 时,连 SIGKILL 也无法杀死,必须等待 I/O 恢复或重启系统(例如 NFS 故障、有缺陷的设备驱动)。
误区二:kill -9 不会产生僵尸进程,kill 才会
真相:僵尸进程的产生与信号类型无关,只取决于父进程是否调用了 wait() 回收子进程。无论子进程如何退出(正常 exit、SIGTERM、SIGKILL、段错误崩溃),只要父进程不回收,必成僵尸。
当一个进程退出时,内核释放其大部分资源(内存、文件描述符、栈等),但保留最小的进程描述符(包含 PID、退出状态、资源使用统计),直到父进程通过 wait() 或 waitpid() 读取退出状态。这段“已死但未被清理”的状态就是僵尸进程(状态码 Z)。
$ ps aux | grep defunctuser 12345 0.0 0.0 0 0 ? Z 10:20 0:00 [test] <defunct>fork 失败)僵尸进程本身无法被任何信号杀死(因为它已经死了),只能:
方法一:杀死僵尸的父进程,让 PID 1 的 init/systemd 收养并回收
# 找到僵尸进程的父进程 PPIDps -eo pid,ppid,stat,comm | grep Zkill -9 <PPID> # 谨慎:会影响父进程的其他子进程方法二:重启系统(终极手段,父进程可能是内核线程或 1 号进程)
kill | killall | pkill | |
|---|---|---|---|
-u | -u | ||
-g | -g |
# kill:通过 PIDkill 1234 # 发送 SIGTERMkill -15 1234 # 同上kill -9 1234 # 强制杀死kill -SIGKILL 1234 # 同上# killall:通过进程名killall nginx # 停止所有 nginx 进程(优雅)killall -9 nginx # 强制杀死所有 nginxkillall -u root -9 bash # 杀死 root 用户的所有 bash# pkill:更灵活的匹配pkill -f "python.*server"# 杀死命令行包含 python.*server 的进程pkill -TERM -u www-data # 给 www-data 用户所有进程发 SIGTERM用户观察:对某个进程执行 kill <PID> 后进程还在,执行 killall <进程名> 却能杀掉。为什么?
| 信号被忽略 | strace -e signal kill <PID> | |
| PID 已变化 | kill | ps 确认 PID 是否匹配当前进程 |
| 权限不足 | kill -9 <PID> 是否报错 "Operation not permitted" | |
killall 匹配了多个 | killall -v <进程名> | |
killall 发送的信号不同 | killall 默认发送 SIGKILL?极少数实现例外 | strace -e signal killall <进程名> 确认 |
# 启动一个忽略 SIGTERM 的示例进程trap"echo 'SIGTERM ignored'" TERM; whiletrue; do sleep 1; done &PID=$!# 尝试 kill(SIGTERM)——无效,进程继续运行kill$PID && echo"Sent SIGTERM"# 使用 kill -9 ——成功杀死kill -9 $PID# 结论:不是 killall 更厉害,而是需要发送正确的信号用户观察到:用 kill <PID> 杀死某个进程后出现僵尸;用 killall -9 <进程名> 却没有僵尸。
僵尸产生的唯一条件是:**子进程退出 + 父进程未调用 wait()**。
关键区别在于:
kill <子进程PID> | wait() → 子进程变僵尸 | |
killall -9 <进程名> |
#include<stdio.h>#include<unistd.h>#include<sys/wait.h>intmain(){pid_t pid = fork();if (pid == 0) {// 子进程:立即退出return0; } else {// 父进程:永不调用 wait,直接进入死循环printf("Child PID: %d\n", pid);while (1) sleep(1); }}./test & # 启动,记录 Child PID = 1234,Parent PID = 1233# 方式1:只杀子进程kill 1234 # 子进程退出ps aux | grep test# 看到 [test] <defunct> 僵尸出现# 方式2:杀所有同名进程./test & # 重新运行killall test# 同时杀死父进程和子进程ps aux | grep test# 无僵尸(父进程死后子进程被 init 回收)程序逻辑完全一样,设备 A 上 kill/kill -9 不会导致僵尸,设备 B 上却会。
僵尸产生与程序逻辑无关,与父进程是否能正常调用 wait() 有关。差异来源:
| 父进程执行路径被阻塞 | wait() 之前的代码 |
| 父进程被外部杀死 | ulimit、systemd 看门狗、OOM killer),提前杀死了父进程 |
| init 进程行为差异 |
# 1. 确认父进程是否还活着ps -ef | grep <父进程名># 2. 查看父进程卡在哪里cat /proc/<父进程PID>/wchan # 内核等待通道strace -p <父进程PID> # 系统调用跟踪# 3. 检查 PID 1 的回收行为ps -p 1 -o comm=# 如果是 systemd → 正常回收# 如果是 busybox init → 可能存在问题# 4. 查看系统日志dmesg | grep -E "oom|killed|segment"journalctl -u <服务名> -n 50第1步:先发 SIGTERM (kill PID) ↓第2步:等待 3-5 秒 ↓第3步:检查进程是否还在 (ps -p PID) ↓第4步:还在 → 发 SIGKILL (kill -9 PID)// 方法1:显式调用 wait()signal(SIGCHLD, SIG_IGN); // 方法2:忽略子进程退出信号(某些系统自动回收)// 或pid_t pid = fork();if (pid == 0) {// childexit(0);} else { wait(NULL); // 方法1:等待子进程}# 方法3:使用 double fork 技巧(孙进程被 init 收养)# 方法4:用 systemd 管理服务,自动处理孤儿进程
这里是女程序员的笔记本
15年+嵌入式软件工程师兼二胎宝妈
分享读书心得、工作经验,自我成长和生活方式。
希望我的文字能对你有所帮助