¿Por qué no puedo bloquear mi sistema con una bomba de horquilla?

Probablemente tenga una distribución de Linux que use systemd.

Systemd crea un cgroup para cada usuario y todos los procesos de un usuario pertenecen al mismo cgroup.

Cgroups es un mecanismo de Linux para establecer límites en los recursos del sistema, como el número máximo de procesos, ciclos de CPU, uso de RAM, etc. Esta es una capa de limitación de recursos diferente y más moderna que ulimit (que usa el getrlimit() llamada al sistema).

Si ejecuta systemctl status user-<uid>.slice (que representa el cgroup del usuario), puede ver el número actual y máximo de tareas (procesos y subprocesos) que está permitido dentro de ese cgroup.

$ systemctl status user-$UID.slice
● user-22001.slice - User Slice of UID 22001
   Loaded: loaded
  Drop-In: /usr/lib/systemd/system/user-.slice.d
           └─10-defaults.conf
   Active: active since Mon 2018-09-10 17:36:35 EEST; 1 weeks 3 days ago
    Tasks: 17 (limit: 10267)
   Memory: 616.7M

De forma predeterminada, la cantidad máxima de tareas que systemd permitirá para cada usuario es el 33 % del "máximo de todo el sistema" (sysctl kernel.threads-max ); esto suele equivaler a ~10.000 tareas. Si desea cambiar este límite:

• En systemd v239 y posteriores, el valor predeterminado del usuario se establece a través de TasksMax= en:

  /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
  

  Para ajustar el límite para un usuario específico (que se aplicará inmediatamente y se almacenará en /etc/systemd/system.control), ejecute:

  systemctl [--runtime] set-property user-<uid>.slice TasksMax=<value>
  

  Los mecanismos habituales de anular la configuración de una unidad (como systemctl edit ) también se pueden usar aquí, pero requerirán un reinicio. Por ejemplo, si desea cambiar el límite para cada usuario, podría crear /etc/systemd/system/user-.slice.d/15-limits.conf .

• En systemd v238 y versiones anteriores, el valor predeterminado del usuario se establece a través de UserTasksMax= en /etc/systemd/logind.conf . Cambiar el valor generalmente requiere un reinicio.

Más información sobre esto:

• man 5 systemd.control de recursos
• man 5 systemd.slice
• man 5 logind.conf
• http://0pointer.de/blog/projects/systemd.html (busque cgroups en esta página)
• man 7 cgroups y https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
• https://en.wikipedia.org/wiki/Cgroups

De todos modos, esto ya no bloqueará los sistemas Linux modernos.

Crea montones de procesos, pero en realidad no quema tanta CPU ya que los procesos quedan inactivos. Te quedas sin ranuras en la tabla de procesos antes de quedarte sin RAM ahora.

Si no está limitado por cgroup como señala Hkoof, la siguiente alteración aún hace que los sistemas se caigan:

:(){ : | :& : | :& }; :

En los años 90, accidentalmente descargué uno de estos sobre mí. Sin darme cuenta, había configurado el bit de ejecución en un archivo fuente C que tenía un comando fork() en él. Cuando hice doble clic en él, csh intentó ejecutarlo en lugar de abrirlo en un editor como yo quería.

Incluso entonces, no bloqueó el sistema. Unix es lo suficientemente robusto como para que su cuenta y/o el sistema operativo tengan un límite de proceso. Lo que sucede en cambio es que se vuelve muy lento, y es probable que falle cualquier cosa que necesite iniciar un proceso.

Lo que sucede entre bastidores es que la tabla de procesos se llena de procesos que intentan crear nuevos procesos. Si uno de ellos termina (ya sea debido a un error en la bifurcación porque la tabla de procesos está llena, o debido a que un operador desesperado intenta restaurar la cordura de su sistema), uno de los otros procesos felizmente bifurcará uno nuevo para llenar el vacío.

La "bomba de bifurcación" es básicamente un sistema de procesos que se repara a sí mismo involuntariamente con la misión de mantener llena la tabla de procesos. La única forma de detenerlo es matarlos a todos a la vez.