Many (most? all?) default Linux installations of popular distros are still vulnerable to fork-bombs, i.e. can easily be rendered unusable (until reboot) by spawning a large number of processes. You can easily test how your system behaves with well known fork-bomb for bash:
:(){ :|: & };:
Keep in mind that this problem can easily be triggered by a programming error or misusing an application. For example, I encountered it once when rebuilding a Makefile-based project while having CDPATH environment variable set in a way, that resulted in recursive calls to make program in an infinite loop. When that kind of problem happens, it may be hard to regain control and rebooting the system may be the only option.
Fortunately, Linux has measures to protect against such problems and it's very easy to set up. The best way to go is to relay on pam_limits module, configured via /etc/security/limits.conf. It's probably installed by default by all popular Linux distributions (I've tested it on Arch Linux and Ubuntu). Limiting the number of processes to 240 for given user is as simple as:
pawel hard nproc 240
With such setting, logout and login back and verify it has been activated:
[pawel@pc ~]$ ulimit -u
240
Then run a fork bomb again. It should now reach the limit of concurrent processes very quickly while still leaving a lot of spare system resources, so that you can easily deal with the problem.
Just a remark: set the nproc limit to a reasonable value, i.e. examine your typical desktop environment first to estimate typical loads and add a safe margin. For example, a typical GNOME desktop with a few applets can easily create around 50 processes, so keep this in mind.
See 'man limits.conf' and 'man pam_limits' for more information.
No comments:
Post a Comment