Proč nemohu rozbít svůj systém vidlicovou bombou?

Pravděpodobně máte distribuci Linuxu, která používá systemd.

Systemd vytvoří cgroup pro každého uživatele a všechny procesy uživatele patří do stejné cgroup.

Cgroups je linuxový mechanismus pro nastavení limitů na systémové prostředky, jako je maximální počet procesů, cykly CPU, využití RAM atd. Toto je jiná, modernější vrstva omezení zdrojů než ulimit (který používá getrlimit() systémové volání).

Pokud spustíte systemctl status user-<uid>.slice (což představuje cgroup uživatele), můžete vidět aktuální a maximální počet úloh (procesy a vlákna), která je v této cgroup povolena.

$ 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

Ve výchozím nastavení je maximální počet úloh, které systemd povolí každému uživateli, 33 % z „celosystémového maxima“ (sysctl kernel.threads-max ); to obvykle činí ~ 10 000 úkolů. Pokud chcete tento limit změnit:

• V systemd v239 a novějších je výchozí nastavení uživatele nastaveno pomocí TasksMax= v:

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

  Chcete-li upravit limit pro konkrétního uživatele (který bude okamžitě aplikován a také uložen v /etc/systemd/system.control), spusťte:

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

  Obvyklé mechanismy přepisování nastavení jednotky (jako je systemctl edit ) lze použít i zde, ale budou vyžadovat restart. Pokud například chcete změnit limit pro každý uživatel, můžete vytvořit /etc/systemd/system/user-.slice.d/15-limits.conf .

• V systemd v238 a dřívějších je výchozí nastavení uživatele nastaveno pomocí UserTasksMax= v /etc/systemd/logind.conf . Změna hodnoty obecně vyžaduje restart.

Více informací o tomto:

• man 5 systemd.resource-control
• man 5 systemd.slice
• man 5 logind.conf
• http://0pointer.de/blog/projects/systemd.html (na této stránce vyhledejte skupiny cgroups)
• man 7 cgroups a https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
• https://en.wikipedia.org/wiki/Cgroups

Moderní linuxové systémy to už stejně nezničí.

Vytváří hromady procesů, ale ve skutečnosti nespaluje tolik CPU, protože procesy jsou nečinné. Dojdou vám sloty v tabulce procesů dříve, než vám dojde paměť RAM.

Pokud nejste omezeni cgroup, jak zdůrazňuje Hkoof, následující změna stále sráží systémy:

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

V 90. letech jsem jeden takový omylem rozpoutal na sobě. Neúmyslně jsem nastavil prováděcí bit na zdrojový soubor C, který měl v sobě příkaz fork(). Když jsem na něj dvakrát kliknul, csh se jej pokusil spustit, místo aby jej otevřel v editoru, jaký jsem chtěl.

Ani potom to nezhroutilo systém. Unix je dostatečně robustní, že váš účet a/nebo OS bude mít procesní limit. Místo toho se to stane velmi pomalé a vše, co potřebuje ke spuštění procesu, pravděpodobně selže.

To, co se děje v zákulisí, je, že tabulka procesů se plní procesy, které se snaží vytvořit nové procesy. Pokud se jeden z nich ukončí (buď kvůli chybě na rozvětvení, protože tabulka procesů je plná, nebo kvůli zoufalému operátorovi, který se snaží obnovit zdravý rozum do jejich systému), jeden z ostatních procesů vesele rozvětví nový, aby ho zaplnil. prázdnota.

"Fork bomb" je v podstatě neúmyslně samoopravující systém procesů na misi, aby byl váš procesní stůl plný. Jediný způsob, jak to zastavit, je nějak zabít všechny najednou.