为什么现代系统正在逐渐弃用 /proc 伪文件系统

Why People Have Moved Away from Using /proc for Everything

文章背景与核心概要

在 Unix 和 Linux 发展的黄金年代，/proc 伪文件系统 (Pseudo-filesystem) 曾作为“一切皆文件”设计哲学的典范之作，让开发者能够像读取普通文本一样轻松探查内核数据与进程状态。然而，随着现代系统对极高吞吐、严格安全隔离与微秒级响应的要求不断提升，这种严重依赖文本格式转换与文件描述符 (File Descriptor, FD) 的机制逐渐显露出性能开销大、描述符易耗尽以及缺乏原子性等硬伤。现代操作系统正逐步转向更轻量、高效且原子的直接系统调用 (System Call)。本文深入剖析了这一变迁背后的技术演进脉络与工程权衡。

概要

Summary

虽然 /proc 伪文件系统曾是一项革命性的 Unix 创新，它为向外暴露进程与系统信息提供了前所未有的便利，但现代操作系统正在越来越多地转向使用直接系统调用来取代它。尽管 /proc 具有便于人类阅读和易于编写脚本的巨大优势，但在实际生产环境中，它却在性能 (源于文本格式转换和沉重的文件描述符开销)、可靠性 (例如资源耗尽与原子性保障缺失) 以及安全性 (增加了构建安全沙箱与 chroot 隔离环境的复杂性) 等方面带来了不容忽视的严峻挑战。

While the /proc pseudo-filesystem was a revolutionary Unix innovation for exposing process and system information, modern systems are increasingly replacing it with direct system calls. Despite its convenience for human readability and simple scripting, /proc presents significant real-world challenges in performance (due to text formatting and heavy file-descriptor overhead), reliability (such as resource exhaustion and atomicity issues), and security (complicating sandboxing and chroot environments).

/proc 的兴盛与退潮

The Rise and Fall of /proc

Unix 体系中最精妙的构想之一，莫过于 /proc 伪文件系统 (该设计最早源自 Research Unix)。它最初被创建用于对外暴露进程内部状态，以作为传统 ptrace() 调试手段的替代品；但在随后的演化中，诸如 Linux 等部分 Unix 系统赋予了它越来越庞杂的使命，使其承载了大量的通用系统信息。

One of the great ideas in Unix is the /proc pseudo-filesystem (which comes from Research Unix). Initially used to expose processes as an alternative to ptrace(), it grew to encompass an increasing amount of general system information in some Unixes, such as Linux.

在 Linux 中，这一设计带来了软件生态对常规 /proc 文件的 高频依赖与广泛使用。然而，无论是在 Linux 还是其他现代 Unix 变体中，人们都正日益弃用通过 /proc 获取信息的做法，转而优先采用更为高效的直接系统调用。这种转变绝不是因为 /proc 在理论设计上有何硬伤，而完全是出于对实际运行性能与系统可靠性的深层考量。

In Linux, this has resulted in frequent use of general /proc files. However, in both Linux and other Unixes, people are increasingly moving away from accessing information through /proc in favor of direct system calls. This shift isn't because /proc is a bad idea in theory, but rather due to practical issues concerning both performance and reliability.

性能瓶颈

Performance Bottlenecks

1. 文本格式与二进制数据的转换开销

1. Text vs. Binary Overhead

广为人知的一大性能硬伤在于：在 Linux (以及其他某些程度上类似的系统) 中，/proc 内部呈现的海量信息本质上都是以纯文本字符串形式输出的二进制数值。

The famous performance issue is that on Linux (and to a lesser extent elsewhere), a lot of information in /proc consists of binary numbers reported in text form.

• 内核必须在底层将所有这些内部二进制数值逐一格式化转换为可读的文本字符串；
• 消费这些 /proc 信息的应用程序，拿到文本后又几乎无一例外地需要将其重新解析还原为二进制数值。

• The kernel must format all of these numbers into text.
• Consumers of the /proc information generally parse them right back into binary.

