再尝试一个更短、更有针对性的问题。请注意，这不是常见的“为什么 file-nr 报告的数字低于我的预期”问题。我有相反的问题。
Linux 2.6 系统正在泄漏文件句柄。我知道这一点是因为我定期 cat /proc/sys/fs/file-nr。第一个数字在几个小时内呈上升趋势，第二个数字始终为 0。当第一个数字达到第三个时，登录变得不可能，没有新的 shell 等。所以我相信 file-nr 的输出，并且有理由相信有严重的文件句柄泄漏。 （系统并不总是这样做，我们还没有找到导致它开始发生的押韵或原因，但它相当常见。）
现在是奇怪的部分。以 root 身份运行，我通过 /proc/each process id/fd 对所有 fd 执行 ls -l。请注意，我以 root 身份执行此操作，因此我应该看到所有进程的所有文件句柄。
根据我有限的理解， ls 的输出应该显示与 file-nr 显示的句柄数量相同的数量。我不希望它是准确的，因为进程可能会来来去去，它们可能会在我行走 /proc/# 时打开或关闭文件。但经过足够多的次数后，我预计平均而言，会达成大致一致。所以第一个问题是，这是一个合理的假设吗？如果不合理，为什么不呢？
我问这个问题是因为 file-nr 显示句柄计数缓慢增加，逐渐向 65536 迈进。但是 /proc/ids../fd 的聚合输出显示数千更少的手柄。例如，在某一时刻，file-nr 看起来像“9900 0 65536”，但 proc 中每个进程的文件句柄计数不到 2000，并且重复执行，它或多或少保持不变。无论泄漏的句柄是什么，都不会显示为进程。
相差7000多？当进程不疯狂地启动和停止并且不应该疯狂地打开和关闭文件时？请注意，每个进程的硬文件句柄限制为 1024，因此并不是任何一个进程导致了这一情况。系统确实显示了几十个失效进程，但我不认为失效进程可以保留文件句柄。而且我努力让其他人检查我的工作，这样它看起来就不会是对 ls 或任何东西的愚蠢滥用。
这对我来说是一个关键问题，如果有人能解释为什么计数中存在如此大的分歧，它可能会让我走上解决关键和生产停止问题的轨道。
请注意，我没有使用 lsof - 它已从系统中删除。但由于我只对实际文件句柄感兴趣，这可能与“打开文件”不同，所以步行 /proc/#s 应该足够了。或者说我是这么想的。
答案1
事实证明，至少在 Linux 2.6 中，失效的进程可以保留文件句柄。我不知道怎么回事，但是当我们强行清理失效的 sshd 进程时，句柄计数又下降了。