是的，我知道这个问题之前已经被问过了，我已经尝试过所有我见过的解决scheme，而且没有一个能够为我工作。 我们运行的是Ubuntu 12，每次启动时，我们都有一个自动启动的进程。 我已经进入/etc/security/limits.conf并添加了这些行：
* hard nofile 65000 * soft nofile 32000 root hard nofile 65000 root soft nofile 32000 我也进入了/etc/pam.d/common-session并添加了这一行：
session required pam_limits.so
为了使这个工作适用于非交互式进程，我也进入了/etc/pam.d/common-session-noninteractive并添加了完全相同的行。
当我作为我们的pipe理员用户login（他在sudo列表中，我将调用这个用户SUDOUSER）时，我发现当我做ulimit -a时，限制现在是32000。
然后我重新启动整个机器，以确保新的进程限制，就像重新启动后启动的进程一样。
但是，在重启之后，当我看到在运行时启动的持续进程时，我得到进程ID（比如12345），然后执行cat / proc / 12345 / limits，并且我看到限制仍然是默认值（1024 soft， 4096硬）。
那么我做错了什么？
好的，我find了解决办法。 原来，暴发户忽略了pam.d和limits.conf中的所有限制。 在暴发户做这个的方法是明确地设置在这个过程的新贵conf脚本的限制。 所以，假设进程是myproc，并且你有一个文件/etc/init/myconf.conf。 在这个脚本里面，只是在顶部附近的某个地方包含这一行：
limit nofile 32000 65000
确保这一行本身 – 它不是放置在脚本或预启动脚本等 – 它是一个主线（或“节”）本身。
现在只需重新启动进程，并看到cat / proc / 12345 / limits的限制