这一“二进制 -> 文本 -> 二进制”的反复转换过程耗费了大量宝贵的 CPU 时间，尤其是在监控程序或性能分析工具需要高频读取 /proc 来收集指标的场景下更是雪上加霜。虽然纯文本对于人类肉眼直接查看或简易脚本读取确实十分友好，但在极致效率面前显然不是最优解，这也正是为何现代替代接口普遍倾向于直接在内存间以原生二进制形式高效传输数据的原因。

All of this consumes CPU time, especially if programs read /proc frequently for performance metrics. While text is convenient for easy consumption, it is not optimal, which is why alternate interfaces prefer transferring data in binary form.

2. 文件系统操作的底层系统调用成本

2. The Cost of File Operations

另一个相对隐蔽但同样影响深远的性能损耗，在于从 /proc 读取信息时所涉及的大量底层系统调用与内核内部开销。

A less obvious performance issue is the number of system calls and kernel work required to access information from /proc.

程序要读取 /proc 中的任意一个虚拟文件，通常必须依次经历以下三个固定步骤：

To read a file in /proc, a program must:

1. 调用 open() 根据文件路径打开该虚拟文件；
2. 调用 read() 读取文件中的内容；
3. 读取完毕后调用 close() 关闭该文件 (或者在后续读取前调用 lseek() 重置文件偏移量)。

1. open() the filename
2. read() the file
3. close() it again (or lseek() before reading again)

这些密集的系统调用及其附带的内核级开销 (例如路径名解析与虚拟文件节点构建) 日积月累之下会产生不可忽视的性能负担。相比之下，诸如 sysctl() 或 sysinfo() 这类现代接口仅需发起一次系统调用即可直接返回所需数据——有时甚至能一次性打包获取多项系统指标。此外，直接系统调用还为在用户空间彻底免内核态切换读取特定只读信息开辟了技术可能 (就像 Linux 目前针对部分时间与时钟相关的系统调用通过 vDSO 机制实现的用户态快速读取那样)。

These system calls and accompanying kernel work (such as filename resolution) add up over time. Modern interfaces like sysctl() or sysinfo() provide data in a single system call—sometimes fetching multiple pieces of information at once. Direct system calls also open up the possibility of accessing certain read-only information entirely in user space (as Linux currently does for a small set of time-related calls).

可靠性与安全层面的严峻挑战

Reliability and Security Challenges

相比于性能瓶颈，通过 /proc 提取系统指标所引发的系统可靠性与安全性隐患，往往是更为棘手的结构性问题：

A bigger issue with retrieving information through /proc is reliability and security:

• 资源耗尽 (Resource Exhaustion)：访问 /proc 下的任何内容都必须占用一个文件描述符 (File Descriptor, FD)。一旦进程耗尽了可用的文件描述符限额，后续读取系统平均负载——甚至获取加密安全随机数的尝试都会直接报错失败。这种情况可能因系统资源上限设置过低而意外发生，也可能源于攻击者刻意发起的资源耗尽攻击，企图以此干扰安全敏感型操作的正常执行；
• 描述符生命周期管理 (Descriptor Management)：在高度依赖多线程或高频调用 fork() 的程序中，开发者必须极其小心地跟踪并及时关闭这些文件描述符，否则子进程极容易意外继承父进程中打开的 /proc 文件描述符，埋下严重的资源泄露或状态错乱隐患；
• chroot 环境与沙箱隔离 (Sandboxing)：如果系统运行不可或缺地依赖 /proc 或 /dev (例如用于生成密码学安全随机数)，那么配置安全的 chroot 隔离环境就会变得异常复杂。你不仅必须把 /proc 的特定子目录暴露给沙箱内部，还必须允许受限进程拥有调用 open() 打开文件的权限——而这一关键权限恰恰是在现代 Web 浏览器等沙箱环境中极力收紧防范的。为了既保证安全又维持功能，运维与安全团队不得不编写越来越复杂晦涩的系统调用过滤规则 (例如 seccomp 过滤器)。

