![[lang]](/images/eye.png)
Lessons learned the hard way |
2007-04-20
|
According to /etc/security/limits.conf, nproc controls the "max number of processes".
In reality, it counts a thread started by a process as a process.
This makes the setting orders of magnitude less useful. And, since it goes through pam, and thus gets decided at start time, also a little painful to recover from changing this setting to a higher value to account for threads.
RLIMIT_NPROC limits the number of processes/threads per user — not the total number of processes/threads.
Comment by blah — 2007-04-20 @ 13:56
“In reality” a thread *is* a process. Older versions of ps displayed this and newer ones don’t for brevitys sake.
Try the -L option to ps with something like ps -eLf
Notice how threads have their own specific pid.
Comment by Jeff Schroeder — 2007-04-20 @ 18:03
_less_ useful? if it didn’t work this way, what would you use to catch a thread-spawn fork bomb?
Comment by Nomen Nescio — 2007-04-20 @ 23:07
Jeff, I know it can be rationalized as being correct. Bottom line is, a thread is not a process the way a process is a process. The comment in pam is ambiguous at best.
(Nescio), I would use the separate option to RLIMIT_NTHREADS that should have been here. AFAIK a thread-spawn fork bomb is harder to trigger than a process fork bomb – for example, I don’t think you can get threads to be created from bash itself.
Comment by Thomas — 2007-04-25 @ 10:34