我正在运行一个Linux 2.6.36内核，我看到一些随机错误。 像
ls: error while loading shared libraries: libpthread.so.0: cannot open shared object file: Error 23 是的，我的系统无法持续运行'ls'命令。 🙁
我注意到我的dmesg输出中的几个错误：
# dmesg | tail [2808967.543203] EXT4-fs (sda3): re-mounted. Opts: (null) [2837776.220605] xv[14450] general protection ip:7f20c20c6ac6 sp:7fff3641b368 error:0 in libpng14.so.14.4.0[7f20c20a9000+29000] [4931344.685302] EXT4-fs (md16): re-mounted. Opts: (null) [4982666.631444] VFS: file-max limit 1231582 reached [4982666.764240] VFS: file-max limit 1231582 reached [4982767.360574] VFS: file-max limit 1231582 reached [4982901.904628] VFS: file-max limit 1231582 reached [4982964.930556] VFS: file-max limit 1231582 reached [4982966.352170] VFS: file-max limit 1231582 reached [4982966.649195] top[31095]: segfault at 14 ip 00007fd6ace42700 sp 00007fff20746530 error 6 in libproc-3.2.8.so[7fd6ace3b000+e000]
显然，文件最大错误看起来可疑，被聚集在一起，最近。
# cat /proc/sys/fs/file-max 1231582 # cat /proc/sys/fs/file-nr 1231712 0 1231582
这对我来说也有点奇怪，但事实是，我没有办法在这个系统上打开120万个文件。 我是唯一使用它的人，而且本地networking之外的任何人都看不到它。
# lsof | wc 16046 148253 1882901 # ps -ef | wc 574 6104 44260
我看到一些文件说：
文件最大和文件编号：
内核dynamic地分配文件句柄，但是现在它不会再释放它们。
file-max中的值表示Linux内核将分配的最大文件句柄数。 当您收到很多有关用完文件句柄的错误消息时，可能需要增加此限制。
历史上，file-nr中的三个值表示分配的文件句柄的数量，已分配但未使用的文件句柄的数量以及文件句柄的最大数量。 Linux 2.6总是报告0作为自由文件句柄的数量 – 这不是一个错误，它只是意味着分配文件句柄的数量与使用的文件句柄的数量完全一致。
试图分配比file-max更多的文件描述符，用printk报告，查找“VFS：达到文件最大限制”。
我第一次读到这个内核基本上有一个内置的文件描述符泄漏，但我觉得很难相信。 这意味着任何需要重新启动的系统才能释放文件描述符。 正如我所说的，我不敢相信这是真的，因为我一直都希望Linux系统一直保持好几个月（甚至几年）。 另一方面，我也不敢相信我的近乎空闲的系统已经打开了超过一百万个文件。
有没有人有任何想法，要么修复或进一步诊断？ 当然，我可以重新启动系统，但是我不希望这个问题每隔几周就会出现一次。 作为一个权宜之计，我已经退出了火狐浏览器，即使我只打开了一个窗口，它占了将近2000行的lsof输出（！），现在我可以再次运行'ls'了，但是我怀疑这会修复问题很长。 （编辑：哎呀，说话太快了，当我输完这个问题的时候，症状已经回来了）
在此先感谢您的帮助。
另一个更新：我的系统基本上是无法使用的，所以我决定我没有select，只能重新启动。 但在此之前，我一次又一次仔细地退出一个进程，每次终止后检查/proc/sys/fs/file-nr 。 我发现，可以预见的是，随着我closures，打开文件的数量逐渐减less。 不幸的是，这不是一个大的影响。 是的，我能够清理5000-10000个打开的文件，但还剩下120多万个文件。 我closures了一切。 所有的交互式shell，除了我打开的一个SSH完成closures，httpd，甚至nfs服务。 基本上，进程表中的所有内容都不是内核进程，而且还有数量可观的文件显然处于打开状态。
重新启动后，我发现/proc/sys/fs/file-nr显示了大约2000个文件打开，这更合理。 像往常一样开始2个Xvnc会议，以及我喜欢保持开放的十几个监控窗口，总计达到约4000个文件。 当然，我看不出有什么问题，但是我显然没有find根本原因。
我仍然在寻找想法，因为我绝对期待它再次发生。
另一个更新，第二天：
我仔细观察了系统，发现/proc/sys/fs/file-nr每小时显示大约900个打开文件的增长。 我晚上closures了系统唯一的NFS客户端，并停止增长。 请注意，它并没有释放资源，但至less停止了消耗。 这是一个已知的NFS错误？ 我今天将把NFS客户端重新上线，我将进一步缩小范围。
如果有人熟悉这种行为，可以随意插入“是的，NFS4有这个问题，回到NFS3”或类似的东西。
经过多一点testing，我相信这是一个NFS服务器错误。 当NFS客户机上的进程在文件上写入locking时，服务器会保留一个打开的文件句柄（这可能是一个错误的术语 – 我向任何真正的内核专家表示歉意）。 如果服务器在释放锁的时候释放了句柄，那么这可能是确定的，但是显然没有。
我原来的问题发生在rrdtool。 rrdtool打开一个文件进行读取/写入，locking文件进行写入，更改并退出。 每次运行rrdtool时，服务器上打开文件的数量都会增加一个。 （Nitpicky细节 – 服务器实际上是以32个块为单位进行分配的，所以更像是“32次运行会打开32个文件描述符”，但从长远来看，这是一个微不足道的细节）
我写了一个最小的testing程序来validation这种行为。 事实上，打开文件，locking它，然后退出足以触发这个。 在退出之前明确释放locking不会有任何帮助。 打开文件而不locking它不会触发问题。
到目前为止，我还没有find一种方法来释放服务器上的资源，而不是重新启动。 如上所述，重新启动NFS服务是不够的。
我还没有testingNFS版本3.也许它工作得更好。
无论如何，谢谢你的尝试。 希望我的经验可以对未来的其他人有所帮助。
最后一个更新：NFSv4开发人员之一J. Bruce Fields已经确认这是一个错误，并且说它仅限于NFSv4。 显然我是第一个报告的。 他希望很快有补丁。
请记住，孩子们：当你发现一个错误，find适当的地方来报告它，这是一个很好的机会将得到修复。 华友世纪为开源。 🙂
我晚上closures了系统唯一的NFS客户端，并停止增长。 请注意，它并没有释放资源，但至less停止了消耗。
请参阅使用被认为有害的NFS ，特别是第III.B点。 当您的NFS客户端不可用时，其锁不会被释放，所以打开的文件数量不会减less。 如果你踢了NFS服务器（或者更确切地说，锁守护进程），你会看到打开的文件数量减less。
我认为你可以把这个问题安全地归因于NFS客户正在做的事情，而且你可能已经在上面的问题中没有提到。
error loading shared libraries错误的错误是因为您已达到可以打开的最大文件数量; 当你运行ls ，内核试图打开一个库ls是dynamic链接的; 显然，这是因为你在该文件系统的最大打开文件限制，因此错误。
你的客户正在做的是每小时打开900个文件。 这不是在NFS导出上运行Spotlight的Mac，是吗？
我有同样的问题。 安装了我们用作中央networking存储的HA服务器集群。 在此DRBD群集上，NFS4服务器正在运行。
我们每个小时都会生成数千个小数据文件，并将其存储在这个NFS4服务器上。
从我们启动NFS4服务器的那一刻开始，大约需要30天，直到fs.file-nr达到1.2mil文件的限制，然后在24小时内整个机器崩溃。
就在现在，高速caching备份机器在崩溃后接pipe了两个小时之后，就显示出来了
fs.file-nr = 19552 0 488906
在20分钟内以+3000的速度递增。
HA备份机器待机30天，一直有580 0 488 906个。 唯一改变的是NFS4服务器启动了。
我会很高兴，如果有这个解决scheme..
我正在运行MDV 2010，自定义编译的x64 2.6.37 RC3内核