• Resource Exhaustion: To access anything in /proc, you must create a file descriptor. If you run out of file descriptors, your attempt to get the load average—or even secure random numbers—will fail. This can happen accidentally due to low limits or through deliberate attacks designed to glitch security-sensitive operations.
• Descriptor Management: Heavily threaded or fork()-heavy programs must carefully track and close these file descriptors, otherwise child processes might inadvertently inherit open /proc file descriptors.
• chroot and Sandboxing: If /proc or /dev access is critical (e.g., for secure random numbers), setting up a secure chroot environment becomes complicated. You must expose parts of /proc and allow processes to open() files—a power you may want to restrict, such as inside a web browser sandbox. Doing so securely requires increasingly sophisticated system call filtering.

(注：严格来说 /dev/random 和 /dev/urandom 属于字符设备文件而非 /proc 虚拟文件，但在文件描述符耗尽和沙箱安全限制方面，它们所面临的架构缺陷完全一致。)

(Note: /dev/random and /dev/urandom are not strictly /proc virtual files, but they suffer from the exact same issues regarding file descriptor exhaustion and security restrictions.)

状态一致性与原子性难题

The Atomicity Problem

另一个困扰 /proc 的可靠性难题，在于难以以具备原子性 (Atomicity) 的方式一致性地获取进程状态信息。

Another reliability issue is retrieving process information in a consistent, atomic manner.

当目标进程的关键运行数据被分散在多个不同的 /proc/<pid> 文件中时，程序不可避免地需要多次发起 read() 调用。在此期间目标进程很可能正在持续运行并改变状态，因此即使你提前打开所有文件并竭尽全力以最快速度连续读取，最终抓取到的也很可能是一组自相矛盾、互不一致的“时间碎片快照”。相比之下，现代用于获取进程状态的新型系统调用接口，允许操作系统内核在底层锁定并一次性返回所请求的完整数据视图，从而提供连贯、一致且具备原子性保障的精准结果。

When information is split across multiple /proc/<pid> files, you may receive inconsistent snapshots because you must make multiple read() calls—even if you pre-open all files and read them as fast as possible. Alternative system call interfaces for process information allow the kernel to provide a coherent, consistent view of all requested data at once.

转向现代替代接口的技术演进

The Shift Toward Alternative Interfaces

上述种种架构限制倒逼着现代操作系统——尤其是 Linux——相继引入一系列崭新的底层接口来替代传统的数据访问途径。例如，当今几乎所有的主流 Unix 变体都内置了专用的系统调用，允许程序直接从内核熵池中获取随机数据 (详情可参阅维基百科关于 提供熵源的系统调用 的专题介绍)。

All of these limitations have pushed systems—especially Linux—to adopt an array of additional ways to access the same data. For example, pretty much every Unix now features specialized system calls to fetch randomness directly from the kernel (see Wikipedia's entropy-supplying system calls).

总结与思考

Conclusion

然而，指出这些缺陷绝非要否定 /proc 核心理念的历史价值。相较于早期必须直接在原始内核内存中晦涩摸索的粗暴方案，/proc 的诞生无疑是操作系统交互史上的一次重大飞跃；时至今日，通过熟悉的文件系统路径快速读取纯文本信息，依然是编写日常 Shell 脚本和进行快速排错调试时不可替代的趁手工具。但技术的演进最终提醒我们：任何优雅崇高的软件设计哲学，在碰撞到严酷复杂的工程现实时，都需要不断修正与权衡演化。

None of this invalidates the core concept of /proc. Its introduction was a vast improvement over older methods of fishing around in raw kernel memory, and extracting plain text from filesystem paths remains genuinely useful for shell scripts and quick debugging. Ultimately, however, it serves as a reminder that practical reality can get messy.

(资料来源：Unix Geek 博客讨论区)

(Source: Unix Geek Blog Comments)