util-linux项目中lsns命令在高负载下的异常终止问题分析

问题背景

在Linux系统管理工具集util-linux中，lsns命令用于列出系统命名空间信息。然而，在高CPU负载环境下，用户发现该命令会以状态码1异常终止，且不提供任何错误信息。经过深入分析，发现这与进程状态变化时的处理逻辑有关。

根本原因

当系统处于高负载状态时，进程创建和销毁频繁。lsns命令在遍历/proc文件系统收集进程信息时，会遇到以下关键问题：

1. 在调用fstatat或openat系统调用时，目标进程可能恰好被终止
2. 这种情况下系统调用会返回ESRCH错误（"No such process"）
3. 当前错误处理逻辑仅处理了EACCES和ENOENT，忽略了ESRCH情况
4. 导致命令异常终止并返回状态码1

技术细节

lsns命令的核心处理流程涉及两个关键函数：

1. read_processes()：遍历/proc目录获取所有进程信息
2. read_process()：读取单个进程的命名空间信息

问题出现在以下场景：

• 当lsns开始处理某个进程时，该进程仍然存在
• 但在执行fstatat/openat之前，进程被终止
• 系统调用返回ESRCH错误
• 由于未处理该错误码，导致整个命令异常终止

解决方案

修复方案相对简单但有效：在错误处理逻辑中增加对ESRCH错误码的特殊处理。具体修改包括：

1. 在read_process()函数中，将ESRCH与EACCES、ENOENT同等对待
2. 同样在read_processes()函数中进行相同修改
3. 遇到这些错误时不再终止命令执行，而是跳过当前进程继续处理

这种处理方式符合Linux/proc文件系统的特性：进程信息是动态变化的，工具应该能够容忍这种瞬态变化。

修复效果

经过修复后，lsns命令能够：

• 正确处理高负载环境下进程快速变化的场景
• 不再因进程消失而异常终止
• 保持稳定的运行状态，完整输出可用的命名空间信息

该修复已被合并到util-linux的主干代码中，并计划包含在v2.40.3和v2.41版本中发布。