Present Perfect


Picture Gallery
Present Perfect

Lessons learned the hard way

Filed under: General — Thomas @ 13:05


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.


  1. 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

  2. “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

  3. _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

  4. 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

RSS feed for comments on this post. TrackBack URL

Leave a comment