Why a fork bomb can make a server unresponsive
A fork bomb abuses a normal operating-system feature: forking, or creating a new process from an existing one. In a recursive version, each process repeats the same action, so the number of active processes can grow exponentially. The machine is not doing more useful work; it is spending its capacity managing a rapidly multiplying crowd of tasks.
The bottleneck is more than CPU
A processor can run only a limited number of tasks at once. The operating system switches among them, but every switch and every process still takes time and resources. As the crowd grows, legitimate programs may get little chance to run.
The squeeze can also hit limits on how many processes the system can track, or on the memory and other resources each process consumes. When those limits are exhausted, the server may struggle to start a login session or launch the tool needed to stop the runaway processes. That is why a machine can appear frozen even if its hardware has not failed.
Why limits matter
Systems can reduce the damage by limiting how many processes a user or service may create, and by isolating workloads so one cannot consume all available resources. These safeguards do not change the underlying mechanism; they put a ceiling on how far it can spread.
The practical danger is that a tiny action can turn into an operational outage—not because the command is computationally complex, but because each new process helps create more.
