GNU/Linux >> Tutoriels Linux >  >> Linux

Pourquoi est-ce que je ne peux pas planter mon système avec une bombe à fourche ?

Vous avez probablement une distribution Linux qui utilise systemd.

Systemd crée un groupe de contrôle pour chaque utilisateur, et tous les processus d'un utilisateur appartiennent au même groupe de contrôle.

Cgroups est un mécanisme Linux permettant de définir des limites sur les ressources système telles que le nombre maximal de processus, les cycles du processeur, l'utilisation de la RAM, etc. Il s'agit d'une couche de limitation des ressources différente, plus moderne, que ulimit (qui utilise le getrlimit() appel système).

Si vous exécutez systemctl status user-<uid>.slice (qui représente le groupe de contrôle de l'utilisateur), vous pouvez voir le nombre actuel et maximum de tâches (processus et threads) autorisés dans ce groupe de contrôle.

$ 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

Par défaut, le nombre maximum de tâches que systemd autorisera pour chaque utilisateur est de 33 % du "maximum à l'échelle du système" (sysctl kernel.threads-max ); cela équivaut généralement à environ 10 000 tâches. Si vous souhaitez modifier cette limite :

  • Dans systemd v239 et versions ultérieures, la valeur par défaut de l'utilisateur est définie via TasksMax= dans :

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

    Pour ajuster la limite pour un utilisateur spécifique (qui sera appliquée immédiatement ainsi que stockée dans /etc/systemd/system.control), exécutez :

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

    Les mécanismes habituels de remplacement des paramètres d'une unité (tels que systemctl edit ) peuvent également être utilisés ici, mais ils nécessiteront un redémarrage. Par exemple, si vous souhaitez modifier la limite pour tous utilisateur, vous pouvez créer /etc/systemd/system/user-.slice.d/15-limits.conf .

  • Dans systemd v238 et versions antérieures, la valeur par défaut de l'utilisateur est définie via UserTasksMax= en /etc/systemd/logind.conf . La modification de la valeur nécessite généralement un redémarrage.

Plus d'informations à ce sujet :

  • man 5 systemd.resource-control
  • man 5 systemd.tranche
  • man 5 logind.conf
  • http://0pointer.de/blog/projects/systemd.html (recherchez les cgroups sur cette page)
  • man 7 cgroups et https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
  • https://en.wikipedia.org/wiki/Cgroups

Cela ne plantera plus les systèmes Linux modernes de toute façon.

Il crée des hordes de processus mais ne brûle pas vraiment beaucoup de CPU car les processus deviennent inactifs. Vous manquez d'emplacements dans la table de processus avant de manquer de RAM maintenant.

Si vous n'êtes pas limité au groupe de contrôle comme le souligne Hkoof, la modification suivante arrête toujours les systèmes :

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

Dans les années 90, j'en ai accidentellement déclenché un sur moi-même. J'avais par inadvertance défini le bit d'exécution sur un fichier source C contenant une commande fork(). Lorsque j'ai double-cliqué dessus, csh a essayé de l'exécuter plutôt que de l'ouvrir dans un éditeur comme je le voulais.

Même alors, cela n'a pas planté le système. Unix est suffisamment robuste pour que votre compte et/ou le système d'exploitation aient une limite de processus. Ce qui se passe à la place, c'est qu'il devient super lent, et tout ce qui doit démarrer un processus est susceptible d'échouer.

Ce qui se passe dans les coulisses, c'est que la table des processus se remplit de processus qui tentent de créer de nouveaux processus. Si l'un d'eux se termine (soit en raison d'une erreur sur le fork parce que la table de processus est pleine, soit en raison d'un opérateur désespéré essayant de rétablir la santé mentale de son système), l'un des autres processus en créera un nouveau pour remplir le vide.

La "bombe à fourche" est essentiellement un système de processus autoréparable involontairement en mission pour garder votre table de processus pleine. La seule façon de l'arrêter est de les tuer tous d'une manière ou d'une autre.


Linux
  1. Pourquoi un programme avec Fork() imprime-t-il parfois sa sortie plusieurs fois ?

  2. Pourquoi puis-je voir la sortie des processus en arrière-plan ?

  3. Puis-je mettre à jour le système avec un Live Cd ?

  4. Réparer une image système avec DISM

  5. Pourquoi mon chat fonctionne-t-il plus lentement avec les appels système que le chat de Linux ?

Comment tuer des processus sur le bureau Linux avec xkill

Commande Linux PS avec exemples

Audit de sécurité avec Lynis

Pourquoi mv ne peut-il pas gérer l'existence d'un répertoire de même nom dans la destination ?

Puis-je utiliser l'authentification par clé SSH pour me connecter à un système distant avec un nom d'utilisateur différent ?

Jusqu'où la charge du système peut-elle aller ?