我们最近开始在我们的一个nginx框中得到以下错误：
2011/05/25 16:35:51 [alert] 3580#0: accept() failed (24: Too many open files) 检查/etc/security/limits.conf，我们有这个：
* soft nofile 900000 * hard nofile 900000
但是当我们做了/ proc / {pid} /限制它显示文件限制为1024.当我们重新启动nginx的问题是固定的，/ proc / {pid} /限制显示900000.我想这可能是由于因为机器已经重新启动，在启动之前，nginx已经启动，之后才能应用限制。 然而，我一直在读的关于限制和pam工作的一切都表明，这并不是真正的限制。 有人知道这里发生了什么？
编辑：对不起，应该提及操作系统和东西。 我们正在运行内核2.6.18-194.26.1.el5和nginx 1.0.1的CentOS
这个错误报告似乎证实了你最初的怀疑：
这是“如何为守护进程设置ulimits？”这个问题的错误答案？ /etc/security/limits.d只能由pam_limits处理，它没有理由在服务启动的path中。
另一方面，在手动重启时，nginxinheritance了shell的限制。
解决方法：只需在nginx的initscript中调用ulimit即可。 您不能将ulimit -n用作普通用户，但init脚本在启动时应该具有足够的权限。