1. 进程控制，Linux 运维躲不开的“地基”
不管你是刚装了双系统的桌面用户，还是在企业里管理几十台 Rocky 服务器的运维，只要你碰 Linux，就一定会遇上“进程控制”这四个字。进程是 Linux 系统里最核心的执行单位——程序是磁盘上的静态文件，进程则是程序跑起来以后，在内存里那套动态的、带状态的运行实体。一个程序可以被反复启动成多个进程，每个进程有独立的 PID（进程号）、独立的内存空间、独立的资源统计，它们之间靠内核来调度、隔离、通信。理解了进程，就相当于拿到了读懂 Linux 操作系统的钥匙。
这篇文章会把进程控制拆成几个层面来聊：进程是怎么创建的、状态怎么切换、日常工作里怎么查看和杀死进程、进程占着 I/O 时怎么处理、虚拟机和嵌入式里的进程控制有什么不一样。其中会穿插一些我实际踩过的坑，比如脚本后台跑了一晚上却什么都没有写进日志，比如误删了正在被进程占用的文件结果还能救回来。标题里“Linux 系统 + 进程控制”这两个词，几乎涵盖了你日常运维 80% 的操作场景，值得花点时间彻底搞明白。
2. 进程的一生：创建、状态切换与退出
2.1 fork 与 exec：进程诞生的两条腿
Linux 上创建一个新进程，和很多人想象的“双击然后蹦出来一个新窗口”完全不同。它是通过系统调用 fork 和 exec 配合完成的：fork 会把当前进程的内存、寄存器、文件描述符整体复制一份，生成一个几乎一模一样的子进程，子进程和父进程从同一个位置继续往下执行；exec 则是把当前进程的地址空间清空，加载另一个程序文件，重新开始执行。也就是说，一个进程如果想启动另一个程序，整个过程就是“先 fork 一下变成双胞胎，然后其中一个把自己换脸成目标程序”。
这里有个理解上的关键点：父进程和子进程之间是“兄弟般”的独立关系，不是上下级关系。父子只是创建关系，不代表父进程死后子进程就一定跟着死。子进程如果没有父进程领养，会被 init/systemd 这样的 PID 1 进程收养，所以你会看到很多孤儿进程挂在 systemd 名下，这在 Linux 里是完全正常的。我见过不少新手用 ps 看到一堆子进程没有父进程以为出问题了，其实只是父进程退出后，systemd 接管了它们。
2.2 进程状态，一张表看懂
进程不是一直“活着”的状态，它随时可能在运行、睡眠、停止、僵死这些状态之间横跳。用ps aux或top看进程状态，就是看 STATE 那一列的字母。常见状态可以整理成一张表，建议直接记住：
| 状态 | 字母 | 含义 | 常见触发场景 |
|---|---|---|---|
| 运行中 | R | 正在 CPU 上跑或正在就绪队列里等待调度 | 高 CPU 的计算任务 |
| 可中断睡眠 | S | 等待某个事件（I/O、信号、定时器） | sleep、等待用户输入 |
| 不可中断睡眠 | D | 内核态等待，不能被信号打断 | 磁盘、NFS 卡住时常见 |
| 暂停 | T | 进程挂起 | Ctrl+Z、SIGSTOP |
| 僵尸 | Z | 进程已退出，但父进程没回收它的残留信息 | 父进程写的代码太差，不调用 wait() |
| 短暂不可中断 | I | 内核线程的短暂等待 | 内核内部任务 |
最让新手困惑的是 R 状态。R 不代表进程一定在“跑”，它是一个总的就绪调度队列，哪怕进程不停地在等待时间片，它如果还没睡下去，就一直显示 R。同时，R 状态的进程数长期大于 CPU 核数，说明机器负载偏高。这个用top里的 1 分钟 5 分钟 15 分钟负载均值就能对比出来——负载均值接近核数还好，超过 2 倍 CPU 核数就需要警惕了。
2.3 僵尸进程和孤儿进程的来龙去脉
僵尸进程这个词听起来很可怕，其实它只是“进程死了但尸体还没被收走”的数据残留。进程退出时，内核会保留一小段退出状态码、资源统计等数据，直到父进程调用了 wait 系列的系统调用把这些信息收走，这个 PID 才会被真正释放。如果父进程是那种写完就忘的烂代码，一直不调用 wait，子进程就会长期停留在 Z 状态，变成僵尸。
僵尸进程本身不占 CPU 也不占内存，但你也不能直接 kill 它，因为 kill 是发给活着的进程的，僵尸已经死了。正确做法是杀父进程，让僵尸被 PID 1 进程收养，PID 1 会在回收它们的一瞬间完成善后。要是系统里出现一大片僵尸，那就得仔细排查父进程到底在干什么，常见原因包括：父进程用循环 fork 后忘记 wait、父进程自身卡死在某个不可中断状态、父进程是跑飞了的脚本。
孤儿进程则是父进程先退出，子进程被 systemd/init 收养。这些进程是活着的，继续正常执行，不影响系统。等下节讲后台任务的习惯时你会发现，孤儿进程其实比僵尸进程常见得多。
3. 命令行里掌控进程：前后台、信号与守护化
3.1 前台后台切换，用 Ctrl+Z 和 jobs 做多任务
终端里运行命令，默认是前台进程，终端会被它独占，期间你什么其他命令都敲不了。这时你可以按 Ctrl+Z，进程会收到一个 SIGTSTP 信号暂停下来，然后你用bg命令把它丢到后台继续跑，用fg再把它拉回前台。配套的jobs命令可以列出当前这个 shell 会话里所有后台任务及它们的任务编号，比如[1]+ Running sleep 100 &。
这部分看着基础，实际是很多人搞混的地方。后台任务并不等于 daemon，它依然属于当前终端会话。你如果把终端窗口直接关掉，后台任务会收到 SIGHUP 信号，默认行为是直接终止。所以“关了窗口还能跑”才是最需要的技能，这就得上下一节讲的 nohup 和 setsid。
3.2 nohup、setsid 与守护进程的正确姿势
要把一个进程真正脱离终端存活，常见三件套：在命令后面加&、用nohup包裹、或者用setsid让进程彻底脱离会话。&只是告诉你 shell “这个命令放后台启动”，进程还挂着终端；nohup则是“当终端挂断时忽略 SIGHUP”，从而在关闭 SSH 后继续运行；setsid更彻底，直接让进程变成新的会话领头进程，跟当前终端一点关系都没有。
实际使用中我建议这样：临时性任务用nohup cmd > /tmp/cmd.log 2>&1 &，然后把输出的 PID 记录下来；长期稳定服务则优先交给 systemd，后面第 5 节会专门讲怎么用一个简单的 unit 文件把脚本变成服务。以前我刚学的时候习惯只加一个&就关掉终端，出门回来发现任务没跑，白白损失时间。现在还记得一个原则：凡是需要长时间跑的任务，永远把日志重定向到文件，并且养成“启动后马上看一下日志第一行”的习惯。
3.3 kill 与常用信号：进程控制的遥控器
进程控制里最频繁的动作就是“给进程发信号”，kill命令名字起得吓人，实际上它就是个信号发送器。信号是 Linux 内核对进程异步通知的一种方式，每个信号有固定的编号和默认行为。常用的我列在下面：
| 信号名 | 编号 | 默认动作 | 典型用法 |
|---|---|---|---|
| SIGHUP | 1 | 终止进程 | 终端挂断或让 daemon 重载配置 |
| SIGINT | 2 | 终止进程 | Ctrl+C 触发 |
| SIGKILL | 9 | 立即杀死，不可捕获 | 实在不听话时的最后手段 |
| SIGTERM | 15 | 请求终止 | 默认终止信号，可被应用捕获来做收尾工作 |
| SIGSTOP | 19 | 停止进程 | 相当于冷藏，进程还在但暂停 |
| SIGCONT | 18 | 继续执行 | 让被 SIGSTOP/SIGTSTP 暂停的进程恢复 |
这里有个非常实用的习惯：kill -9虽然看着爽，但应该最后考虑，而不是第一考虑。因为 SIGKILL 信号不能被进程捕获，进程没机会清理临时文件、释放数据库连接、保存状态。先发一个 SIGTERM（也就是默认的kill PID），给进程几秒钟完成善后；它实在赖着不走，再用kill -9。有经验的运维会把kill -9用在已经陷入不可中断睡眠、长时间卡死的进程上，因为这类进程给什么信号都没反应，只能强杀。
4. 用 ps 和 top 读懂进程现场
4.1 ps aux 字段精读
查看进程信息，ps是最基础的工具，但我见过很多人只会 “ps -ef | grep xxx”。ps aux输出的每个字段都非常有信息量：USER 是运行用户，PID 是进程号，%CPU 和 %MEM 是瞬时占用比例，VSZ 和 RSS 分别是虚拟内存和实际常驻内存大小，STAT 是状态，START 是启动时间，TIME 是累计占用的 CPU 时间，COMMAND 是完整命令行。一个常见误区是看到 %CPU 是 99% 就以为要加 CPU，其实它代表这个进程占用了差不多整个单核，如果机器是多核，真正的总体占用应该用 top 或pidstat综合看。
还有个小技巧，ps -eo pid,ppid,stat,etime,cmd,args可以自定义输出列，排查问题时特别有效。比如我想看“某个脚本到底跑多久了”，ps -eo pid,etime,cmd | grep myscript.sh就能直接看到从启动到现在经过的时间。比起ps -ef那堆默认输出，自选列能省很多眼睛。至于ps -ef和ps aux的区别，一个是 Unix 风格一种是 BSD 风格，字段大同小异，习惯哪个都行，不用纠结。
4.2 top 和 htop：现场压力分析
top是实时看进程和系统负载的利器。打开之后你五行汇总信息最重要：第一行可以看到当前时间、开机时间、用户数、1 分钟 5 分钟 15 分钟的负载均值；第二行看进程总数和运行/睡眠/僵尸数；第三行看 CPU 的 us(用户态)、sy(内核态)、wa(I/O 等待)、id(空闲) 等占比；第四五行看内存。CPU 的 wa 如果长期偏高，说明磁盘子系统是瓶颈，这时候光杀进程是没用的，得看看是不是某个进程在疯狂读写磁盘。
top里按 P 按 CPU 排序，按 M 按内存排序，按 z 高亮，按 h 调出帮助，按 k 可以对选中的进程直接发信号。如果觉得 top 界面难看，可以装htop，它支持鼠标操作、树状查看、多核图表，对新手更友好。不过老运维一般还是习惯 top，因为任何系统都自带，不要依赖额外工具，这是服务器排障的基本素养。
5. 脚本进程实战：日志缓冲、存活监控与误删恢复
5.1 长时间脚本没日志输出，问题是缓冲不是没跑
很多人在服务器上跑数据脚本，明明在终端里能看到 print 输出，重定向到日志文件后，却等了大半天tail -f都没看到一行内容。这个问题的根源一般是缓冲：当标准输出是终端时，C 库默认行缓冲，遇到换行就刷出去；当标准输出被重定向到文件时，默认变成全缓冲，数据会攒满一个 4KB 或 8KB 的缓冲区才一次性写入磁盘。Java 和 Python 尤其典型，Python 的print在重定向下经常被缓冲住。
解决办法不复杂：Python 可以在启动参数加python3 -u，或者代码里sys.stdout.reconfigure(line_buffering=True)；如果不想改代码，Linux 还自带一个万能工具stdbuf -oL，比如stdbuf -oL python3 myscript.py > run.log 2>&1 &，就能强制把标准输出和标准错误都改成行缓冲。再有就是不要在代码里只往控制台打日志，正经做任务还是建议用 logging 模块，设置好 file handler 和 flush 策略。日志一直空着，并不代表进程没活着，所以判断存活得用下面的方法。
5.2 如何确认脚本是否还在正常运行
判断一个脚本到底是在跑、还是卡住、还是已经死掉，不能只看日志有没有新增，因为日志不更新也可能只是缓冲没刷。我用一套组合拳：先用pgrep -f script_name.py找 PID，再用ps -p PID -o pid,stat,etime,cmd看它的状态和运行时长，最后用一个动态更新的方式确认它在干活，比如strace -p PID -e trace=read,write -c统计系统调用，或者直接cat /proc/PID/io看它在单位时间内的字节读写有没有变化。
还有一条铁律：后台任务的 PID 随手记下来。启动命令里加一句echo $! > /tmp/mytask.pid，以后查状态、发信号就不用重新 grep 了。$!是 shell 里最近一个后台进程的 PID，这个细节我用得频率非常高。如果任务是由 systemd 管的，就直接systemctl status 服务名，它会告诉你进程状态、PID、最近日志、是否开机启动，省力得多。
5.3 rm -rf 误删后，只要进程占着还能救回来
“rm -rf删掉的文件能恢复吗？”这个问题的答案，在 Linux 里有一个很现实又很吓人的分支：如果文件正在被某个存活进程打开，那它虽然从目录树里消失了，但数据仍然在磁盘上被那个进程的文件描述符持有。此时完全可以把数据从/proc/<pid>/fd/<fd号>这个虚拟路径里倒出来，恢复效率很高。
实际操作分四步。第一步，用lsof +L1 | grep deleted找到被删除但还被进程打开的句柄，或者直接lsof | grep 'deleted'。第二步，从输出里找到进程 PID 和文件描述符编号。第三步，用cat /proc/<pid>/fd/<fd号> > /tmp/recovered.txt把文件内容导回。第四步，赶紧让它落地成正常文件，然后做快照或者备份。但注意，这个方法的前提是文件被“占用中”。如果删除时没有进程打开它，常规手段基本救不回来，除非用 ext4 的 debugfs、extundelete 这类底层工具去扫磁盘，这就看运气了。所以我一直坚持：能用普通命令移动就用普通命令，rm时要反复确认路径，重要资料必须有备份。
5.4 用 systemd 接管关键进程
手工 nohup 适合临时任务，生产环境里长期跑的脚本、服务，我强烈建议用 systemd 接管。它的好处太多：开机自启、自动重启、日志集中、资源限制、依赖管理。一个最简单的服务文件长这样：
[Unit] Description=My Python Service After=network.target [Service] ExecStart=/usr/bin/python3 -u /opt/app/myservice.py Restart=on-failure RestartSec=3 StandardOutput=journal StandardError=journal User=appuser [Install] WantedBy=multi-user.target把这段内容放到/etc/systemd/system/myservice.service，然后执行systemctl daemon-reload、systemctl enable --now myservice，服务就会被拉起并设置为开机自启。查看状态用systemctl status myservice，看日志用journalctl -u myservice -f。管理进程再也不用到处找 PID 了，systemctl 把启停、查状态、看日志、设开机启动都集中在一条命令里。
6. 资源的“紧箍咒”：优先级、文件描述符与 cgroup
6.1 nice 值与 renice：让进程学会排队
进程控制不只是启动和杀死，还有“协调资源”。Linux 进程调度器会根据 nice 值计算进程的优先级，nice 值范围是 -20 到 19，默认 0，数值越小优先级越高。普通用户只能调高 nice 值（更友好），只有 root 能调低 nice 值（抢资源）。比如一个批量压缩任务撞上一个在线服务，你就可以用nice -n 10 ./compress_task让压缩任务的优先级让位于在线服务；如果任务已经在运行，用renice 10 -p PID动态调整。
实用技巧是配合taskset绑定 CPU 核。嵌入式或者多路服务器上，把计算密集任务绑到固定 CPU，可以避免它在多个核之间来回切换缓存，性能能提升不少。命令写法是taskset -c 0,1 ./my_task，表示只让它在 0 号和 1 号 CPU 上运行。这两个命令配合好，就能在不改代码的情况下显著改善系统响应。
6.2 ulimit：限制每个进程的资源上限
Linux 对进程的资源使用是有“户口本”的，可以用ulimit -a查看当前 shell 会话的所有限制。几个最常用的：ulimit -n控制文件描述符数量，高并发服务如果这里设太小，进程会报 “Too many open files”；ulimit -u控制每个用户可创建的进程数；ulimit -v控制虚拟内存大小。运维里最痛的坑之一就是 Linux 默认对一个用户的进程数限制太小，比如账户下的任务一多，明明内存还有余量，却 fork 不出新进程，日志里全是 “resource temporarily unavailable”。
生产环境调优一般会在 systemd 服务文件里用LimitNOFILE=65535和LimitNPROC=65535，或者在/etc/security/limits.conf里配好。嵌入式系统里则相反，往往会刻意调低这些限制，防止某个失控进程把整块内存吃光，因为嵌入式内存本来就紧张。
6.3 cgroup 与容器：更现代的进程隔离
如果把进程控制提升到容器层面，资源限制的主角就变成了 cgroup。Docker、Kubernetes 对 CPU、内存、IO 的限制，底层全部是 cgroup 实现的。在 systemd 系统上，最快的临时限制方式是用systemd-run：
systemd-run --scope -p CPUQuota=50% -p MemoryMax=512M ./myapp这条命令会临时把./myapp放进一个资源受限的 scope 里，CPU 使用率上限 50%，内存最大 512M。在传统环境里，直接用 cgroupfs 操作也是可行的，只是语法比较底层，所以我更推荐 systemd 这个入口。理解了 cgroup，你再回头看容器里的进程，就会明白为什么容器内看到的进程、PID，跟宿主机上的进程之间有一套复杂的映射关系，这些抽象很难靠肉眼直接对应。
7. 不同环境下的进程控制：虚拟机、嵌入式与企业发行版
7.1 VMware 与双系统：把进程控制练扎实，系统随便折腾
很多新手为了学 Linux，会在虚拟机上安装系统，或者干脆一台机器装 Windows 和 Linux 双系统。VMware 里跑 Linux，很方便的一点是快照功能：在改内核参数、调优先级、实验 kill -9 之前打一个快照，翻车了直接回滚。这个办法我特别推荐给刚开始学进程控制的人，因为像kill -9杀 shell、把 init 进程弄停这种操作在物理机上就没法回头了，虚拟机里却能肆无忌惮地折腾。
在虚拟机里使用 Linux 时，想从 Windows 往虚拟机粘贴文本，只要装了 VMware Tools（或 open-vm-tools）就能无障碍复制粘贴。类似地，如果你在虚拟机里看到ps ef显示的进程树，包含了一堆和宿主机交互的服务进程，不要慌，那是 tools 的服务，对进程控制排查影响不大。双系统更是把 Windows 和 Linux 隔离开，互不干扰，只是要注意两个系统的引导顺序，跟进程控制没有直接关系。
7.2 企业发行版：Rocky Linux、银河麒麟与系统补丁
企业在生产环境里更喜欢稳定派发行版，比如 Rocky Linux、AlmaLinux，以及国产的银河麒麟。这些发行版名字不同，底层的进程模型完全一致，因为内核都是 Linux 内核，进程相关的命令、systemd 体系、信号机制都通用。所以你在 Ubuntu 上练会的systemctl、kill、journalctl，切到 Rocky 或麒麟上仍然是同一套操作。
刚装完的 Rocky Linux 要连有线网，不用去翻老旧的 ifconfig，用 nmcli 即可：nmcli device status查看网卡状态，nmcli connection up ens33拉起有线连接，nmcli connection modify ens33 ipv4.method manual ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1修改 IP 地址。改 IP 时要留意正在跑的远程连接，如果改的是自己正在用的 IP，小心直接断掉。麒麟这类系统打补丁时，绝大多数都是基于 apt 或 dnf 的包管理器，先停相关服务，打完补丁再启动服务，避免补丁覆盖进程正在使用的库文件造成运行时崩溃。
7.3 Foxmail 这类应用进程迁移：先停进程，再动文件
网上搜“Linux 系统 foxmail 邮箱邮件存储位置变更”的人不少，这类应用迁移有一个千万要记住的原则：先清理掉正在运行的 Foxmail 进程，再移动/重命名邮件目录。为什么？因为进程一旦启动，就会持有邮件目录里文件的文件描述符，你以为你把目录移走了，实际上进程还通过旧句柄读写着原来的 inode，移动完成后数据到底写哪儿了根本说不清楚，严重时还会损坏邮箱结构。
正确顺序是用pkill foxmail先停掉进程，确认没有残留（ps aux | grep foxmail），再修改配置文件里的邮件存储路径或移动目录，然后重新启动 Foxmail，最后验证索引和邮件是否正常加载。这个流程不光对 Foxmail，对数据库、消息队列、任何有持久化文件的应用都适用。我遇到过的“迁移后文件被锁、无法删除”之类的坑，基本都是因为忘了先杀进程。
7.4 备份别总惦记 Ghost：Clonezilla 与进程一致性
有人问“Linux 系统分区是不是不能用 Ghost 备份”，这是有一定道理的。Ghost 主要面向 Windows 的 FAT/NTFS 分区，对 Ext4、XFS 这些 Linux 文件系统的支持很弱，用 Ghost 备份 Linux 分区容易出奇怪的问题。Linux 生态下的免费备份神器是 Clonezilla，中文叫再生龙，支持主流文件系统，可以做分区镜像、完整磁盘克隆。它跟 Ghost 最大的区别就是专门考虑过 Linux 文件系统特性。
但备份之前必须做一件事：让业务进程进入一致状态。最稳妥的是停应用进程、执行sync把文件系统缓存落到磁盘，再启动备份工具。数据库这种对一致性敏感的，最好用数据库自身的备份机制，单纯复制文件很容易得到一份说不清能不能用的备份。备份的过程本质是“冻结 + 复制”,而冻结的就是正在运行的进程的写入。
7.5 嵌入式 Linux 的进程控制：减法思维
如果你在 ZYNQ 7020 这种板子上跑 Linux，会发现进程控制的思路和老服务器很不一样。ZYNQ-7000 系列采用双核 Arm Cortex-A9，资源有限，能跑完整的 Linux 系统，但内存和存储都紧张。这种环境下，进程控制更要讲究“减法”：启动的进程越少越好，后台服务能用 busybox 提供的精简版就不用大而全的组件，日志策略要开 logrotate 防止日志把磁盘塞满。
嵌入式里最常用的进程控制命令也就是ps、kill、nohup、killall，但要注意，嵌入式 Linux 的 ps 工具往往是 busybox 版，某些选项跟桌面发行版不一样，比如不支持ps aux的完整字段，建议先用ps -ef或ps裸跑确认支持哪些参数。还有一个经验：嵌入式程序崩溃时经常连 dump 日志都来不及打，很多设计会用一个看门狗脚本监视进程状态，进程掉了立刻重启。那个“查询脚本是否还在正常运行”的思路，其实也是看门狗的核心，放到嵌入式上因为资源受限格外关键。
8. 进程控制实用速查：我常用的命令组合
最后分享几条我日常高频使用的命令组合，适合直接抄走。排查问题时基本都是这些命令的排列组合。
# 找进程 pgrep -af "python.*myservice" # 看指定进程的详细信息：PID、状态、运行时长、完整命令 ps -p <pid> -o pid,ppid,stat,etime,cmd # 实时看进程的线程和 CPU 占用 top -Hp <pid> # 杀掉指定名称的进程，优雅版先 TERM pkill -TERM myservice # 5 秒后还活着再 KILL sleep 5 && pkill -KILL myservice # 查看系统所有进程状态分布 ps -eo stat | awk '{print $1}' | sort | uniq -c # 查看被删除但被进程占用的文件 lsof +L1 | grep deleted这些命令就像写字用的笔，不需要记全，但常用的几只一定放桌面上。第一次接触时不要死记，遇到实际场景再用一遍两遍，很快就能形成肌肉记忆。我教团队新人的办法是：每天上班第一件事跑一次ps -eo pid,ppid,stat,etime,cmd | head -30，看看系统里有几个关键服务，过一周自然就熟了。
在我自己的使用经验里，进程控制最微妙的部分不是命令考察，而是“纪律”：优先发 SIGTERM 而不是 SIGKILL，重要删除操作前先用 lsof 看清文件有没有被占用，用 systemd 接管长期服务，给后台任务随手记录 PID。这些习惯养成了，系统维护就算立住了。你可以下一步把这套进程控制知识用到你手头的任何 Linux 环境里——无论是虚拟机双系统、企业服务器还是嵌入式板卡——基础完全一样，差别只是资源约束和管理工具的顺滑程度。
