View attachment 32097
what does this image means?
" Life is

){ :|: };: "
is it a meme or something?
As
@AlphaObeisance wrote in post #14, the fork bomb will use up resources in a system to the point that the system bricks.
The fork bomb replicates itself using up the number of processes that a user can run on the system, which locks out the user from running any more processes, and on its way, its consumption of processes also uses up RAM and the caches on the system and generates huge cpu activity as it keeps flooding the system with itself. The user is thus unable to do anything and the system is overwhelmed by processes so it eventually locks up. That's basically it, in a non-technical nutshell.
It's possible to implement some preventative measures, but it depends in part on how a system is used. One can check on the number of processes that a user is limited to, since if the user is limited to a smaller number of processes that they are able to run on a system, the system will stop running user processes when that number is reached, and bash will output a message like:
Code:
bash: fork: Resource temporarily unavailable
Rather than locking up the system bash will lock up the fork bomb process.
To find out the number of processes a user is limited to one can run the following:
Code:
[~]$ ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 39
file size (blocks, -f) unlimited
pending signals (-i) 62263
max locked memory (kbytes, -l) 4194304
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) 95
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 62263 <-------------MAXIMUM FOR USER
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
The output shows that the maximum number of processes a user can run on this machine is 62263, which is more than enough for the uses that this particular machine undertakes. To see the current number of processes actually on the machine in the present moment, the user can run:
Code:
[~]$ pgrep -wcu $USER
971
pgrep identifies processes, "-c" counts them, "-u $USER" applies the pgrep command to the $USER, and the "-w" counts the threads of processes, which are actually processes themselves and count as real processes for the process tally that the user is using. The output on this machine is a mere 971 processes running which is well within the maximum limit.
The system itself, which includes root's processes has a much higher limit for the number of process it can run and can be seen with a command like:
Code:
[~]$ cat /proc/sys/kernel/pid_max
4194304
That figure is the same as "max locked memory" in the earlier
ulimit -a output.
The upshot is, that for a user, one can lower the maximum number of user processes which would limit the fork bomb to that number, which, if low enough, will prevent the blockage of the system for the user. A number like 10000 might suffice, but as mentioned above, it depends on what the machine normally does. The best prevention is not to run a fork bomb.
One can configure the limits for user processes in the file: /etc/security/limits.conf, with instructions in the file itself and/or the manpage for ulimits.conf.