★ FEATURED ARTICLE 写Linux文章最怕写成命令手册堆砌。但进程控制这个主题恰恰是命令背后的机制和坑最容易被人忽略——比如为什么有些进程杀不掉为什么明明关掉了终端程序却还在跑为什么服务器重启后服务没起来。这些场景我几乎每年都会遇到几回每次排查都能发现有人对进程的基本规律没吃透。这篇文章我尽量不绕弯子把进程控制从原理到实操拆开讲先搞清楚进程怎么诞生、怎么活着、怎么结束然后聊怎么观测进程状态再讲到启动调度时的各种细节接着深入信号机制最后结合systemd说现代发行版下的进程管理方式。内容偏运维和开发实战面试准备也够用。1. 先弄懂进程在系统里的一生从PID到僵尸状态进程控制的核心永远是围绕PID和PPID展开的。内核里每一个进程都对应一个task_struct结构它像一张户口页上面写着这个进程的编号PID、父进程编号PPID、当前状态、打开的文件描述符、挂的信号处理器、CPU时间统计等等。我们日常操作进程本质上就是在操作这张“户口信息”。很多新手不理解为什么Linux的进程管理那么复杂其实只要记住一句话Linux下进程和程序是两回事。程序是磁盘上的静态文件比如/bin/bash进程是这个程序被加载到内存后正在运行的那份动态实例。类比一下程序是菜谱进程是厨师照着菜谱正在做的那道菜——同一个菜谱可以同时被多个厨师使用也就是同一个程序可以对应多个进程。1.1 进程是如何诞生的fork与execLinux里几乎所有的进程都不是“凭空出现”的。除了0号进程idle进程和1号进程init/systemd是内核在开机时手动创建的其他进程都遵循一个固定套路先复制再替换。这个复制动作叫fork。进程调用fork()时内核会把这个进程的地址空间、打开的文件描述符、环境变量等复制一份生成一个几乎一模一样的子进程。子进程拿到新的PID父进程通过wait()系统调用等待子进程结束。复制完成之后子进程再调用exec系列函数比如execve让自己变身成另一个程序——这一步才是真正“换内容”的过程。所以你会看到在Shell里执行一条命令时Shell先fork出一个子进程这个子进程再用exec把自己替换成你要跑的那个命令程序。这个“先fork再exec”的组合是理解所有进程启动方式的基础。很多时候排查看不到进程异常退出的原因其实是因为搞混了“哪个进程是父进程哪个是被exec替换后的进程”。1.2 进程生命周期里的关键状态进程在生存期间会不断切换状态。用ps能看到的常见状态码包括R运行、S可中断睡眠、D不可中断睡眠、T暂停、Z僵尸。大多数时候R和S很常见D状态一般出现在等待磁盘IO时Z状态则是排查时的重灾区。僵尸进程是最有意思的状态它的生命已经结束了但它的“户口页”还没被销毁。原因是子进程退出时需要把退出码告诉父进程这个退出码就放在task_struct里。只要父进程没调用wait()来读取这个退出码内核就不敢把task_struct回收掉。这个已经死了但没被“收尸”的进程就是僵尸状态。你没法用kill杀掉僵尸进程因为它的执行代码已经没了信号根本无从处理。唯一的办法是让它的父进程“收尸”——也就是父进程调用wait()或者直接干掉父进程让僵尸进程被托管给一号进程后清理掉。我曾经见过一台机器上堆积了几百个僵尸进程最后发现是某个Python服务fork了子进程却从不wait代码里没写好回收逻辑进程数直接撑爆了系统的PID上限。1.3 孤儿进程的归宿与僵尸相对的是孤儿进程父进程死了子进程还活着。Linux的处理方式是把孤儿进程统一过继给1号进程systemd由它来负责等待和回收。所以如果你用nohup启动一个后台进程然后把Shell关掉这个进程不会死而是被systemd接管继续在后台跑。理解这层逻辑很重要。很多人在服务器上跑长任务时习惯直接关闭终端结果任务还在跑但又找不到它在哪个终端里这就是因为进程已经脱离原来的终端会话过继给systemd了。后面讲到setsid、disown的时候你还会再次遇到这个机制。2. 怎么把系统里的进程看清楚常用观测命令组合控制进程的前提是能看到进程。ps命令是最基础的但很多人只会看ps aux的输出不知道怎么从里面快速提取有效信息。我来拆一下最实用的几个组合。2.1 ps的实用输出解析ps aux输出的每一列都很关键。USER是启动用户PID是进程号%CPU和%MEM是资源占用VSZ是虚拟内存大小RSS是常驻物理内存大小STAT是状态START是启动时间COMMAND是完整的命令行。排查问题时我第一眼看的是STAT列。如果看到Z说明有僵尸如果看到D说明这个进程卡在不可中断的等待里可能是磁盘IO出问题如果大量进程都是S状态但CPU占用很高那就得看具体是哪几个进程在抢CPU了。ps的--forest参数也是宝藏它能把进程树以树状结构显示出来父子关系一目了然。我每次排查服务异常时都会先跑这条命令ps -ef --forest这条命令会把所有进程按父子关系分层显示。你想找某个服务的子进程有没有残留或者确认某个守护进程下面挂了多少worker用它最直观。比用pstree更全面因为保留了完整命令行。2.2 动态监控top与htop的使用心得ps是静态快照top是动态监控。top默认按CPU占用排序适合找“谁在吃CPU”。按大写P按CPU排序按大写M按内存排序这个大多数人都知道。我想提两个容易被忽略的点第一top第一行的load average是1分钟、5分钟、15分钟的负载均值。如果你看到load值超过CPU核心数说明系统确实繁忙。但要注意load高不一定代表CPU忙也可能是大量进程处于D状态等待磁盘IO这时候CPU其实很闲我们在排查时经常会踩这个误区。第二top的交互界面里有个“H”键可以切换到线程视图。很多进程是单进程多线程架构你在进程列表上看不到CPU消耗的真相。按H后你能看到每个线程的CPU占用就能定位到具体是哪条线程在空转。比如Java应用出现CPU飙高时我会先在top里按H定位线程号再用jstack取线程日志一条路就盘清了。htop相对来说更人性化支持鼠标操作、颜色区分、树状视图。但它不是所有环境都预装我在生产机上更习惯用原生top因为不用装额外依赖。2.3 快速定位进程PID的三个命令知道我目标程序的真实名字怎么快速找到PID三个命令各有分工pgrep -a nginx # 按名称匹配显示PID和完整命令行 pidof nginx # 只输出PID适合脚本里赋值用 pgrep -af python.*app.py # 按完整命令行匹配比单纯按名字更准确pgrep支持模糊匹配和正则好处是能按参数过滤。pidof的优点是输出干净直接给PID列表写Shell脚本时特别方便。要注意的是pidof默认精确匹配进程名如果你要匹配带参数的进程还是得用pgrep。另外有个冷门但实用的技巧查看某个端口被哪个进程占用时优先用ss而不是古老的netstatss -tulnp | grep :8080ss列出监听端口时能直接带上进程名和PID不需要再额外做PID反查。排查端口冲突时这条命令基本是秒出结果。3. 启动与调度不是简单nohup前台后台、优先级和CPU绑定每次看别人写启动脚本无非就是nohup something 一挂了之。但进程控制远不止这一层至少应该知道前后台切换、会话脱离、调度优先级以及CPU亲和性这几个维度。3.1 前后台作业控制Shell里用一条命令启动进程后它会占用当前终端的输入输出。这些在前台运行的进程有个特点它收到的信号和终端按键直接关联比如CtrlC会产生SIGINT信号发给它。如果你希望程序在后台走可以启动时加一个“”符号long_running_task 加了这个符号后Shell会立即返回提示符进程继续运行但它的标准输出和标准错误仍然连着终端。这就带来一个影响关掉终端窗口时终端挂断事件会向后台进程发送SIGHUP信号进程很可能随之退出。把已经在前台跑的进程切到后台可以用CtrlZ暂停然后执行bg让它继续在后台运行。这个过程在作业控制中非常常见# 按CtrlZ暂停当前进程 jobs -l bg %1jobs -l能看到当前终端会话下所有的作业列表。作业控制属于“终端会话级”的概念一旦你退出这个终端会话这些作业就都不存在了所有进程则转为孤儿进程重新被systemd收养。3.2 nohup、setsid与disown脱离挂断信号想真正让进程不在乎终端挂断核心是让它忽略或绕过SIGHUP信号。nohup的做法是启动时自动把SIGHUP信号的处理方式设置为忽略并且把输出重定向到nohup.out文件。setsid的做法更彻底它会创建一个全新的会话让进程彻底脱离原终端的控制。我个人在生产环境启动长任务的推荐顺序是这样的优先用setsid或systemd-run而不是nohup。因为nohup虽然忽略SIGHUP但进程仍然和原终端会话有千丝万缕的关系setsid则让进程成为完全独立的会话领头进程逻辑上更干净。不过很多发行版默认没有预装setsid命令需要util-linux包一般服务器上都有。已启动的进程想脱离当前Shell的挂断信号可以用disown命令disown -h %1-h选项是“仅清除SIGHUP绑定其他保持原样”让作业不被挂断。这个命令在你忘了用nohup时特别救命。3.3 调整进程优先级nice与reniceLinux的CPU调度默认使用CFS完全公平调度器但进程之间有优先级差异字段叫nice值范围是-20到19。nice值越低优先级越高越容易被调度器选中执行。启动时指定优先级用nicenice -n -5 ./important_task注意设置负nice值需要root权限普通用户只能调高nice降优先级不能调低。运行中的进程用renice调整renice -n -10 -p 12345调整nice值的时机和分寸很重要。我在实际运维中见过有人把所有进程的nice都调成负数结果系统交互操作变得特别卡因为普通命令反而得不到CPU时间。正确的思路是只对真正重要的批处理任务降低nice值其他进程保持默认。3.4 绑定CPU核心taskset在多核服务器上进程默认可以在任意CPU核心上运行。但有些场景希望进程固定在某个核心上执行比如对延迟敏感的应用避免CPU缓存频繁失效。taskset就是干这个的taskset -c 0,2 ./app taskset -cp 0 12345 # 把PID 12345绑定到0号核心-C参数里那个p是“查询并设置已有进程”的意思。这个命令在排查NUMA架构下的性能问题时特别有用不过普通场景用得不多知道有这个能力就够了。4. 进程终止要讲信号kill不是乱杀进程控制里最容易被误解的就是kill。很多人以为kill就是“杀死进程”实际上kill命令的本意是发送信号。它默认发的是SIGTERM15号信号而这个信号是否立刻杀掉进程完全取决于进程自己的处理逻辑。4.1 常见信号的适用时机信号很多掌握这几个就够日常使用了信号编号默认行为适用场景SIGINT2终止进程等效CtrlC适合交互式程序优雅退出SIGTERM15终止进程kill命令默认信号请求进程自行退出SIGKILL9强制终止进程无法响应时兜底使用SIGHUP1终止进程终端挂断或重新加载配置SIGSTOP19暂停进程冻结进程不终止可用SIGCONT恢复SIGCONT18继续运行恢复被暂停的进程SIGQUIT3终止生成core文件调试崩溃现场时使用SIGTERM是唯一推荐的“礼貌请求”进程收到后可以执行清理动作再优雅退出。好的服务程序都会注册SIGTERM处理器用来关闭连接、保存状态、释放资源。如果你直接kill -9内核会强制回收进程资源不做任何清理很可能导致数据损坏或者端口没释放干净。4.2 为什么kill -9是最后手段我在实际排障时见过太多人遇到进程卡住第一反应就是kill -9然后发现服务重启后起不来。原因多半是进程依赖的数据文件没写完或者共享内存没清理干净残留状态挡了路。正确顺序应该是先killSIGTERM等待几秒观察进程是否退出如果还在再考虑SIGINT或者SIGQUIT最后才用kill -9。尤其是在处理数据库、消息队列这类带持久化状态的服务时直接强杀几乎等于自断后路。但有一种场景必须用kill -9进程完全失去响应且不处理任何信号。比如一个进程卡在D状态不可中断睡眠SIGTERM也没用只能kill -9把它从阻塞状态拉起来杀掉。不过D状态通常和磁盘IO有关如果不解决底层IO问题杀掉当前进程后新进程很可能立刻又卡进去。4.3 按名称、按用户批量终止的坑有时候我们不知道PID只知道进程名可以用pkillpkill -f python.*app.py pkill -u nginx nginx-f选项是在完整命令行中匹配而不是只匹配进程名。这样能精确打击带特定参数运行的进程但也容易误伤。比如你想杀所有命名含agent的进程结果一个日志分析脚本的命令行里也带了agent字样也被干掉了。更安全的方式是先用pgrep把PID列出来确认再决定要不要杀。我处理批量终止时习惯写一个组合命令既能看到又要干的目标又能避免误杀pgrep -af myapp pkill -f myapp先输出所有匹配项人工扫一眼确认无误后再执行pkill。两步走虽然慢一点但救了不止一次场。4.4 清理僵尸进程的正确姿势前面说过僵尸进程杀不掉只能靠父进程wait()回收。如果你发现僵尸进程很多第一件事是找到它的父进程看父进程是哪个ps -eo pid,ppid,stat,cmd | awk $3 Z这个命令输出状态为Z的进程以及各自的PID和PPID。如果父进程是systemdPID 1僵尸会很快被清理掉如果父进程是某个业务进程就得看那业务的代码逻辑里为什么没调用wait或处理子进程退出信号。有些时候父进程本身没问题只是暂时没来得及回收。这种情况下不用管它过一会儿自动就没了。我记得有一次排查僵尸进程发现是个Java程序频繁fork子进程执行外部命令但wait逻辑写在了某个不太触发分支后面导致子进程退出后父进程没机会回收最后是给程序加了shutdown hook解决的。5. systemd接管后的进程控制服务单位与资源限制现代Linux发行版基本都默认跑systemd它就是1号进程负责管理整台机器上的服务。之前讲的很多进程管理技巧到systemd这里会被“封装”到服务单位文件里。而且systemd还能做资源限制这部分和cgroup直接相关。5.1 用systemctl控制服务进程systemd把服务定义成.service文件放在/etc/systemd/system/或者/lib/systemd/system/下。日常控制服务的命令都有固定套路systemctl start my-service systemctl stop my-service systemctl restart my-service systemctl status my-servicestart和stop本质上就是把服务进程拉起来、最终发信号让它停止。但通过systemd管理相比手写启动脚本有几个优势自动处理守护进程化、自动记录日志到journald、依赖关系管理、崩溃自动重启Restart字段等。我建议所有需要开机自启的服务都优先写成systemd服务单位而不是在rc.local里塞一行启动脚本。systemd对进程的管控要严格得多包括启动超时、停止超时、进程清理都有一套标准流程。5.2 服务单位里的进程控制关键字段写一个最简单的服务单位文件大概长这样[Unit] DescriptionMy Custom App Afternetwork.target [Service] Typesimple Usermyapp ExecStart/opt/myapp/bin/start.sh ExecStop/opt/myapp/bin/stop.sh Restarton-failure RestartSec5 KillSignalSIGTERM TimeoutStopSec30 [Install] WantedBymulti-user.targetTypesimple是默认值表示ExecStart启动的进程就是主进程systemd不额外fork。KillSignal指定停止时发什么信号默认就是SIGTERM这是对的保持默认就好。TimeoutStopSec是systemd等待进程退出SIGTERM处理的最长时间超了会强制SIGKILL。如果你的服务正常停止需要超过30秒比如要等待当前请求处理完就需要调大这个值。Restarton-failure表示进程非正常退出时自动拉起是后台服务比较常用的策略。配合RestartSec避免重启太频繁导致撤销风暴这个参数在自愈机制里很重要。5.3 通过cgroup做资源限制热词里出现了“tc cgroup 按照进程控制带宽”这正好是systemd资源控制能力的延伸。cgroup最早就是用来做资源隔离和限制的systemd把cgroup的管理变得更友好直接在服务单位里声明即可[Service] MemoryMax1G CPUQuota50% TasksMax100 IOWeight10CPUQuota50%表示该服务只能使用一个CPU核心的50%计算时间MemoryMax是硬性内存上限超过会触发OOM清理TasksMax限制进程数防止某个服务fork出无限子进程拖垮系统。这些配置在Infrastructure as Code的场景里特别有用因为它们把“这个服务最多能吃多少资源”写成了可审计的配置。你要想验证这些限制是否生效可以看一下服务挂载的cgroup控制组systemd-cgls cat /sys/fs/cgroup/system.slice/my-service.service/memory.max cat /sys/fs/cgroup/system.slice/my-service.service/cpu.max通过cgroup的方式控制进程比在进程内部做自限更可靠因为即使进程失控了内核也会强制执行限制。这也是为什么现代容器技术背后都离不开cgroup。6. 排查实录进程失控、端口占用和重复执行前五部分把原理和操作说透了接下来分享几个我在实际工作中频繁遇到的场景和对应的排查手段。6.1 进程CPU飙高但找不到“凶手”场景服务器负载突然飙升top看到某个进程占用极高的CPU但进程名是一个通用的名字比如java或者nginx worker。这怎么定位我的套路是分三步走。第一步进top按H切到线程视图记录飙高线程的TID。第二步把TID转成十六进制对应的PID拿到Java的线程栈。第三步用jstack把线程栈抓出来看这个线程到底在干什么。如果是容器环境要记得先进入容器的PID命名空间再执行上面的步骤。top -H -p 12345 # 记下飙高的线程号45678 printf %x\n 45678 # 输出b26e jstack 12345 | grep -A 30 b26e如果是非Java进程比如Python或者C写的程序可以用strace跟踪它的系统调用strace -p 12345 -c -f-C参数是统计系统调用耗时-f跟随子进程。跑几秒后CtrlC看到哪个系统调用耗时最长基本就能定位到瓶颈比如频繁读取文件或等待网络IO。6.2 端口被占用又找不到对应进程很经典的一个问题启动服务时提示端口被占用但ss查不到具体进程。这种情况大概率是进程处于其他网络命名空间或者属于另一个用户的进程当前用户没有权限查看。解决办法分两种如果是权限问题用sudo ss -tulnp重新查一次如果是容器环境需要进入容器内部执行。排查命令sudo ss -tulnp | grep :8080 sudo lsof -i :8080lsof的输出会直接显示进程PID和名字。如果两个命令都查不到什么进程但还是提示端口被占用可以考虑是不是有透明代理或者iptables端口转发规则在扰局。检查sudo iptables -t nat -L -n -v6.3 防止同一个脚本被重复启动写完定时任务或者监控脚本后最怕的就是上一次没跑完下一次又开始跑两个进程同时操作同一份数据各种脏数据问题就出来了。解决办法是用flock文件锁脚本开头先抢锁抢不到就退出exec 9/var/run/my-script.lock flock -n 9 || exit 0这段代码用文件描述符9打开锁文件然后尝试非阻塞加锁。如果锁已经被持有直接退出如果加锁成功脚本继续执行。这个方案的优点是简单可靠比pid文件的方式更不容易被残留状态卡死。用pid文件的方式有个坑如果进程崩溃pid文件会残留下一次启动时会误以为进程还在。flock不会出现这种问题锁随着文件描述符的关闭自动释放。6.4 服务停止后进程仍然残留用systemctl stop某个服务发现过了一分钟进程还健在。这时候排查方向有两个第一确认Type类型和ExecStop配置——可能你的服务单位文件写的是Typeforking但服务本身不会forksystemd根本没有正确识别主进程第二检查服务是否还有子进程没被连带终止systemd虽然会终止整个cgroup内的进程但如果你的服务把子进程通过setsid脱离了控制组就管不到了。这种情况最有效的处理方式是手动清理残留进程再回头改服务单位systemctl stop my-service pgrep -af myapp | awk {print $1} | xargs kill -9 systemctl reset-failed my-service改服务单位时如果应用不支持forking就不要偷懒用Typeforking老老实实用Typesimple。如果确实需要超级管理子进程考虑用KillModecontrol-group让systemd终结所有关联进程。6.5 如何追踪进程崩溃的现场进程启动就崩退出码也没给有效信息。这时候要么看系统日志要么用coredump。systemd的journalctl可以直接按服务名过滤journalctl -u my-service -f # 实时跟踪服务日志 journalctl -u my-service --since 10 minutes ago如果想抓崩溃时的内存现场开启core dump然后复现问题ulimit -c unlimited echo /tmp/core.%e.%p /proc/sys/kernel/core_patterncore文件出来后配合gdb就可以精确看崩溃位置gdb /usr/bin/myapp /tmp/core.myapp.12345 btbt全称backtrace能打印出崩溃时的函数调用栈。有了调用栈排查进度能直接快进到业务代码层面。这些例子不是教科书式列举都是我实际踩过或者帮别人排过的场景。写进程控制这种内容最大的价值不是背命令而是理解进程背后的生命周期和信号机制。实际操作中如果你把fork/exec、SIGHUP/SIGTERM、cgroup这几个核心概念吃透了再复杂的进程问题也能拆成一路一路查下去。
阅读完成 · 觉得有帮助？
