Friday, October 10, 2008

Fork bomb


We run our college lab on LTSP built on Debian Etch. Today, one of our students inadvertently ran a fork bomb and the entire lab was stuck. We had to reboot the system. On examining the code , it was found that he put fork system call in an infinite loop.

fork bomb is a process that ‘explodes’ by recursively spawning copies of itself. It will eventually eat up all your computing resources .

On Linux systems  you can set the maximum number of processes that a  user can run.

You can explore your current limits via the ulimit  command. This is what I got on my debian etch installation at home.

aneesh@debian:~$ ulimit -a core file size          (blocks, -c) 0 data seg size           (kbytes, -d) unlimited max nice                        (-e) 0 file size               (blocks, -f) unlimited pending signals                 (-i) 4031 max locked memory       (kbytes, -l) 32 max memory size         (kbytes, -m) unlimited open files                      (-n) 1024 pipe size            (512 bytes, -p) 8 POSIX message queues     (bytes, -q) 819200 max rt priority                 (-r) 0 stack size              (kbytes, -s) 8192 cpu time               (seconds, -t) unlimited max user processes              (-u) virtual memory          (kbytes, -v) unlimited file locks                      (-x) unlimited

On my ubuntu desktop I got this.

 sunil@Ubuntu-Hardy:~$ ulimit -a core file size          (blocks, -c) 0 data seg size           (kbytes, -d) unlimited scheduling priority             (-e) 0 file size               (blocks, -f) unlimited pending signals                 (-i) 16312 max locked memory       (kbytes, -l) 32 max memory size         (kbytes, -m) unlimited open files                      (-n) 1024 pipe size            (512 bytes, -p) 8 POSIX message queues     (bytes, -q) 819200 real-time priority              (-r) 0 stack size              (kbytes, -s) 8192 cpu time               (seconds, -t) unlimited max user processes              (-u) virtual memory          (kbytes, -v) unlimited file locks                      (-x) unlimited

On debian the maximum user processes is 4031 and on ubuntu it is 16312.

ulimit settings can be controlled by /etc/security/limits.conf . The file is commented and self explanatory. Each line in the file is organized like this.

Where:

*   can be:
o a user name
o a group name, with @group syntax
o the wildcard *, for default entry
o the wildcard %, can be also used with %group syntax, for maxlogin limit

 can have the two values:
o “soft” for enforcing the soft limits

o “hard” for enforcing hard limits
 can be one of the following:
o core - limits the core file size (KB)
o data - max data size (KB)
o fsize - maximum filesize (KB)
o memlock - max locked-in-memory address space (KB)
o nofile - max number of open files
o rss - max resident set size (KB)
o stack - max stack size (KB)
o cpu - max CPU time (MIN)
o nproc - max number of processes
o as - address space limit
o maxlogins - max number of logins for this user
o maxsyslogins - max number of logins on the system
o priority - the priority to run user process with
o locks - max number of file locks the user can hold
o sigpending - max number of pending signals

o msgqueue - max memory used by POSIX message queues (bytes)

o nice - max nice priority allowed to raise to

o rtprio - max realtime priority
o chroot - change root to directory (Debian-specific)

Typical entries  in  /etc/security/limit.conf can be

*                      soft    core                  0
*                      hard    rss                   10000
@student        hard    nproc             20
@faculty         soft    nproc               20
#@faculty         hard    nproc           50

There are soft limits and hard limits. Soft limits are default values. However hard limits are  enforced via kernel. So a user can change his soft limit up to the hard limit   using the ulimit command. For details ,RTFM ulimit.

This wikipedia article is very informative and a must read for all sysadmins. There are lot of  example bombs you can try :D.

No comments: