[Bug 391761] Re: process limit unlimited (regression)

[Jan Rathmann]

Am 28.11.2011 17:17, schrieb Steve Langasek:
> How does it "crash"?
I apologize if the term "crash" was a bit unprecise. It does not crash 
in sense of hard-locking (where only Reset switch will revive it again), 
but it becomes totally unresponsive due to excessive swapping.

Yesterday I let the fork bomb run for ~1 hour to give the system time to 
reach the process limit (the default one, nothing was specified in 
limits.conf) and become responsive again, but this did not happen in 
this time period. However, it still reacted to Alt+Print+e, which means 
all tasks are terminated (and all unsaved work is being lost).

Tomorrow I made an attempt to log into TTY1 (Ctrl+Alt+F1) while the fork 
bomb was running for ~10 minutes. The TTY appeared after 1-2 minutes, 
but actually logging was not finished after ~5-10 minutes when I lost 
patience and pressed Alt+Print+e again.

So the system does not "crash" literally but becomes effectively 
unusable, with all unsaved work being probably lost.

>
> What does 'ulimit -u' show from a terminal on this system?

31517 is the output. My system has 4 GB of RAM.

Do you think it is appropriate for this case to open a new bug report 
against the kernel?

Kind regards,
Jan

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/391761

Title:
  process limit unlimited (regression)

Status in “pam” package in Ubuntu:
  Fix Released

Bug description:
  AFAIK, RLIMIT_NPROC is determined by the kernel based on available
  physical memory.  In my 512M VMs, I see the following results of
  "ulimit -u":

  dapper: unlimited
  hardy, intrepid: 4095
  jaunty, karmic: unlimited

  The intention is to have this set to in an attempt to reasonably
  mitigate fork-bombs without getting in the way of intentionally big
  process collections.  Jaunty and Karmic appear to have regressed.  I
  am assuming this is a PAM bug, but it may be a kernel issue.  Tracking
  RLIMIT setting has always eluded me.  :)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/391761/+subscriptions