How I accidentally ran a fork bomb and crashed my laptop

Source: Dev.to

⚠️ Warning: Do not execute the code shown in this post. It will make your system unresponsive.

The Incident

I wanted to observe Linux kernel behavior under heavy load, specifically stressing the CPU and watching the scheduler. I asked ChatGPT for a shell script that would “apply some load” and, unaware of what a fork bomb is, ran the script it gave me:

forkbomb() {
  forkbomb | forkbomb &
}
forkbomb

The script immediately started spawning processes exponentially. I saw a few fork() calls in the terminal, pressed Ctrl + C a couple of times, and assumed it had stopped—​it hadn’t.

Because each instance is backgrounded with &, the processes are placed in separate process groups and become detached from the terminal’s signal handling. Killing the parent does not stop the children, which continue to proliferate.

After closing the terminal, the system became completely unresponsive. No combination of Ctrl + Alt + Del, Esc, or function keys could revive it, so I had to force a power‑off.

What the Logs Showed

After rebooting, I inspected the system journal (journalctl) and found a cascade of warnings that were symptoms of massive resource starvation:

Jan 24 23:20:00 laptop gnome-shell[3515]: libinput error: event5 - ELAN0712:00 04F3:30FD Touchpad: client bug: event processing lagging behind by 91ms, your system is too slow
Jan 24 23:21:24 laptop kernel: pcieport 10000:e0:1d.0: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
Jan 24 23:08:33 laptop tracker-miner-fs-3[22996]: (tracker-extract-3:22996): GLib-GIO-WARNING **: 23:08:33.174: Error creating IO channel for /proc/self/mountinfo: Invalid argument (g-io-error-quark, 13)

These entries are not the root cause; they are secondary effects of the fork bomb exhausting:

• Process table entries
• CPU time
• Memory
• Scheduler run‑queue slots
• File descriptors

How a Fork Bomb Works

A classic fork bomb is a tiny shell function that recursively spawns copies of itself, causing exponential growth:

:(){ :|:& };:

• : defines a function named :.
• :|: runs two copies of the function, connected by a pipe.
• & backgrounds each copy.
• The final : invokes the function.

Each iteration roughly doubles the number of processes, quickly filling the process table and overwhelming the scheduler.

Recovering from a Fork Bomb

If you catch the bomb early, you can regain control:

1. Switch to a virtual console
   Press Ctrl + Alt + F5 (or any F‑key from F1–F6).

2. Log in as root or another user.

3. Identify the offending processes

   ps aux | grep 

4. Terminate them

   killall -u 

   (or kill specific PIDs if needed).

Prevention

• Limit user processes

  ulimit -u 500          # per‑session limit

• Use systemd’s TasksMax in user slices:
  TasksMax=2048

• Never run shell scripts from the internet or AI without reviewing them.

• Never perform kernel or scheduler stress testing on your host system.
  Use a virtual machine, container, or cgroup sandbox for such experiments.

A fork bomb’s elegance lies in its simplicity: a few lines of code can consume all system resources and render a machine unusable. Always handle unknown scripts with caution.