C'est pas pour troller, mais j'avais entendu dire que, dorénavant, c'est systemd qui allait gérer l'ensemble des cgroups. Donc est-ce que ces manipulations ne risque pas de perturber notre PID 1 préféré ?
Oui et non.
Si il s'agit d'un processus lancé depuis un terminal ou un pseudo terminal, ça ne change pas grand chose. Il y a des projets de nouvelle interface pour les cgroups qui forcera une interface centralisée. Dans les systèmes utilisant le framework systemd c'est celui-ci qui s'occupera de gérer les cgroups.L'api et les commandes seront différentes, mais dans l'ensemble les fonctionnalités devrait être sensiblement les mêmes.
Par contre si il s'agit d'un processus détaché (daemon ou autre) géré par l'init, ça devient plus compliqué. Et c'est déjà le cas aujourd'hui, même sans la nouvelle interface.
Si le processus a été lancé par systemd il a nécessairement été placé dans une slice, c'est à dire une tranche de ressources configurée dans systemd. Par défaut il y a trois grande catégories de slice présente dans systemd
- la slice system, qui lance tous les services "classiques".
- la slice user, qui lance tous les services "utilisateurs" - c'est à dire ayant besoin d'avoir accès à logind)
- la slice machine qui gère les machines virtuelles et les containers (dans une certaine mesure, tout n'est pas supporté et tout ce qui est supporté n'est pas recommandé)
Il faut bien comprendre trois choses :
- Un processus ne peut appartenir qu'à un cgroup et un seul
- Quand un processus change de hiérarchie il devient littéralement invisible aux yeux des processus qui ne sont pas dans une hiérarchie ancêtre.
- Certains processus (par exemple logind) et certains devices (les cartes réseaux notamment) ne peuvent pas être déplacés, ré-alloués ou même relancés dans un autre cgroup sans heurts. (Et par heurts je veux dire passage de systemd en mode panique totale, avec tentative de relance en boucle de certains services)
A noter que le troisième point n'est en aucun cas une faute de systemd, simplement le résultat d'un choix qui a été fait dans un soucis de simplification. La nouvelle interface résoudra ce problème via la centralisation des appels.
De fait certaines opérations sur les cgroups qui sont possibles sans systemd deviennent très complexe avec systemd.
Par exemple supposons que je veuille mettre à disposition d'un client une machine virtuelle avec une carte réseau dédiée, et en plus une interface web de monitoring sur laquelle il peut se loguer en utilisant ses identifiants utilisateurs local (ou domaine).
Maintenant supposons que je veuille mettre des restrictions à tout ça en utilisant les cgroups. La transversalité du bignou va m'obliger à créer plusieurs tranches avec systemd et à composer avec les différents éléments.
Sans systemd je peux parfaitement créer une hiérarchie globale pour le client et mettre les restrictions dessus.
En plus certaines opérations, comme allouer un coeur CPU ou une carte réseau à un cgroup défini, geler un processus ou encore taguer les paquets en fonction de leur cgroup ne sont pas encore supportées par systemd.
Pour faire court :
- Pour l'instant sur tous les processus lancés depuis un tty, ça marche et ça devrait continuer de marcher - mais peut-être avec une API différente, et peut-être avec certains manques sous le framework systemd si les fonctionnalités manquantes aux slides en sont pas implémentées.
- En ce qui concerne les processus rattachés au PID 1,à aujourd'hui il y a des limitations - elles n'impactent probablement pas grand monde (mais j'en suis et ca me casse les pieds gravement)
Pour le futur ca dépendra du controlleur de cgroups au final, sous le framework systemd il y aura très probablement des manques dus aux choix architecturaux. Mais on ne sait jamais, il faut attendre les nouvelles interface et leur intégration pour être sur.
[^] # Re: et systemd ?
Posté par Kaane . En réponse au journal Les cgroups, un outil trop méconnu. Évalué à 10.
Oui et non.
Si il s'agit d'un processus lancé depuis un terminal ou un pseudo terminal, ça ne change pas grand chose. Il y a des projets de nouvelle interface pour les cgroups qui forcera une interface centralisée. Dans les systèmes utilisant le framework systemd c'est celui-ci qui s'occupera de gérer les cgroups.L'api et les commandes seront différentes, mais dans l'ensemble les fonctionnalités devrait être sensiblement les mêmes.
Par contre si il s'agit d'un processus détaché (daemon ou autre) géré par l'init, ça devient plus compliqué. Et c'est déjà le cas aujourd'hui, même sans la nouvelle interface.
Si le processus a été lancé par systemd il a nécessairement été placé dans une slice, c'est à dire une tranche de ressources configurée dans systemd. Par défaut il y a trois grande catégories de slice présente dans systemd
- la slice system, qui lance tous les services "classiques".
- la slice user, qui lance tous les services "utilisateurs" - c'est à dire ayant besoin d'avoir accès à logind)
- la slice machine qui gère les machines virtuelles et les containers (dans une certaine mesure, tout n'est pas supporté et tout ce qui est supporté n'est pas recommandé)
Il faut bien comprendre trois choses :
- Un processus ne peut appartenir qu'à un cgroup et un seul
- Quand un processus change de hiérarchie il devient littéralement invisible aux yeux des processus qui ne sont pas dans une hiérarchie ancêtre.
- Certains processus (par exemple logind) et certains devices (les cartes réseaux notamment) ne peuvent pas être déplacés, ré-alloués ou même relancés dans un autre cgroup sans heurts. (Et par heurts je veux dire passage de systemd en mode panique totale, avec tentative de relance en boucle de certains services)
A noter que le troisième point n'est en aucun cas une faute de systemd, simplement le résultat d'un choix qui a été fait dans un soucis de simplification. La nouvelle interface résoudra ce problème via la centralisation des appels.
De fait certaines opérations sur les cgroups qui sont possibles sans systemd deviennent très complexe avec systemd.
Par exemple supposons que je veuille mettre à disposition d'un client une machine virtuelle avec une carte réseau dédiée, et en plus une interface web de monitoring sur laquelle il peut se loguer en utilisant ses identifiants utilisateurs local (ou domaine).
Maintenant supposons que je veuille mettre des restrictions à tout ça en utilisant les cgroups. La transversalité du bignou va m'obliger à créer plusieurs tranches avec systemd et à composer avec les différents éléments.
Sans systemd je peux parfaitement créer une hiérarchie globale pour le client et mettre les restrictions dessus.
En plus certaines opérations, comme allouer un coeur CPU ou une carte réseau à un cgroup défini, geler un processus ou encore taguer les paquets en fonction de leur cgroup ne sont pas encore supportées par systemd.
Pour faire court :
- Pour l'instant sur tous les processus lancés depuis un tty, ça marche et ça devrait continuer de marcher - mais peut-être avec une API différente, et peut-être avec certains manques sous le framework systemd si les fonctionnalités manquantes aux slides en sont pas implémentées.
- En ce qui concerne les processus rattachés au PID 1,à aujourd'hui il y a des limitations - elles n'impactent probablement pas grand monde (mais j'en suis et ca me casse les pieds gravement)
Pour le futur ca dépendra du controlleur de cgroups au final, sous le framework systemd il y aura très probablement des manques dus aux choix architecturaux. Mais on ne sait jamais, il faut attendre les nouvelles interface et leur intégration pour être sur.