[ CATEGORY ]
PAGE 1 / 2
某天执行 ps aux，列表里多出几行奇怪的记录：STAT 一栏是 Z，COMMAND 后面跟着 <defunct>。这些进程不占 CPU，也不怎么占内存，但 kill -9 对它们毫无作用，数量还会慢慢变多。这就是僵尸进程。
它并不神秘，本质上只是一个“已经退出、但还没被回收”的进程留下的空壳。理解它，需要先理解 Linux 里一个进程是怎么死的。
1$ ps -eo pid,ppid,stat,comm | awk '$3 ~ /^Z/'晚上十点，你 ssh 到服务器跑一个数据迁移脚本。四十分钟后，笔记本合盖，网络断开。第二天重新连上，pgrep 什么也没找到，日志停在连接断开的那一秒。
很多人第一反应是“程序被杀了”。更准确地说，是它从一开始就没有真正离开过终端。
从 shell 启动的进程，通常带着三样东西：
有个脚本，你在终端里敲 ./backup.sh，一切正常。放进 crontab，第二天早上一看，备份目录是空的。
crontab -l 里那行命令没写错，路径也对，可它就是不动。这种问题之所以难查，是因为 cron 执行命令时的环境和你的交互式 shell 差得很远：PATH 更短、不读你的配置、工作目录不是你以为的那个、输出没人接。下面按排查顺序拆开讲。
别急着改脚本。先分清是“没跑”还是“跑了但失败”。
一个跑得好好的脚本，加了一行 set -euo pipefail 之后突然开始随机失败。翻日志发现，那条命令明明“成功”了，退出码却是 141。
先还原一个很常见的现场。
服务换到新机器，日志目录写不进去。值班的同学熟练地敲下：
凌晨两点多，监控里出现一批超时告警：某个服务里所有 30 秒超时的 RPC 在同一秒内集体失败。翻日志时更奇怪，同一台机器上连续几条日志的时间戳是倒着走的：
102:17:03.914 request started
202:17:03.902 request timeout
302:17:03.918 request started凌晨两点，监控报警：一台文件服务器上的备份任务卡住了。你 ssh 上去，ps 看到 rsync 的状态是 D，于是熟练地执行 kill -9。一分钟后再看，它还在。再 kill，还在。重启服务，父进程也变成了 D。最后连 reboot 都卡在 “Unmounting filesystems”。
这不是玄学，而是 Linux 进程状态里最容易被误解的一种：不可中断睡眠。理解它，能帮你判断什么时候该修 I/O，什么时候该放弃等待、直接重启机器。
ps 的 STAT 列里，常见状态有这几种：
凌晨两点，监控告警：一台 8 核机器的 load15 超过了 10。
登录上去，top 却显示 CPU 空闲 75%，内存充足，磁盘也没报错。可服务的 P99 延迟已经从 80ms 涨到了 2s。
这是 load average 最容易被误解的地方：它不是 CPU 使用率，而是“有多少任务在排队或者卡住”。CPU 闲着的机器，负载一样可以很高。
一台 2 核 2G 的小型服务器上跑着 Nginx、Gunicorn 和 Redis。最近每隔两三天，就有一个 Python worker 突然消失，应用日志里没有任何异常，SSH 却还能正常登录。这不是程序自己退出，而是被内核的 OOM Killer 杀掉了。
本文按实际排查顺序，从确认内存状态到定位 cgroup 限制，整理一套可复用的命令。
登录后第一件事通常是看 free：
服务运行几天后，日志里开始出现：
1OSError: [Errno 24] Too many open files很多人第一反应是“磁盘满了”或“文件太多”，但在 Linux 中，文件描述符（FD）不只代表普通文件。socket、pipe、epoll、eventfd、inotify、signalfd 都会占用 FD。因此这句话的真实含义往往是：进程打开的连接、管道或事件对象，已经达到上限。