![为什么 ulimit -u 高于 /proc/sys/kernel/pid_max?](https://linux22.com/image/89585/%E4%B8%BA%E4%BB%80%E4%B9%88%20ulimit%20-u%20%E9%AB%98%E4%BA%8E%20%2Fproc%2Fsys%2Fkernel%2Fpid_max%EF%BC%9F.png)
关于我的系统ulimit -u
报告63172
和/proc/sys/kernel/pid_max
报告32768
。
为什么 的值ulimit -u
比内核的值高?根据我的理解,ulimit -u
显示了用户可以拥有的最大进程,而不是系统范围内的最大进程。pid_max
应该是通过内核在系统范围内进行的。在我看来ulimit -u
,高于 的值似乎是错误的pid_max
,这是否意味着用户如果生成足够多的进程,可能会导致 PID 回绕?另外,如果该pid_max
值受到用户正在执行的操作的影响,是否会导致No more processes error
发生这种情况?
答案1
PID做正常使用时环绕。这根本不是问题;内核确保新的 PID 不会与现有的 PID 发生冲突。没有任何规定 PID 必须单调递增;进程 12345 可以很容易地fork()
拥有一个子进程 5001。
在这种情况下,是的,用户可能会用完所有进程槽并阻止进一步的fork()
类型活动发生。如果这是您的环境中的问题,那么您需要调整 ulimit 值/etc/security/limits.conf
或/etc/security/limits.d/*
答案2
这通常意味着系统将在达到用户限制之前耗尽进程槽。的手册页setrlimit
说:
RLIMIT_NPROC
可以为调用进程的真实用户 ID 创建的最大进程数(或者更准确地说,在 Linux 上为线程数)。遇到此限制时,
fork(2)
会失败并出现错误EAGAIN
。对于具有CAP_SYS_ADMIN
或能力的进程,不强制执行此限制CAP_SYS_RESOURCE
。
返回值EAGAIN
强烈暗示这是对并发线程的限制,一旦子线程退出,后续线程fork()
可能会成功。