In PAM, the default max processes for a user is set (in /etc/security/limits.d/90-nproc.conf) to 1024. On a modern machine, this is too low, and results in processes failing to start. It's also very hard to discover why this happens(*), and awkward to fix (requiring a logout or reboot). One reason this is more relevant that it was is that that the chromium web browser runs each tab in a separate process, so it's very easy to accumulate a couple of hundred processes. Admittedly I use the machine quite demandlingly (3 monitors, 4 virtual desktops, 16 GB of RAM, and a bad habit of not closing browser tabs immediately), but I'm the single user of this machine and I wasn't doing anything particularly unusual, so I wouldn't expect to run up against a rule designed to protect me against a fork bomb. Aside: on my Ubuntu netbook, the value of ulimit -u is 60522, and on this desktop, after I commented out the problematic line in 90-nproc.conf, is 126107. (*)When launching an application from the CLI, we get an error about failing to fork. But when the problem is actually the flashplayer non-deterministically not starting in a web browser, or a cronjob randomly failing this is somewhat hard to debug.
(In reply to Richard Neill from comment #0) > non-deterministically not starting in a web browser, or a cronjob randomly > failing this is somewhat hard to debug. I hear that. I have several cron jobs running fetchmail, which occasionally fail to obtain a socket. I run kde with eight virtual desktops, two xterms running journalctl -fa, 4 or 5 xterms, thunderbird, are always open, msec is doing hourly checks,... When my system is idling, it is burning 443+ process ids per hour. I am going to bump 90-nproc.conf to 2048 from now on.
CC: (none) => junknospam
Thanks. Can I suggest that a factor 10 safety margin (i.e. to 10240) might be worthwhile - otherwise, this problem is going to reccur in the near future. I suspect that when the value of 1024 was originally chosen, it was never expected that it would be reached in practice.
(In reply to Richard Neill from comment #2) > I suspect that when the value of 1024 was originally chosen, it was never > expected that it would be reached in practice. Thanks to dbus and systemd changes. :( > Thanks. Can I suggest that a factor 10 safety margin (i.e. to 10240) might > be worthwhile - otherwise, this problem is going to reccur in the near > future. I was thinking 10x was a bit high. But if systemd is going to run with timers to replace cron then 8x or 10x might not be unreasonable.
Source RPM: (none) => pam
CC: (none) => mageia
I'm not inclined to change the default unless Fedora does. Theirs is here. I actually do need to update it so that root is unlimited like they've done: http://pkgs.fedoraproject.org/cgit/pam.git/tree/90-nproc.conf
CC: (none) => luigiwalser
root is now unlimited for Mageia 4 in pam-1.1.8-6.mga4. Hopefully that'll help. I don't know what to say about having 1000 chromium processes, that's crazy.
Note that this is not a process limit, this is a limit on thread count. A single chromium tab will cause 4 threads to be created, and a single Flash Player applet will cause ~10 threads to be created. Thus with e.g. 100 chromium tabs open, of which 40 contain Flash videos, one already uses up 800 threads, which doesn't leave that much for other stuff. I've been hit by this multiple times recently, I wrote about this in more detail here: https://bugzilla.redhat.com/show_bug.cgi?id=432903#c16
CC: (none) => anssi.hannula
Related(In reply to Anssi Hannula from comment #6) > Note that this is not a process limit, this is a limit on thread count. Related, maybe bash manpage should be updated. It shows -T for thread count [which doesn't seem to exist anymore and is not shown by ulimit -a] and -u as processes per user, the same as in man page of prlimit. But it will probably apply to both, as the upper limit for processes should also apply to overall number of threads ... ?
CC: (none) => doktor5000
Fedora has updated the process limit to 4096 in Rawhide. I've done the same in Cauldron. I've also done that, as well as the unlimited for root noted previously, for Mageia 3. Advisory: ---------------------------------------- The default per-user process limit of 1024 set in the pam package caused problems with some applications that create several processes. This limit has been changed to 4096 to alleviate these problems. Also, the limit has been lifted altogether for the root user. References: https://bugzilla.redhat.com/show_bug.cgi?id=432903 https://bugs.mageia.org/show_bug.cgi?id=11550 ---------------------------------------- Updated packages in core/updates_testing: ---------------------------------------- pam-1.1.6-5.1.mga3 pam-doc-1.1.6-5.1.mga3 libpam0-1.1.6-5.1.mga3 libpam-devel-1.1.6-5.1.mga3 from pam-1.1.6-5.1.mga3.src.rpm
Hardware: x86_64 => AllAssignee: bugsquad => qa-bugsSeverity: normal => minor
Tested Mag3 on real 32-bit hardware I had to re-start the system for the change to be seen, hence only the 'after' result to contain within one post. ulimit -T [See comment 7] bash: ulimit: -T: invalid option After installing update: $ rpm -q pam pam-1.1.6-5.1.mga3 $ rpm -q libpam0 libpam0-1.1.6-5.1.mga3 $ ulimit -u 4096 [Previously 1024] $ prlimit RESOURCE DESCRIPTION SOFT HARD UNITS NPROC max number of processes 4096 11788 # ulimit -u 11788 [Previously 1024] # prlimit RESOURCE DESCRIPTION SOFT HARD UNITS NPROC max number of processes 11788 11788 > the limit has been lifted altogether for the root user Note that the root max is *not* 'unlimited', which designation does exist for other limits from prlimit. If, however, this result is satisfactory, can you DavidW [comment 8] please put MGA3-32-OK in the whiteboard. Otherwise back to you.
CC: (none) => lewyssmith
Yep, it looks good. Thanks Lewis.
Whiteboard: (none) => MGA3-32-OK
Maybe you should mention in the advisory that it is actually the thread count and not process count which is limited? If it were a process count limit there would be no issue in the first place.
(In reply to Anssi Hannula from comment #11) > Maybe you should mention in the advisory that it is actually the thread > count and not process count which is limited? > > If it were a process count limit there would be no issue in the first place. I suppose that's technically correct, but since processes is the terminology that both ulimit and prlimit are using, I don't know if that'd make it more clear or more confusing.
Testing mga3-64, Tested complete for pam-1.1.6-5.1.mga3, ok for me. $ ulimit -u 4096 $ prlimit RESOURCE DESCRIPTION SOFT HARD UNITS AS address space limit unlimited unlimited octets CORE max core file size 0 unlimited blocs CPU CPU time unlimited unlimited secondes DATA max data size unlimited unlimited octets FSIZE max file size unlimited unlimited blocs LOCKS max number of file locks held unlimited unlimited MEMLOCK max locked-in-memory address space 65536 65536 octets MSGQUEUE max bytes in POSIX mqueues 819200 819200 octets NICE max nice prio allowed to raise 0 0 NOFILE max number of open files 1024 4096 NPROC max number of processes 4096 63031 RSS max resident set size unlimited unlimited pages RTPRIO max real-time priority 0 0 RTTIME timeout for real-time tasks unlimited unlimited microsecondes SIGPENDING max number of pending signals 63031 63031 STACK max stack size 8388608 unlimited octets # ulimit -u 63031 # prlimit RESOURCE DESCRIPTION SOFT HARD UNITS AS address space limit unlimited unlimited octets CORE max core file size 0 unlimited blocs CPU CPU time unlimited unlimited secondes DATA max data size unlimited unlimited octets FSIZE max file size unlimited unlimited blocs LOCKS max number of file locks held unlimited unlimited MEMLOCK max locked-in-memory address space 65536 65536 octets MSGQUEUE max bytes in POSIX mqueues 819200 819200 octets NICE max nice prio allowed to raise 0 0 NOFILE max number of open files 1024 4096 NPROC max number of processes 63031 63031 RSS max resident set size unlimited unlimited pages RTPRIO max real-time priority 0 0 RTTIME timeout for real-time tasks unlimited unlimited microsecondes SIGPENDING max number of pending signals 63031 63031 STACK max stack size 8388608 unlimited octets
CC: (none) => geiger.david68210Whiteboard: MGA3-32-OK => MGA3-32-OK MGA3-64-OK
Last-checked the RPM diffs, no unexpected change there. Update validated. Advisory uploaded. Please sysadmins push the update to 3/core/updates
Keywords: (none) => validated_updateCC: (none) => stormi, sysadmin-bugsWhiteboard: MGA3-32-OK MGA3-64-OK => MGA3-32-OK MGA3-64-OK advisory
Update pushed: http://advisories.mageia.org/MGAA-2014-0011.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED