RK3588 上 bash 进程 CPU 占满 99%

RK3588 上 bash 进程 CPU 占满 99%？串口终端忙等问题排查实录

问题现象

最近在 Orange Pi 5 Max（RK3588 芯片）上遇到一个诡异的问题：系统明明啥也没跑，top 一看却有个 bash 进程 CPU 占用高达 99.3%，状态一直是 R（运行中），活活占满了一个核心。

RK3588 是 8 核大小核架构（4×A55 + 4×A76），单进程 99% CPU 意味着它占满了单个核心，而不是系统整体满载。但问题是——一个普通的 bash 怎么会吃这么多 CPU？

排查过程

第一步：用 top 锁定异常进程

首先通过 top 确认了 PID 为 2769 的 bash 进程是罪魁祸首，用户是 root，CPU 占用 99.3%，状态持续为 R。

初步怀疑是死循环脚本，但转念一想：如果是脚本在跑，通常会有子进程，或者 bash 会调用其他命令。而这里只有一个孤零零的 bash，不太像正常的脚本执行。

第二步：用 lsof 深挖文件描述符

为了搞清楚这个 bash 到底在做什么，我用 lsof 查看了它打开的文件描述符：

sudo lsof -p 2769

输出结果的关键信息是：所有标准文件描述符（0/1/2/255）都绑定到了 /dev/ttyS2——这是串口终端设备。

bash    2769 root    0u   CHR   4,66      0t0    92 /dev/ttyS2
bash    2769 root    1u   CHR   4,66      0t0    92 /dev/ttyS2
bash    2769 root    2u   CHR   4,66      0t0    92 /dev/ttyS2
bash    2769 root  255u   CHR   4,66      0t0    92 /dev/ttyS2

这说明这个 bash 不是 SSH 登录的 shell，而是通过串口 ttyS2 登录的 root 终端。

第三步：根本原因——串口终端忙等

结合现象和 lsof 的输出，原因就很清晰了：

串口终端异常断开，但 bash 进程没有正常退出，陷入了忙等（busy-wait）循环。

具体来说，当串口硬件连接异常断开（比如串口线松动、接触不良），或者串口参数不匹配导致通信失败时，bash 会反复尝试读写已经"死掉"的串口设备：

• read(0, ...) 尝试从串口读输入，立刻返回错误

• write(1, ...) 尝试输出提示符，也立刻返回错误

• 内核返回错误后，bash 又立刻重试，中间没有任何阻塞或休眠

这种无阻塞的无限重试，就是典型的"忙等"，直接把一个核心跑满。

为什么会出现 root 用户的串口 shell？因为 Orange Pi 默认开启了 [email protected] 服务，允许通过串口登录系统。如果之前有人通过串口登录过 root，之后串口连接异常断开，就可能留下这个"僵尸"bash 进程。

解决方法

快速解决：直接杀掉异常进程

最简单粗暴的方法，直接 kill -9 干掉这个进程：

sudo kill -9 2769

执行后再看 top，CPU 占用会立刻降下来，问题当场解决。

但这只是治标不治本——如果串口登录服务还在，下次还可能出现同样的问题。

彻底根治：禁用串口登录服务

如果你不需要通过串口登录系统（大多数人都是用 SSH 或者桌面），建议直接禁用串口登录服务，从根源上避免问题复现：

# 停止串口登录服务
sudo systemctl stop [email protected]

# 禁用开机自启
sudo systemctl disable [email protected]

# 屏蔽服务，防止被其他依赖意外启动
sudo systemctl mask [email protected]

如果需要确认有哪些串口服务在运行，可以用：

systemctl list-units | grep serial

验证手段：用 strace 确认忙等

如果你想亲眼确认这个 bash 确实在疯狂读写串口，可以用 strace 跟踪系统调用：

sudo strace -p 2769

你会看到它反复执行 read() 和 write()，每次都立刻返回错误（比如 -1 EIO），中间没有任何 nanosleep 或 select 阻塞调用——这就是典型的忙等循环铁证。

经验总结

这次排查给了我几个启发：

1. 嵌入式设备上的"幽灵"进程，先查串口。ARM 开发板通常默认开启串口登录，异常断开很容易留下忙等进程。

2. lsof 是排查进程行为的利器。通过文件描述符就能快速判断进程是在读写文件、网络还是终端设备。

3. 单进程 100% CPU 不一定是计算密集型任务。死循环、忙等、I/O 异常都可能导致 CPU 占满，不要上来就怀疑是算法问题。

4. 不需要的服务就关掉。串口登录、蓝牙、HDMI 这些不用的服务，禁用后既能减少安全隐患，也能避免这类诡异问题。

如果你也在 RK3588 或者其他 ARM 开发板上遇到类似的"啥也没干但 CPU 很高"的问题，不妨先检查一下是不是串口终端在搞鬼。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/tsuibeyond/article/details/162796869