1. 一块开发板的“灵魂”管理为什么进程状态是绕不开的坎“飞凌嵌入式ElfBoard-进程之进程状态”这个话题乍一看是操作系统的教科书知识点但真在嵌入式开发板上跑起来你会发现它和PC上的体验完全不一样。我最早接触ElfBoard时以为进程状态就是ps aux输出里那一列字母R、S、D、Z、T背下来就够了。直到有一次我在调试一个串口驱动的阻塞读时发现整个应用卡死ps显示进程进入了D状态而且kill -9都杀不掉才意识到进程状态不是一个“背诵题”而是一套可以指导你排查问题的“诊断语言”。这篇文章我不会从《现代操作系统》第一章开始念定义而是以ElfBoard这个具体的ARM嵌入式开发板为实验平台带着你把进程状态的分类、迁移逻辑、排查手段完整过一遍。适合正在做嵌入式Linux应用开发、或者刚入手飞凌ElfBoard想系统学习进程管理的朋友。你不需要是内核专家只要会在开发板上敲Linux命令、写过简单的C程序就能跟着复现每一个实验。先抛一个反直觉的结论你在用户态看到的“进程状态”其实只是内核为每个进程维护的一个状态机切片。它反映的不是进程“现在在干嘛”而是进程“为什么不在CPU上跑”。搞懂这一点很多诡异问题就迎刃而解了。2. 七种进程状态拆解R、S、D、T、t、Z、X到底在说什么2.1 R和S状态运行与睡眠的边界在哪里RTASK_RUNNING状态表示进程处于可运行队列中。这里有一个新手常误解的点R状态不代表进程此时此刻正占用CPU。在多核环境下ElfBoard的Cortex-A系列处理器有多个核心一个进程只要满足“有资格被调度器选中”的条件就会显示为R哪怕它正在等待CPU空闲。换句话说R状态的进程不一定在跑但它“想跑”。STASK_INTERRUPTIBLE是可中断睡眠这是嵌入式Linux里最常见的状态。进程因为等待某个事件而主动休眠比如等待网卡数据包、等待用户输入、等待定时器超时。处于S状态的进程可以被信号唤醒这也是为什么你对一个S状态的进程执行kill命令通常有效。提示如果你在ElfBoard上跑一个读串口的程序程序阻塞在read()系统调用上它大概率就是S状态。这是正常现象不是卡死。我在开发一个基于ElfBoard的RS485通信程序时就因为在主循环里用了一个阻塞读进程一直显示S状态。刚开始我怀疑是不是驱动有问题后来才明白这就是“等待事件”的标准表现。判断一个S状态进程是否健康关键是看它等待的事件是否可能到来——如果事件永远不来它就会一直睡下去表现为“程序没反应”。2.2 D状态让无数工程师头疼的不可中断睡眠DTASK_UNINTERRUPTIBLE状态是嵌入式开发中最让人紧张的状态之一。处于这个状态的进程同样是在睡眠但它不能被信号打断。设计这个状态的初衷是保护某些关键操作——最常见的是磁盘I/O、网络驱动处理数据包的过程中内核需要等待硬件完成某个动作如果这个过程中被信号打断硬件和软件的状态就可能不一致导致数据损坏。在ElfBoard上如果你的SD卡读写突然变得极慢或者某个进程出现在D状态且持续很久不消失大概率是存储子系统或者驱动出了问题。我在调试一个视频采集应用时进程就经常掉进D状态top显示它一动不动kill -9没有任何反应。后来排查发现是摄像头驱动里的某个wait_event没有超时保护硬件异常后中断没来进程就永久睡在了D状态。提示D状态进程无法被普通信号杀掉只能等内核驱动里的等待条件满足或者直接重启系统。如果频繁出现D状态且能复现优先检查驱动代码里是否有不合理的“无限等待”。2.3 T、t、Z、X暂停、跟踪与僵尸的真相TTASK_STOPPED状态是由外部信号如SIGSTOP或调试器如gdb暂停的进程。在ElfBoard上调试程序时你在gdb里按下CtrlC进程就会进入T状态。这个状态是可逆的——SIGCONT信号能让它恢复运行。tTASK_TRACED状态和T很像但它是被ptrace系统调用“冻结”的专门用于调试器跟踪。gdb设置断点后进程会处于t状态。区分T和t的小技巧ps输出中t状态通常跟在调试场景相关T则可能是sleep命令被SIGSTOP暂停。ZEXIT_ZOMBIE是僵尸状态。当你的C程序在ElfBoard上执行exit()退出后进程不会立刻消失它会先变成一个僵尸等待父进程调用wait()或waitpid()回收它的退出状态。如果父进程一直不回收僵尸进程会堆积占用内核进程表项。ElfBoard毕竟资源有限进程表项耗尽后就没法再启动新进程了。XEXIT_DEAD是真正的死亡状态只在一瞬间存在ps基本看不到。在内核源码中这个状态是进程生命周期中最后一次状态赋值随后task_struct就会被释放。3. 进程状态的迁移机制一个状态机背后的调度逻辑3.1 从“等待CPU”到“占用CPU”调度器如何驱动R状态你可能会问进程状态之间的切换究竟是“谁”在操作答案就是内核的调度器。每当系统时钟中断触发一个tick时调度器会检查当前运行进程的剩余时间片。如果时间片耗尽当前进程就会被“踢出”CPU重新回到可运行队列中状态保持R调度器再从队列里挑一个优先级最高的进程运行。在ElfBoard这样的小型嵌入式系统上调度器还做了很多精细的优化。比如使用CFS完全公平调度器时调度器会维护每个进程的虚拟运行时间。睡眠时间较长的进程一旦醒来会被补偿从而更快地获得CPU。这也是为什么你在开发板上同时跑多个任务时交互式应用比如按键响应通常比后台计算任务更“跟手”。提示进程从R状态变为S状态本质上是一次主动的“让出CPU”。系统调用如sleep()、wait()、read()等在条件不满足时都会触发调度器切换到其他进程。3.2 fork、exec、exit三大系统调用与状态流转的关系要彻底理解状态就不能不涉及进程创建和退出的路径。在ElfBoard上用C语言写程序时fork()是关键起点调用fork()后父进程会生成一个子进程。子进程刚被创建时处于可运行状态R但由于它的task_struct被插入到运行队列中具体是立刻运行还是等下一个调度周期取决于内核的调度策略。exec系列系统调用如execl、execvp不会改变进程PID但它会重新加载程序的代码段、数据段。这个过程中进程通常仍然处于R状态不会发生状态跳转。exit()系统调用执行后进程并没有立即消亡。它先调用内核里的do_exit()释放大部分资源然后把状态设置为EXIT_ZOMBIE。之后父进程调用wait()成功读取退出状态内核才会把进程彻底清理状态变为EXIT_DEAD。我建议你在ElfBoard上写一个经典“孤儿进程僵尸进程”的实验让父进程先退出子进程被init进程收养同时让子进程退出后父进程不回收。你会看到ps里出现status为Z的进程并且它一直存在。这个过程能帮你直观理解“退出不等于消失”。3.3 中断、等待队列与状态切换的微观过程再往底层走一层S状态和D状态的切换实际上和“等待队列”紧密相关。当一个进程调用sleep_on()或wait_event()时内核会把这个进程放入一个等待队列中。比如你在ElfBoard上写GPIO按键驱动时用户态程序通过poll()等待按键事件内核在驱动里就把当前进程挂进了一个等待队列然后进程进入S状态。当硬件中断发生时比如按键触发GPIO中断中断处理函数会调用wake_up()把等待队列里的进程唤醒。被唤醒的进程状态被设置为R并被放入可运行队列。这里有一个细节D状态和S状态在代码路径上的差异主要是唤醒时是否检查信号。等待队列唤醒时会调用try_to_wake_up()如果进程是TASK_INTERRUPTIBLE信号也会导致唤醒如果是TASK_UNINTERRUPTIBLE只有等待条件满足才能唤醒。注意如果你的ElfBoard驱动里用wait_event_interruptible()那么用户态进程按CtrlC是可以打断等待的如果你用wait_event()则可能按下CtrlC完全没反应。这是我在写驱动时踩过的最痛的坑之一。4. 在ElfBoard上实测进程状态三个可复现的验证实验4.1 实验环境准备宿主机构建和开发板通讯在动手之前你需要把ElfBoard和开发主机连接好。飞凌ElfBoard一般通过USB转OTG口或者以太网口与主机通信。我的实测环境如下开发板ElfBoardARM Cortex-A架构运行Linux内核宿主机Ubuntu 20.04通过串口或SSH连接开发板交叉编译工具链arm-linux-gnueabihf-gcc你要做的是写几个简单的C程序编译后传到ElfBoard上运行。如果板子已经烧录了飞凌官方的镜像通常自带gcc你甚至可以在板子上直接编译测试代码省去交叉编译的配置过程。我在测试时就图省事直接在板子上用vi写代码、用板载gcc编译效率也不低。4.2 实验一用ps和top实时观测各状态下进程的表现进入ElfBoard的终端后先运行一个简单的交互程序vi test_sleep.c#include stdio.h #include unistd.h int main(void) { printf(PID: %d\n, getpid()); while (1) { sleep(1); } return 0; }编译并在后台运行gcc -o test_sleep test_sleep.c ./test_sleep 此时执行ps -eo pid,stat,comm | grep test_sleep你会发现状态列显示为S这就是进程在等待sleep定时器到期。如果你用top看会发现该进程的CPU占用率是0%但RES内存却占了一些。再写一个死循环程序#include stdio.h int main(void) { volatile unsigned long i; while (1) { i; } return 0; }编译运行后状态会变成R。如果CPU是单核你会发现这个死循环几乎占满了一个核心的CPU时间。此时再开一个终端执行top按P键按CPU排序会看到这个R状态进程排在前面。提示R状态进程不一定代表“系统有问题”。如果你的产品里有一个后台数据采集任务长期占用CPU并保持R状态只要它在设计范围内就是正常的。关键是要区分“长时间R状态”和“长时间D状态”前者可能是计算密集后者多半是等待I/O异常。4.3 实验二构造一个D状态进程观察“杀不死”的现象构造D状态进程稍微麻烦一点因为普通用户态程序很难直接进入不可中断睡眠。最简单的方式是使用内核线程或者驱动中的等待。但如果你不想写驱动还有一个技巧在ElfBoard上挂载一个慢速的NFS目录然后从NFS读取大量数据进程有可能因为NFS的I/O阻塞进入D状态。由于NFS服务端响应慢内核的nfs_wait_event会让进程处于TASK_UNINTERRUPTIBLE。我在验证过程中用这种方式让一个dd进程进入了D状态持续了十几秒。其间执行kill -9ps显示进程仍然存在。恢复方法是等NFS服务端响应返回进程才会继续往下走。如果你的ElfBoard没有NFS环境也可以用fio之类的工具模拟磁盘压力同样可能触发D状态。注意D状态持续过久通常是系统级故障的前兆。比如SD卡底层驱动有bug、存储介质坏块导致反复重试、网络文件系统服务端失联等。在ElfBoard的日志里如果伴随有task blocked more than 120 seconds的告警基本可以断定有进程陷入D状态超时。4.4 实验三制造僵尸进程并验证信号与回收机制僵尸进程的制造方法非常简单下面这个程序会让父进程处于无限循环不回收子进程#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { printf(child process exit\n); _exit(0); } else { while (1) { sleep(1); } } return 0; }编译运行后用ps查看./test_zombie ps -eo pid,ppid,stat,comm | grep test_zombie你会看到子进程的状态是Z父进程状态是S。此时就算你用kill -9去杀僵尸进程也会提示“kill: (PID) - No such process”因为它实际上已经死了只是残留了内核进程表项。要清除僵尸进程你需要让父进程调用waitpid()或者直接结束父进程这样僵尸进程会被init进程收养并回收。提示如果你的ElfBoard长期运行某个守护进程而这个守护进程没有妥善处理子进程退出僵尸进程就会越积越多。曾见过一个设备在连续运行一周后ps输出里全是Z状态新的业务进程无法创建系统“假死”。这种问题从进程状态入手排查五分钟就能定位。5. 进程状态视角下的开发板实战陷阱与排查心得5.1 驱动挂起导致D状态堆积如何定位到底层模块在开发板上遇到大量D状态进程时第一反应不应是“杀进程”而是先查内核日志。dmesg | tail -50如果看到task: xxx blocked for more than 120 seconds之类信息通常会附上调用栈里面会显示进程阻塞在内核的哪个函数上。比如wait_on_bit、lock_page、nfs_wait_event等。根据调用栈就能大致判断是文件系统、块设备驱动还是网络驱动的问题。我之前调试ElfBoard的SD卡驱动时遇到过一种情况进程在mmc_wait_for_req上卡住状态进入D。这是因为SD卡在坏块重试时底层驱动没有设置超时导致mmc_wait_for_req永远在等待传输完成。解决办法是在设备树里为mmc节点增加max-frequency限制并且检查驱动中的超时逻辑。注意排查D状态问题时echo w /proc/sysrq-trigger可以触发内核打印所有进程的栈回溯这是我在嵌入式环境下比较常用的诊断手段。它会在内核日志里输出当前所有TASK_UNINTERRUPTIBLE状态进程的堆栈信息能直接看到它们阻塞在哪里。5.2 后台脚本进程的S/T状态切换一个真实的产品运维案例在部署基于ElfBoard的边缘计算节点时我习惯用Shell脚本拉起多个业务进程。Shell脚本本身通常是S状态它等待子进程退出后继续执行。如果你用kill -STOP PID去暂停某个业务进程脚本可能会因为等待该进程退出而进入T状态。记得有一次现场工程师反馈设备无法远程登录。我通过串口连上去后发现一个服务进程状态是Tps显示它被SIGSTOP暂停了。追查历史命令发现是之前手动测试信号机制时kill -STOP命令没有在测试结束后恢复导致服务一直挂着。这个问题非常隐蔽因为top默认不会高亮显示T状态进程如果你只看CPU占用率根本发现不了。提示在ElfBoard上进行信号实验时务必养成用kill -CONT PID恢复进程的习惯并在脚本里加入超时自动恢复逻辑。否则一个暂停的进程可能会让整个业务链瘫痪。5.3 busybox工具的局限性与替代方案飞凌ElfBoard的官方文件系统通常使用busybox来提供基本的shell工具。busybox版本较老时ps命令可能不支持-o自定义输出列或者默认不显示STAT列给查看进程状态带来不便。我的做法是优先用top -b -n 1它会输出当前所有进程的PID、STAT、CPU、MEM信息且busybox自带支持。如果一定需要自定义输出可以考虑在开发板上安装完整版的procps工具包或者直接使用/proc/pid/status文件来查看进程的State字段cat /proc/1234/status | grep State输出为State: S (sleeping)这比ps的输出更直接尤其在内核线程上/proc/pid/status还会显示更多上下文信息。提示/proc/pid/stat中的字段是空格分隔的但进程名可能包含空格所以用脚本解析时不要按split简单切分建议读/proc/pid/status更可靠。6. 从进程状态延伸为ElfBoard打开第二个网口的完整操作6.1 为什么要给ElfBoard扩展第二个网口聊完了进程状态有人可能觉得这和网络接口不搭界。实际上在嵌入式设备上扩展网口是常见的硬件需求尤其是在做网关、数据采集器时。进程状态排查和网络接口配置都属于系统集成的底层能力。我在这个项目里同时用到两个网口一个连接内网传感器一个连接外网服务器。如果网口初始化失败相关网络进程的状态会一直停留在S状态无法进入正常的收发循环。所以这里分享一下打开第二个网口的完整操作。飞凌ElfBoard的硬件上通常预留了以太网控制器接口。以某个配置为例主控芯片本身集成两路MAC但板卡默认只引出了一路千兆以太网口。要启用第二路网口大致分三步内核配置、设备树配置、用户态网络配置。6.2 设备树中的网口节点配置以dts为例打开ElfBoard的出厂设备树文件通常位于内核源码的arch/arm/boot/dts/目录下找到与以太网相关的节点。飞凌ElfBoard不同型号的节点名可能不同常见的有ethernet开头的节点。你需要确认第二路网口的控制器节点是否被禁用。设备树中通常用status disabled来关闭默认不使用的网口。例如macb1 { status okay; pinctrl-0 pinctrl_macb1_default; phy-mode rgmii; phy-handle phy1; };注意还要确保引脚复用pinctrl配置正确。如果第二路网口的引脚被复用成了GPIO或者其他功能网络就无法工作。飞凌的开发板资料里有详细的引脚功能对照表你需要把对应引脚配置成以太网功能。注意设备树修改后必须重新编译设备树内核或者使用单独的dtb文件不要直接改运行中的设备树。6.3 内核配置选项确认MAC控制器驱动已编译在ElfBoard上打开第二个网口之前最好先检查当前内核是否已经包含对应网口控制器的驱动。执行zcat /proc/config.gz | grep -i macb如果你的内核没有开启CONFIG_MACB就需要重新编译内核。在飞凌的SDK里执行menuconfigmake menuconfig进入Device Drivers - Network device support - Ethernet driver support找到对应的MAC控制器驱动比如Cadence MACB勾选为*。确认后重新编译内核和设备树烧录到开发板。提示如果你不希望重新刷写整个内核可以只更新dtb文件。但前提是内核本身已经包含驱动否则只更新设备树是没用的。6.4 用户态网络配置让第二个网口真正活起来内核和设备树就位后启动ElfBoard使用ifconfig -a查看是否出现eth1或类似的接口名。如果接口存在但IP没配置可以手动设置ifconfig eth1 up ifconfig eth1 192.168.2.100 netmask 255.255.255.0如果希望开机自动配置可以在/etc/network/interfaces中增加auto eth1 iface eth1 inet static address 192.168.2.100 netmask 255.255.255.0配置完成后用一个网线把开发板的第二网口连接到电脑互相ping一下验证连通性。6.5 网口初始化失败的排查链路我在配置第二网口时遇到过接口识别不到的情况。排查链路如下第一步确认设备树节点状态。如果忘了把status从disabled改成okay内核不会注册对应的网络设备。这一步最容易被遗漏。第二步检查引脚复用冲突。如果你把同一组引脚既配成了串口功能又配成了网口功能内核会报pin conflict错误。可以通过内核启动日志dmesg | grep pin来确认。第三步检查PHY芯片的复位GPIO。有些网口的PHY芯片需要先被复位才能正确检测到。设备树里的phy-reset-gpios如果不正确网口会一直处于无连接link down状态。第四步确认PHY地址。如果两个网口共用同一个MDIO总线而PHY地址相同就会冲突。这是双网口配置最常见的坑。查看PHY驱动里配置的地址确保两个PHY使用不同地址。提示网络接口配置好后进程状态监测也要跟上。跨网口传输数据时如果进程长期处于S状态且/proc/net/dev上的字节数不增长大概率是硬件中断配置问题而不是应用代码问题。7. 写在进程状态和网口之后一点个人经验在飞凌ElfBoard上玩进程状态实际上是在通过一个“快照”理解内核的调度和同步机制。你看到的每一个D状态、Z状态背后都可能对应着一个驱动模型的问题、一段需要等待的I/O、一个没有正确回收的父进程。说实话这些知识在PC上很难感受到因为PC的资源和性能掩盖了很多底层行为而在开发板上资源有限、场景明确每一个状态变化都能被放大、感知、复现。再分享一个我自己常用的习惯每次在ElfBoard上启动一套新业务后我都会写一个定时巡检脚本捕获ps -eo pid,stat,comm的输出记录到本地日志。一旦线上出现“进程假死”之类的反馈翻出历史日志对比状态变化曲线很多时候一眼就能看出是哪个进程先进入了非正常状态。这个方法不复杂但真到排查问题时比临时翻内核日志高效得多。最后需要再强调一次进程中出现的S状态不一定是坏事D状态不一定是系统要崩Z状态也不一定需要立刻处理。搞清楚状态背后的等待条件、事件来源、回收路径才是真正理解“进程之进程状态”的意义所在。希望这篇基于ElfBoard的实战拆解能帮你在自己的开发板上少踩几个坑。
嵌入式Linux进程状态全解析：从R/S/D/Z到ElfBoard实战排查
1. 一块开发板的“灵魂”管理为什么进程状态是绕不开的坎“飞凌嵌入式ElfBoard-进程之进程状态”这个话题乍一看是操作系统的教科书知识点但真在嵌入式开发板上跑起来你会发现它和PC上的体验完全不一样。我最早接触ElfBoard时以为进程状态就是ps aux输出里那一列字母R、S、D、Z、T背下来就够了。直到有一次我在调试一个串口驱动的阻塞读时发现整个应用卡死ps显示进程进入了D状态而且kill -9都杀不掉才意识到进程状态不是一个“背诵题”而是一套可以指导你排查问题的“诊断语言”。这篇文章我不会从《现代操作系统》第一章开始念定义而是以ElfBoard这个具体的ARM嵌入式开发板为实验平台带着你把进程状态的分类、迁移逻辑、排查手段完整过一遍。适合正在做嵌入式Linux应用开发、或者刚入手飞凌ElfBoard想系统学习进程管理的朋友。你不需要是内核专家只要会在开发板上敲Linux命令、写过简单的C程序就能跟着复现每一个实验。先抛一个反直觉的结论你在用户态看到的“进程状态”其实只是内核为每个进程维护的一个状态机切片。它反映的不是进程“现在在干嘛”而是进程“为什么不在CPU上跑”。搞懂这一点很多诡异问题就迎刃而解了。2. 七种进程状态拆解R、S、D、T、t、Z、X到底在说什么2.1 R和S状态运行与睡眠的边界在哪里RTASK_RUNNING状态表示进程处于可运行队列中。这里有一个新手常误解的点R状态不代表进程此时此刻正占用CPU。在多核环境下ElfBoard的Cortex-A系列处理器有多个核心一个进程只要满足“有资格被调度器选中”的条件就会显示为R哪怕它正在等待CPU空闲。换句话说R状态的进程不一定在跑但它“想跑”。STASK_INTERRUPTIBLE是可中断睡眠这是嵌入式Linux里最常见的状态。进程因为等待某个事件而主动休眠比如等待网卡数据包、等待用户输入、等待定时器超时。处于S状态的进程可以被信号唤醒这也是为什么你对一个S状态的进程执行kill命令通常有效。提示如果你在ElfBoard上跑一个读串口的程序程序阻塞在read()系统调用上它大概率就是S状态。这是正常现象不是卡死。我在开发一个基于ElfBoard的RS485通信程序时就因为在主循环里用了一个阻塞读进程一直显示S状态。刚开始我怀疑是不是驱动有问题后来才明白这就是“等待事件”的标准表现。判断一个S状态进程是否健康关键是看它等待的事件是否可能到来——如果事件永远不来它就会一直睡下去表现为“程序没反应”。2.2 D状态让无数工程师头疼的不可中断睡眠DTASK_UNINTERRUPTIBLE状态是嵌入式开发中最让人紧张的状态之一。处于这个状态的进程同样是在睡眠但它不能被信号打断。设计这个状态的初衷是保护某些关键操作——最常见的是磁盘I/O、网络驱动处理数据包的过程中内核需要等待硬件完成某个动作如果这个过程中被信号打断硬件和软件的状态就可能不一致导致数据损坏。在ElfBoard上如果你的SD卡读写突然变得极慢或者某个进程出现在D状态且持续很久不消失大概率是存储子系统或者驱动出了问题。我在调试一个视频采集应用时进程就经常掉进D状态top显示它一动不动kill -9没有任何反应。后来排查发现是摄像头驱动里的某个wait_event没有超时保护硬件异常后中断没来进程就永久睡在了D状态。提示D状态进程无法被普通信号杀掉只能等内核驱动里的等待条件满足或者直接重启系统。如果频繁出现D状态且能复现优先检查驱动代码里是否有不合理的“无限等待”。2.3 T、t、Z、X暂停、跟踪与僵尸的真相TTASK_STOPPED状态是由外部信号如SIGSTOP或调试器如gdb暂停的进程。在ElfBoard上调试程序时你在gdb里按下CtrlC进程就会进入T状态。这个状态是可逆的——SIGCONT信号能让它恢复运行。tTASK_TRACED状态和T很像但它是被ptrace系统调用“冻结”的专门用于调试器跟踪。gdb设置断点后进程会处于t状态。区分T和t的小技巧ps输出中t状态通常跟在调试场景相关T则可能是sleep命令被SIGSTOP暂停。ZEXIT_ZOMBIE是僵尸状态。当你的C程序在ElfBoard上执行exit()退出后进程不会立刻消失它会先变成一个僵尸等待父进程调用wait()或waitpid()回收它的退出状态。如果父进程一直不回收僵尸进程会堆积占用内核进程表项。ElfBoard毕竟资源有限进程表项耗尽后就没法再启动新进程了。XEXIT_DEAD是真正的死亡状态只在一瞬间存在ps基本看不到。在内核源码中这个状态是进程生命周期中最后一次状态赋值随后task_struct就会被释放。3. 进程状态的迁移机制一个状态机背后的调度逻辑3.1 从“等待CPU”到“占用CPU”调度器如何驱动R状态你可能会问进程状态之间的切换究竟是“谁”在操作答案就是内核的调度器。每当系统时钟中断触发一个tick时调度器会检查当前运行进程的剩余时间片。如果时间片耗尽当前进程就会被“踢出”CPU重新回到可运行队列中状态保持R调度器再从队列里挑一个优先级最高的进程运行。在ElfBoard这样的小型嵌入式系统上调度器还做了很多精细的优化。比如使用CFS完全公平调度器时调度器会维护每个进程的虚拟运行时间。睡眠时间较长的进程一旦醒来会被补偿从而更快地获得CPU。这也是为什么你在开发板上同时跑多个任务时交互式应用比如按键响应通常比后台计算任务更“跟手”。提示进程从R状态变为S状态本质上是一次主动的“让出CPU”。系统调用如sleep()、wait()、read()等在条件不满足时都会触发调度器切换到其他进程。3.2 fork、exec、exit三大系统调用与状态流转的关系要彻底理解状态就不能不涉及进程创建和退出的路径。在ElfBoard上用C语言写程序时fork()是关键起点调用fork()后父进程会生成一个子进程。子进程刚被创建时处于可运行状态R但由于它的task_struct被插入到运行队列中具体是立刻运行还是等下一个调度周期取决于内核的调度策略。exec系列系统调用如execl、execvp不会改变进程PID但它会重新加载程序的代码段、数据段。这个过程中进程通常仍然处于R状态不会发生状态跳转。exit()系统调用执行后进程并没有立即消亡。它先调用内核里的do_exit()释放大部分资源然后把状态设置为EXIT_ZOMBIE。之后父进程调用wait()成功读取退出状态内核才会把进程彻底清理状态变为EXIT_DEAD。我建议你在ElfBoard上写一个经典“孤儿进程僵尸进程”的实验让父进程先退出子进程被init进程收养同时让子进程退出后父进程不回收。你会看到ps里出现status为Z的进程并且它一直存在。这个过程能帮你直观理解“退出不等于消失”。3.3 中断、等待队列与状态切换的微观过程再往底层走一层S状态和D状态的切换实际上和“等待队列”紧密相关。当一个进程调用sleep_on()或wait_event()时内核会把这个进程放入一个等待队列中。比如你在ElfBoard上写GPIO按键驱动时用户态程序通过poll()等待按键事件内核在驱动里就把当前进程挂进了一个等待队列然后进程进入S状态。当硬件中断发生时比如按键触发GPIO中断中断处理函数会调用wake_up()把等待队列里的进程唤醒。被唤醒的进程状态被设置为R并被放入可运行队列。这里有一个细节D状态和S状态在代码路径上的差异主要是唤醒时是否检查信号。等待队列唤醒时会调用try_to_wake_up()如果进程是TASK_INTERRUPTIBLE信号也会导致唤醒如果是TASK_UNINTERRUPTIBLE只有等待条件满足才能唤醒。注意如果你的ElfBoard驱动里用wait_event_interruptible()那么用户态进程按CtrlC是可以打断等待的如果你用wait_event()则可能按下CtrlC完全没反应。这是我在写驱动时踩过的最痛的坑之一。4. 在ElfBoard上实测进程状态三个可复现的验证实验4.1 实验环境准备宿主机构建和开发板通讯在动手之前你需要把ElfBoard和开发主机连接好。飞凌ElfBoard一般通过USB转OTG口或者以太网口与主机通信。我的实测环境如下开发板ElfBoardARM Cortex-A架构运行Linux内核宿主机Ubuntu 20.04通过串口或SSH连接开发板交叉编译工具链arm-linux-gnueabihf-gcc你要做的是写几个简单的C程序编译后传到ElfBoard上运行。如果板子已经烧录了飞凌官方的镜像通常自带gcc你甚至可以在板子上直接编译测试代码省去交叉编译的配置过程。我在测试时就图省事直接在板子上用vi写代码、用板载gcc编译效率也不低。4.2 实验一用ps和top实时观测各状态下进程的表现进入ElfBoard的终端后先运行一个简单的交互程序vi test_sleep.c#include stdio.h #include unistd.h int main(void) { printf(PID: %d\n, getpid()); while (1) { sleep(1); } return 0; }编译并在后台运行gcc -o test_sleep test_sleep.c ./test_sleep 此时执行ps -eo pid,stat,comm | grep test_sleep你会发现状态列显示为S这就是进程在等待sleep定时器到期。如果你用top看会发现该进程的CPU占用率是0%但RES内存却占了一些。再写一个死循环程序#include stdio.h int main(void) { volatile unsigned long i; while (1) { i; } return 0; }编译运行后状态会变成R。如果CPU是单核你会发现这个死循环几乎占满了一个核心的CPU时间。此时再开一个终端执行top按P键按CPU排序会看到这个R状态进程排在前面。提示R状态进程不一定代表“系统有问题”。如果你的产品里有一个后台数据采集任务长期占用CPU并保持R状态只要它在设计范围内就是正常的。关键是要区分“长时间R状态”和“长时间D状态”前者可能是计算密集后者多半是等待I/O异常。4.3 实验二构造一个D状态进程观察“杀不死”的现象构造D状态进程稍微麻烦一点因为普通用户态程序很难直接进入不可中断睡眠。最简单的方式是使用内核线程或者驱动中的等待。但如果你不想写驱动还有一个技巧在ElfBoard上挂载一个慢速的NFS目录然后从NFS读取大量数据进程有可能因为NFS的I/O阻塞进入D状态。由于NFS服务端响应慢内核的nfs_wait_event会让进程处于TASK_UNINTERRUPTIBLE。我在验证过程中用这种方式让一个dd进程进入了D状态持续了十几秒。其间执行kill -9ps显示进程仍然存在。恢复方法是等NFS服务端响应返回进程才会继续往下走。如果你的ElfBoard没有NFS环境也可以用fio之类的工具模拟磁盘压力同样可能触发D状态。注意D状态持续过久通常是系统级故障的前兆。比如SD卡底层驱动有bug、存储介质坏块导致反复重试、网络文件系统服务端失联等。在ElfBoard的日志里如果伴随有task blocked more than 120 seconds的告警基本可以断定有进程陷入D状态超时。4.4 实验三制造僵尸进程并验证信号与回收机制僵尸进程的制造方法非常简单下面这个程序会让父进程处于无限循环不回收子进程#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { printf(child process exit\n); _exit(0); } else { while (1) { sleep(1); } } return 0; }编译运行后用ps查看./test_zombie ps -eo pid,ppid,stat,comm | grep test_zombie你会看到子进程的状态是Z父进程状态是S。此时就算你用kill -9去杀僵尸进程也会提示“kill: (PID) - No such process”因为它实际上已经死了只是残留了内核进程表项。要清除僵尸进程你需要让父进程调用waitpid()或者直接结束父进程这样僵尸进程会被init进程收养并回收。提示如果你的ElfBoard长期运行某个守护进程而这个守护进程没有妥善处理子进程退出僵尸进程就会越积越多。曾见过一个设备在连续运行一周后ps输出里全是Z状态新的业务进程无法创建系统“假死”。这种问题从进程状态入手排查五分钟就能定位。5. 进程状态视角下的开发板实战陷阱与排查心得5.1 驱动挂起导致D状态堆积如何定位到底层模块在开发板上遇到大量D状态进程时第一反应不应是“杀进程”而是先查内核日志。dmesg | tail -50如果看到task: xxx blocked for more than 120 seconds之类信息通常会附上调用栈里面会显示进程阻塞在内核的哪个函数上。比如wait_on_bit、lock_page、nfs_wait_event等。根据调用栈就能大致判断是文件系统、块设备驱动还是网络驱动的问题。我之前调试ElfBoard的SD卡驱动时遇到过一种情况进程在mmc_wait_for_req上卡住状态进入D。这是因为SD卡在坏块重试时底层驱动没有设置超时导致mmc_wait_for_req永远在等待传输完成。解决办法是在设备树里为mmc节点增加max-frequency限制并且检查驱动中的超时逻辑。注意排查D状态问题时echo w /proc/sysrq-trigger可以触发内核打印所有进程的栈回溯这是我在嵌入式环境下比较常用的诊断手段。它会在内核日志里输出当前所有TASK_UNINTERRUPTIBLE状态进程的堆栈信息能直接看到它们阻塞在哪里。5.2 后台脚本进程的S/T状态切换一个真实的产品运维案例在部署基于ElfBoard的边缘计算节点时我习惯用Shell脚本拉起多个业务进程。Shell脚本本身通常是S状态它等待子进程退出后继续执行。如果你用kill -STOP PID去暂停某个业务进程脚本可能会因为等待该进程退出而进入T状态。记得有一次现场工程师反馈设备无法远程登录。我通过串口连上去后发现一个服务进程状态是Tps显示它被SIGSTOP暂停了。追查历史命令发现是之前手动测试信号机制时kill -STOP命令没有在测试结束后恢复导致服务一直挂着。这个问题非常隐蔽因为top默认不会高亮显示T状态进程如果你只看CPU占用率根本发现不了。提示在ElfBoard上进行信号实验时务必养成用kill -CONT PID恢复进程的习惯并在脚本里加入超时自动恢复逻辑。否则一个暂停的进程可能会让整个业务链瘫痪。5.3 busybox工具的局限性与替代方案飞凌ElfBoard的官方文件系统通常使用busybox来提供基本的shell工具。busybox版本较老时ps命令可能不支持-o自定义输出列或者默认不显示STAT列给查看进程状态带来不便。我的做法是优先用top -b -n 1它会输出当前所有进程的PID、STAT、CPU、MEM信息且busybox自带支持。如果一定需要自定义输出可以考虑在开发板上安装完整版的procps工具包或者直接使用/proc/pid/status文件来查看进程的State字段cat /proc/1234/status | grep State输出为State: S (sleeping)这比ps的输出更直接尤其在内核线程上/proc/pid/status还会显示更多上下文信息。提示/proc/pid/stat中的字段是空格分隔的但进程名可能包含空格所以用脚本解析时不要按split简单切分建议读/proc/pid/status更可靠。6. 从进程状态延伸为ElfBoard打开第二个网口的完整操作6.1 为什么要给ElfBoard扩展第二个网口聊完了进程状态有人可能觉得这和网络接口不搭界。实际上在嵌入式设备上扩展网口是常见的硬件需求尤其是在做网关、数据采集器时。进程状态排查和网络接口配置都属于系统集成的底层能力。我在这个项目里同时用到两个网口一个连接内网传感器一个连接外网服务器。如果网口初始化失败相关网络进程的状态会一直停留在S状态无法进入正常的收发循环。所以这里分享一下打开第二个网口的完整操作。飞凌ElfBoard的硬件上通常预留了以太网控制器接口。以某个配置为例主控芯片本身集成两路MAC但板卡默认只引出了一路千兆以太网口。要启用第二路网口大致分三步内核配置、设备树配置、用户态网络配置。6.2 设备树中的网口节点配置以dts为例打开ElfBoard的出厂设备树文件通常位于内核源码的arch/arm/boot/dts/目录下找到与以太网相关的节点。飞凌ElfBoard不同型号的节点名可能不同常见的有ethernet开头的节点。你需要确认第二路网口的控制器节点是否被禁用。设备树中通常用status disabled来关闭默认不使用的网口。例如macb1 { status okay; pinctrl-0 pinctrl_macb1_default; phy-mode rgmii; phy-handle phy1; };注意还要确保引脚复用pinctrl配置正确。如果第二路网口的引脚被复用成了GPIO或者其他功能网络就无法工作。飞凌的开发板资料里有详细的引脚功能对照表你需要把对应引脚配置成以太网功能。注意设备树修改后必须重新编译设备树内核或者使用单独的dtb文件不要直接改运行中的设备树。6.3 内核配置选项确认MAC控制器驱动已编译在ElfBoard上打开第二个网口之前最好先检查当前内核是否已经包含对应网口控制器的驱动。执行zcat /proc/config.gz | grep -i macb如果你的内核没有开启CONFIG_MACB就需要重新编译内核。在飞凌的SDK里执行menuconfigmake menuconfig进入Device Drivers - Network device support - Ethernet driver support找到对应的MAC控制器驱动比如Cadence MACB勾选为*。确认后重新编译内核和设备树烧录到开发板。提示如果你不希望重新刷写整个内核可以只更新dtb文件。但前提是内核本身已经包含驱动否则只更新设备树是没用的。6.4 用户态网络配置让第二个网口真正活起来内核和设备树就位后启动ElfBoard使用ifconfig -a查看是否出现eth1或类似的接口名。如果接口存在但IP没配置可以手动设置ifconfig eth1 up ifconfig eth1 192.168.2.100 netmask 255.255.255.0如果希望开机自动配置可以在/etc/network/interfaces中增加auto eth1 iface eth1 inet static address 192.168.2.100 netmask 255.255.255.0配置完成后用一个网线把开发板的第二网口连接到电脑互相ping一下验证连通性。6.5 网口初始化失败的排查链路我在配置第二网口时遇到过接口识别不到的情况。排查链路如下第一步确认设备树节点状态。如果忘了把status从disabled改成okay内核不会注册对应的网络设备。这一步最容易被遗漏。第二步检查引脚复用冲突。如果你把同一组引脚既配成了串口功能又配成了网口功能内核会报pin conflict错误。可以通过内核启动日志dmesg | grep pin来确认。第三步检查PHY芯片的复位GPIO。有些网口的PHY芯片需要先被复位才能正确检测到。设备树里的phy-reset-gpios如果不正确网口会一直处于无连接link down状态。第四步确认PHY地址。如果两个网口共用同一个MDIO总线而PHY地址相同就会冲突。这是双网口配置最常见的坑。查看PHY驱动里配置的地址确保两个PHY使用不同地址。提示网络接口配置好后进程状态监测也要跟上。跨网口传输数据时如果进程长期处于S状态且/proc/net/dev上的字节数不增长大概率是硬件中断配置问题而不是应用代码问题。7. 写在进程状态和网口之后一点个人经验在飞凌ElfBoard上玩进程状态实际上是在通过一个“快照”理解内核的调度和同步机制。你看到的每一个D状态、Z状态背后都可能对应着一个驱动模型的问题、一段需要等待的I/O、一个没有正确回收的父进程。说实话这些知识在PC上很难感受到因为PC的资源和性能掩盖了很多底层行为而在开发板上资源有限、场景明确每一个状态变化都能被放大、感知、复现。再分享一个我自己常用的习惯每次在ElfBoard上启动一套新业务后我都会写一个定时巡检脚本捕获ps -eo pid,stat,comm的输出记录到本地日志。一旦线上出现“进程假死”之类的反馈翻出历史日志对比状态变化曲线很多时候一眼就能看出是哪个进程先进入了非正常状态。这个方法不复杂但真到排查问题时比临时翻内核日志高效得多。最后需要再强调一次进程中出现的S状态不一定是坏事D状态不一定是系统要崩Z状态也不一定需要立刻处理。搞清楚状态背后的等待条件、事件来源、回收路径才是真正理解“进程之进程状态”的意义所在。希望这篇基于ElfBoard的实战拆解能帮你在自己的开发板上少踩几个坑。
