.\" -*- coding: UTF-8 -*- .\" Copyright (C) 2015 Serge Hallyn .\" and Copyright (C) 2016, 2017 Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH cgroups 7 "2 mai 2024" "Pages du manuel de Linux 6.8" .SH NOM cgroups – Groupes de contrôle de Linux .SH DESCRIPTION .\" Les groupes de contrôle, habituellement appelés cgroups, sont une fonctionnalité du noyau Linux qui permet d'organiser les processus en groupes hiérarchiques afin de limiter et de superviser leur utilisation de types divers de ressource. L’interface cgroup du noyau est fournie à travers un pseudo\-système de fichiers appelé cgroupfs. Le regroupement est implémenté dans le code central cgroup du noyau, tandis que le suivi et les limites de ressources sont implémentés dans un ensemble de sous\-systèmes de type par ressource (mémoire, CPU, etc.). .SS Terminologie Un \fIcgroup\fP est une collection de processus qui sont liés à un ensemble de limites ou de paramètres définis à l’aide du système de fichiers cgroup. .P Un \fIsous\-système\fP est un composant du noyau qui modifie le comportement des processus dans un cgroup. Divers sous\-systèmes ont été implémentés, rendant possible de faire des choses comme la limitation de temps CPU et de mémoire disponibles pour un cgroup, la comptabilisation du temps CPU utilisé dans un cgroup et le gel ou la reprise de l’exécution des processus dans un cgroup. Les sous\-systèmes sont parfois connus comme \fIcontrôleurs de ressource\fP (ou simplement, contrôleurs). .P .\" Les cgroups pour un contrôleur sont agencés dans une \fIhiérarchie\fP. Celle\-ci est définie en créant, supprimant et renommant des sous\-répertoires dans le système de fichiers cgroup. À chaque niveau de la hiérarchie, des attributs (par exemple, des limites) peuvent être définis. Les limites, le contrôle et la comptabilisation fournis par les cgroups ont généralement des effets partout dans la sous\-hiérarchie du cgroup où les attributs sont définis. Par conséquent, par exemple, les limites placées dans un cgroup d’un niveau supérieur dans la hiérarchie ne peuvent être franchies par des cgroups descendants. .SS "Cgroups version 1 et version 2" La publication initiale de l’implémentation des cgroups a été faite dans Linux 2.6.24. Au cours du temps, divers contrôleurs de cgroup ont été ajoutés pour permettre la gestion de divers types de ressources. Cependant, le développement de ces contrôleurs n’a pas été coordonné en grande partie avec pour résultat l'apparition de nombreuses incohérences entre les contrôleurs et une complexité accrue de la gestion des hiérarchies de cgroup. Une description plus complète de ces problèmes peut être trouvée dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v2.rst\fP (ou \fIDocumentation/cgroup\-v2.txt\fP dans Linux version 4.17 et précédentes). .P À cause des problèmes avec l’implémentation initiale des cgroups (cgroups version 1), des travaux ont commencé, à partir de Linux 3.10, sur une nouvelle implémentation indépendante pour remédier à ces problèmes. Au départ marquée comme expérimentale, et dissimulée derrière l’option de montage \fI\-o\ __DEVEL__sane_behavior\fP, la nouvelle version (cgroups version 2) est devenue finalement officielle avec la publication de Linux 4.5. Les différences entre les deux versions sont décrites dans le texte qui suit. Le fichier \fIcgroup.sane_behavior\fP, présent dans cgroups version 1, est un vestige de cette option de montage. Le fichier indique toujours « 0 » et n’est conservé que pour la rétrocompatibilité. .P .\" Bien que cgroups version 2 soit destiné à remplacer la version 1, l’ancien système continue à exister (et pour des raisons de compatibilité, ne sera vraisemblablement pas supprimé). Actuellement, cgroups version 2 implémente un sous\-ensemble de contrôleurs disponibles dans cgroups version 1. Les deux systèmes sont implémentés de façon que les contrôleurs version 1 et 2 puissent être montés sur le même système. Ainsi, par exemple, il est possible d’utiliser les contrôleurs qui sont pris en charge par la version 2, tout en utilisant aussi des contrôleurs version 1 là où la version 2 ne les prend pas encore en charge. La seule restriction ici est qu’un contrôleur ne peut pas être employé simultanément dans une hiérarchie de cgroups version 1 et dans une hiérarchie de cgroups version 2. .SH "CGROUPS VERSION 1" Sous cgroups version 1, chaque contrôleur peut être monté pour un système de fichiers cgroup distinct qui fournit sa propre organisation hiérarchique des processus dans le système. Il est aussi possible de co\-monter plusieurs (et même tous) les contrôleurs de cgroups version 1 pour le même système de fichiers cgroup, ce qui signifie que les contrôleurs co\-montés gèrent la même organisation hiérarchique des processus. .P .\" Pour chaque hiérarchie montée, l’arbre de répertoires reflète la hiérarchie de groupes de contrôle. Chaque groupe de contrôle est représenté par un répertoire, avec chaque cgroup de contrôle enfant représenté par un répertoire enfant. Par exemple, \fI/user/joe/1.session\fP représente le groupe de contrôle \fI1.session\fP, qui est un enfant du cgroup \fIjoe\fP, qui est un enfant de \fI/user\fP. Sous chaque répertoire cgroup existe un ensemble de fichiers qui peuvent être lus ou écrits, reflétant les limites de ressources et quelques propriétés générales du cgroup. .SS "Tâches (threads) versus processus" Dans cgroups version 1, une distinction est faite entre les \fIprocessus\fP et les \fItâches\fP. De ce fait, un processus peut consister en plusieurs tâches (plus couramment appelées threads, du point de vue espace utilisateur, et appelées ainsi dans la suite de cette page de manuel). Dans cgroups version 1, il est possible de manipuler indépendamment l’appartenance de cgroup des threads d’un processus. .P .\" La capacité de cgroups version 1 de répartir les threads dans des cgroups différents cause des problèmes dans certains cas. Par exemple, cela n’a aucun sens pour le contrôleur de \fImémoire\fP, puisque tous les threads d’un processus partagent un même espace d’adressage. À cause de cela, la capacité de manipuler indépendamment l’appartenance de cgroup des threads dans un processus a été retirée dans l’implémentation initiale de cgroups version 2, et ultérieurement restaurée dans une forme plus limitée (voir l’explication sur le « mode threads » ci\-après). .SS "Montage de contrôleurs version 1" L’utilisation de cgroups requiert un noyau construit avec l’option \fBCONFIG_CGROUP\fP. De plus, chaque contrôleur version 1 possède une option de configuration associée qui doit être définie pour utiliser ce contrôleur. .P Pour utiliser un contrôleur version 1, il doit être monté pour un système de fichiers de cgroup. L’emplacement habituel de tels montages est sous le système de fichiers \fBtmpfs\fP(5) monté dans \fI/sys/fs/cgroup\fP. Par conséquent, un montage du contrôleur \fIcpu\fP peut être réalisé ainsi : .P .in +4n .EX mount \-t cgroup \-o cpu none /sys/fs/cgroup/cpu .EE .in .P Il est possible de co\-monter plusieurs contrôleurs pour la même hiérarchie. Ici par exemple, les contrôleurs \fIcpu\fP et \fIcpuacct\fP sont co\-montés pour une même hiérarchie : .P .in +4n .EX mount \-t cgroup \-o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct .EE .in .P Le co\-montage de contrôleurs fait qu’un processus est dans le même cgroup pour tous les contrôleurs co\-montés. Séparer le montage de contrôleurs permet à un processus d’être dans le cgroup \fI/toto1\fP pour un contrôleur tout en étant dans \fI/toto2/toto3\fP pour un autre. .P Il est possible de co\-monter tous les contrôleurs version 1 pour la même hiérarchie : .P .in +4n .EX mount \-t cgroup \-o all cgroup /sys/fs/cgroup .EE .in .P (Le même résultat peut être obtenu en omettant \fI\-o\ all\fP, puisque c’est le comportement par défaut si aucun contrôleur n’est explicitement précisé.) .P Il n’est pas possible de monter le même contrôleur pour plusieurs hiérarchies de cgroup. Par exemple, il n’est pas possible de monter à la fois les contrôleurs \fIcpu\fP et \fIcpuacct\fP pour une même hiérarchie et de monter le contrôleur \fIcpu\fP seul pour une autre hiérarchie. Il est possible de créer plusieurs montages avec exactement le même ensemble de contrôleurs co\-montés. Dans ce cas cependant, tout cela aboutit à ce que plusieurs points de montage fournissent une vue de la même hiérarchie. .P .\" Remarquez que sur de nombreux systèmes, les contrôleurs version 1 sont automatiquement montés sous \fI/sys/fs/cgroup\fP. En particulier, \fBsystemd\fP(1) crée automatiquement de tels montages. .SS "Démontage des contrôleurs version 1" Un système de fichiers cgroup monté peut être démonté en utilisant la commande \fBumount\fP(8) comme dans l’exemple suivant : .P .in +4n .EX umount /sys/fs/cgroup/pids .EE .in .P .\" \fIBien remarquer\fP qu’un système de fichiers de cgroup est démonté seulement s’il n’est pas en cours d’utilisation, c’est\-à\-dire qu’il n’a pas de cgroups enfants. Si ce n’est pas le cas, le seul effet de \fBumount\fP(8) est de rendre le montage invisible. Par conséquent, pour être sûr que le montage est réellement retiré, les cgroups enfants doivent d’abord être retirés, ce qui à son tour ne peut être fait qu'après que tous les processus membres ont été déplacés de ces cgroups vers le cgroup racine. .SS "Contrôleurs de cgroups version 1" Chacun de ces contrôleurs de cgroups version 1 est régi par une option de configuration du noyau (liste ci\-après). De plus, la disponibilité de la fonctionnalité des cgroups est régie par l’option de configuration \fBCONFIG_CGROUPS\fP du noyau. .TP \fIcpu\fP (depuis Linux 2.6.24 ; \fBCONFIG_CGROUP_SCHED\fP) Un nombre minimal de « partages de CPU » peut être garanti quand un système est actif. Cela ne limite pas l'utilisation de CPU par un cgroup si les CPU ne sont pas actifs. Pour plus d’informations, consultez \fIDocumentation/scheduler/sched\-design\-CFS.rst\fP (ou \fIDocumentation/scheduler/sched\-design\-CFS.txt\fP dans Linux 5.2 et les versions antérieures). .IP Dans Linux 3.2, ce contrôleur a été étendu pour fournir un contrôle de la « bande passante » du CPU. Si le noyau est configuré avec \fBCONFIG_CFS_BANDWIDTH\fP, il est possible de définir une limite haute du temps CPU alloué aux processus d’un cgroup à chaque période de planification (définie à l’aide d’un fichier dans le répertoire de cgroup). La limite haute s’applique même s’il n’existe aucune compétition pour le CPU. Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/scheduler/sched\-bwc.rst\fP (ou \fIDocumentation/scheduler/sched\-bwc.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIcpuacct\fP (depuis 2.6.24 ; \fBCONFIG_CGROUP_CPUACCT\fP) Ce contrôleur fournit la comptabilisation de l’utilisation du CPU par des groupes de processus. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/cpuacct.rst\fP (ou \fIDocumentation/cgroup\-v1/cpuacct.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIcpuset\fP (depuis Linux 2.6.24 ; \fBCONFIG_CPUSETS\fP) Ce cgroup peut être utilisé pour lier les processus dans un cgroup à un ensemble spécifié de CPU ou de nœuds NUMA. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/cpusets.rst\fP (ou \fIDocumentation/cgroup\-v1/cpusets.txt\fP dans Linux 5.2 et les versions précédentes). . .TP \fImemory\fP (depuis Linux 2.6.25 ; \fBCONFIG_MEMCG\fP) Le contrôleur de mémoire prend en charge le rapport et la limitation de la mémoire du processus, de la mémoire du noyau et de la partition d’échange utilisées par les cgroups. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/memory.rst\fP (ou \fIDocumentation/cgroup\-v1/memory.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIdevices\fP (depuis Linux 2.6.26 ; \fBCONFIG_CGROUP_DEVICE\fP) Ce contrôleur prend en charge la définition des processus qui pourront créer (mknod) des périphériques et les ouvrir en lecture ou écriture. Les politiques peuvent être précisées dans des listes d’autorisations ou de refus. La hiérarchie est imposée, aussi des règles nouvelles ne doivent pas violer les règles existantes pour la cible ou pour des cgroups ancêtres. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/devices.rst\fP (ou \fIDocumentation/cgroup\-v1/devices.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIfreezer\fP (depuis Linux 2.6.28 ; \fBCONFIG_CGROUP_FREEZER\fP) Le cgroup \fIfreezer\fP peut suspendre ou restaurer (reprendre) tous les processus d’un cgroup. Geler un cgroup \fI/A\fP fait que ses enfants, par exemple les processus dans \fI/A/B\fP, sont gelés. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/freezer\-subsystem.rst\fP (ou \fIDocumentation/cgroup\-v1/freezer\-subsystem.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fInet_cls\fP (depuis Linux 2.6.29 ; \fBCONFIG_CGROUP_NET_CLASSID\fP) Ce contrôleur place un identificateur de classe (classid), précisé pour le cgroup, sur des paquets réseau créés par un cgroup. Ces identificateurs peuvent être utilisés dans des règles de pare\-feu, ainsi que pour canaliser le trafic en utilisant \fBtc\fP(8). Cela s’applique aux paquets quittant le cgroup, pas au trafic y arrivant. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/net_cls.rst\fP (ou \fIDocumentation/cgroup\-v1/net_cls.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIblkio\fP (depuis Linux 2.6.33 ; \fBCONFIG_BLK_CGROUP\fP) Le cgroup \fIblkio\fP contrôle et limite l’accès aux périphériques en mode bloc indiqués en appliquant un contrôle d’E/S sous forme de restrictions et de limites d’accès à l’encontre de nœuds feuilles et de nœuds intermédiaires dans la hiérarchie de stockage. .IP Deux politiques sont possibles. La première est une division du disque proportionnelle au poids basée sur la durée et implémentée avec CFQ (Completely Fair Queuing — file d'attente complètement équitable). C’est le cas pour les nœuds feuilles utilisant CFQ. La seconde est une politique d’étranglement qui précise les limites supérieures de taux d’E/S sur un périphérique. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/blkio\-controller.rst\fP (ou \fIDocumentation/cgroup\-v1/blkio\-controller.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIperf_event\fP (depuis Linux 2.6.39 ; \fBCONFIG_CGROUP_PERF\fP) Ce contrôleur permet à \fIperf\fP de superviser l’ensemble des processus groupés dans un cgroup. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau. .TP \fInet_prio\fP (depuis Linux 3.3 ; \fBCONFIG_CGROUP_NET_PRIO\fP) Ce contrôleur permet de définir des priorités par interface réseau pour les cgroups. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/net_prio.rst\fP (ou \fIDocumentation/cgroup\-v1/net_prio.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIhugetlb\fP (depuis Linux 3.5 ; \fBCONFIG_CGROUP_HUGETLB\fP) Ce contrôleur prend en charge la limitation de l’utilisation de très grandes pages par les cgroups. .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/hugetlb.rst\fP (ou \fIDocumentation/cgroup\-v1/hugetlb.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIpids\fP (depuis Linux 4.3 ; \fBCONFIG_CGROUP_PIDS\fP) Ce contrôleur permet de limiter le nombre de processus pouvant être créés dans un cgroup (et ses descendants). .IP Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/pids.rst\fP (ou \fIDocumentation/cgroup\-v1/pids.txt\fP dans Linux 5.2 et les versions antérieures). .TP \fIrdma\fP (depuis Linux 4.11 ; \fBCONFIG_CGROUP_RDMA\fP) Le contrôleur RDMA permet de limiter l’utilisation de ressources spécifiques à RDMA/IB. .IP .\" Plus d’informations sont disponibles dans le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v1/rdma.rst\fP (ou \fIDocumentation/cgroup\-v1/rdma.txt\fP dans Linux 5.2 et les versions antérieures). .SS "Création de cgroups et déplacement de processus" Un système de fichiers de cgroup contient initialement un seul cgroup racine, « / », auquel tous les processus appartiennent. Un nouveau cgroup est créé en créant un répertoire dans le système de fichiers de cgroup : .P .in +4n .EX mkdir /sys/fs/cgroup/cpu/cg1 .EE .in .P Cette commande crée un nouveau cgroup vide. .P Un processus peut être transféré dans ce cgroup en écrivant son PID dans le fichier \fIcgroup.procs\fP du cgroup : .P .in +4n .EX echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs .EE .in .P Un seul PID à la fois peut être écrit dans ce fichier. .P Écrire la valeur 0 dans un fichier \fIcgroup.procs\fP fait que le processus écrivain est transféré dans le cgroup correspondant. .P Quand un PID est écrit dans le fichier \fIcgroup.procs\fP, tous les threads du processus sont transférés ensemble dans le nouveau cgroup. .P Dans une hiérarchie, un processus peut être membre d'un et un seul cgroup. Écrire un PID de processus dans un fichier \fIcgroup.procs\fP le retire automatiquement du cgroup auquel il appartenait précédemment. .P Le fichier \fIcgroup.procs\fP peut être lu pour obtenir une liste des processus qui sont membres d’un cgroup. L'absence de doublons dans la liste renvoyée des PID n’est pas garantie et cette dernière ne sera pas forcément triée. Par exemple, un PID peut être recyclé pendant la lecture de la liste. .P .\" Dans cgroups version 1, un thread individuel peut être transféré dans un autre cgroup en écrivant son ID de thread (c’est\-à\-dire l’ID de thread du noyau renvoyé par \fBclone\fP(2) et \fBgettid\fP(2)) dans le fichier \fItasks\fP d'un répertoire de cgroup. Ce fichier peut être lu pour découvrir l’ensemble des threads membres du cgroup. .SS "Suppression de cgroups" .\" Pour supprimer un cgroup, il doit tout d’abord n’avoir aucun cgroup enfant et ne contenir aucun processus (non zombie). Tant que c’est le cas, on peut simplement supprimer le nom de chemin de répertoire correspondant. Remarquez que les fichiers dans le répertoire de cgroup ne peuvent et n’ont pas besoin d’être supprimés. .SS "Notification de publication de cgroups version 1" Deux fichiers peuvent être utilisés pour déterminer si le noyau fournit des notifications quand un cgroup devient vide. Un cgroup est considéré comme vide quand il ne contient ni cgroup enfant, ni processus membre. .P Un fichier spécial dans le répertoire racine de chaque hiérarchie de cgroup, \fIrelease_agent\fP, peut être utilisé pour enregistrer le nom de chemin d’un programme pouvant être invoqué quand un cgroup dans la hiérarchie devient vide. Le nom de chemin du cgroup nouvellement vide (relatif au point de montage du cgroup) est fourni comme seul argument de ligne de commande quand le programme \fIrelease_agent\fP est invoqué. Le programme \fIrelease_agent\fP pourrait supprimer le répertoire du cgroup ou, peut être, le repeupler avec un processus. .P Par défaut, le fichier \fIrelease_agent\fP est vide, signifiant qu’aucun agent de publication n’est invoqué. .P Le contenu du fichier \fIrelease_agent\fP peut être spécifié à l’aide d’une option de montage quand le système de fichiers de cgroup est monté : .P .in +4n .EX mount \-o release_agent=pathname ... .EE .in .P .\" Que le programme \fIrelease_agent\fP soit invoqué ou pas quand un cgroup particulier devient vide est déterminé par la valeur inscrite dans le fichier \fInotify_on_release\fP dans le répertoire de cgroup correspondant. Si ce fichier contient la valeur 0, alors le programme \fIrelease_agent\fP n’est pas invoqué. Si cette valeur est 1, le programme \fIrelease_agent\fP est invoqué. La valeur par défaut inscrite dans ce fichier dans le cgroup racine est 0. Au moment de la création d’un nouveau cgroup, la valeur dans ce fichier est héritée du fichier correspondant dans le cgroup parent. .SS "Hiérarchies nommées de cgroups version 1" Dans cgroups version 1, il est possible de monter une hiérarchie de cgroup qui n’a pas de contrôleurs attachés. .P .in +4n .EX mount \-t cgroup \-o none,name=un_nom none /un/point/de/montage .EE .in .P Plusieurs instances de telles hiérarchies peuvent être montées, chaque hiérarchie devant avoir un nom unique. Le seul but de telles hiérarchies est de suivre les processus (consultez les explications de notification de publication ci\-dessous). La hiérarchie de cgroup \fIname=systemd\fP qui est utilisée par \fBsystemd\fP(1) pour suivre les services et les sessions d’utilisateur en est un exemple. .P .\" Depuis Linux 5.0, l’option d’amorçage \fIcgroup_no_v1\fP du noyau (décrite ci\-après) peut être utilisée pour désactiver les hiérarchies nommées de cgroups version 1, en spécifiant \fIcgroup_no_v1=named\fP. .SH "CGROUPS VERSION 2" Dans cgroups version 2, tous les contrôleurs montés résident dans une seule hiérarchie unifiée. Alors que des contrôleurs (différents) peuvent être montés simultanément dans des hiérarchies version 1 ou 2, il n’est pas possible de monter le même contrôleur simultanément dans les deux hiérarchies version 1 et version 2. .P Les nouveaux comportements dans cgroups version 2 sont résumés ici et, dans quelques cas, développés dans les sous\-sections suivantes. .IP \- 3 Les cgroups version 2 fournissent une hiérarchie unifiée pour laquelle tous les contrôleurs sont montés. .IP \- Les processus « internes » ne sont pas autorisés. À l’exception du cgroup racine, les processus ne peuvent résider que dans les nœuds feuilles (les cgroups qui ne contiennent pas eux\-mêmes de cgroups enfants). Les détails sont un peu plus subtils que ça et sont décrits ci\-après. .IP \- Les cgroups actifs doivent être indiqués à l’aide des fichiers \fIcgroup.controllers\fP et \fIcgroup.subtree_control\fP. .IP \- Le fichier \fItasks\fP et le fichier \fIcgroup.clone_children\fP qui est utilisé par le contrôleur \fIcpuset\fP ont été supprimés. .IP \- Un mécanisme amélioré pour la notification de cgroups vides est fourni par le fichier \fIcgroup.events\fP. .P Pour plus de détails sur les modifications, consultez le fichier \fIDocumentation/admin\-guide/cgroup\-v2.rst\fP dans les sources du noyau (ou \fIDocumentation/cgroup\-v2.txt\fP dans Linux 4.17 et les versions antérieures). . .P .\" Certains de ces nouveaux comportements intègrent une modification avec l’ajout dans Linux 4.14 du « mode thread » (décrit ci\-après). .SS "Hiérarchie unifiée de cgroups version 2" Dans les cgroups version 1, la possibilité de monter différents contrôleurs pour différentes hiérarchies était voulue pour permettre une grande flexibilité dans la conception des applications. En pratique, la flexibilité s’est avérée moins utile qu’espérée et, dans de nombreux de cas, a ajouté de la complexité. Par conséquent, dans cgroups version 2, tous les contrôleurs disponibles sont montés pour une seule hiérarchie. Les contrôleurs disponibles sont automatiquement montés, ce qui signifie qu’il n’est pas nécessaire (ou possible) d’indiquer les contrôleurs lors du montage d’un système de fichiers cgroups version 2 en utilisant une commande telle que la suivante : .P .in +4n .EX mount \-t cgroup2 none /mnt/cgroup2 .EE .in .P Un contrôleur cgroups version 2 est disponible seulement s’il n’est pas en cours d’utilisation à l’aide d’un montage pour une hiérarchie de cgroups version 1. Ou, pour dire les choses autrement, il n’est pas possible d’employer le même contrôleur pour les deux hiérarchies version 1 et version 2 unifiée. Cela signifie qu’il peut être nécessaire d’abord de démonter un contrôleur version 1 (comme décrit ci\-dessus) avant que ce contrôleur soit disponible en version 2. Puisque \fBsystemd\fP(1) utilise abondamment quelques contrôleurs version 1 par défaut, il peut dans certains cas être plus simple d’amorcer le système avec ces contrôleurs version 1 désactivés. Pour ce faire, spécifier l’option \fIcgroup_no_v1=list\fP sur la ligne de commande d’amorçage du noyau. \fIlist\fP est une liste de noms séparés par des virgules des contrôleurs à désactiver ou le mot \fIall\fP pour désactiver tous les contrôleurs version 1. Cette situation est gérée correctement par \fBsystemd\fP(1), ce qui revient à un amorçage sans ces contrôleurs. .P .\" Remarquez que sur de nombreux systèmes modernes, \fBsystemd\fP(1) monte automatiquement le système de fichiers \fIcgroup2\fP dans \fI/sys/fs/cgroup/unified\fP lors du processus d’amorçage. .SS "Options de montage pour cgroups version 2" Les options suivantes (\fImount\ \-o\fP) peuvent être spécifiées lors du montage de systèmes de fichiers de groupe version 2 : .TP \fInsdelegate\fP (depuis Linux 4.15) Traitement des espaces de noms cgroup comme des limites de délégation. Pour plus de détails, voir ci\-dessous. .TP \fImemory_localevents\fP (depuis Linux 5.2) .\" commit 9852ae3fe5293264f01c49f2571ef7688f7823ce .\" \fImemory.events\fP devrait afficher des statistiques seulement pour le cgroup lui\-même, pas pour les cgroups descendants. C’était le comportement avant Linux 5.2. Depuis Linux 5.2, le comportement par défaut consiste à inclure des statistiques pour les cgroups descendants dans \fImemory.events\fP et cette option de montage peut être utilisée pour revenir au comportement traditionnel. Cette option s’applique au système entier et peut être définie au moment du montage ou modifiée à travers un remontage seulement à partir de l’espace de noms montage initial. Elle est silencieusement ignorée dans les espaces de noms non initiaux. .SS "Contrôleurs de cgroups version 2" Les contrôleurs suivants, documentés dans le fichier source du noyau \fIDocumentation/admin\-guide/cgroup\-v2.rst\fP (ou \fIDocumentation/cgroup\-v2.txt\fP dans Linux 4.17 et les versions antérieures) sont pris en charge dans cgroups version 2 : .TP \fIcpu\fP (depuis Linux 4.15) C’est le successeur des contrôleurs version 1 \fIcpu\fP et \fIcpuacct\fP. .TP \fIcpuset\fP (depuis Linux 5.0) C’est le successeur du contrôleur version 1 \fIcpuset\fP. .TP \fIfreezer\fP (depuis Linux 5.2) .\" commit 76f969e8948d82e78e1bc4beb6b9465908e74873 C’est le successeur du contrôleur version 1 \fIfreezer\fP. .TP \fIhugetlb\fP (depuis Linux 5.6) C’est le successeur du contrôleur version 1 \fIhugetlb\fP. .TP \fIio\fP (depuis Linux 4.5) C’est le successeur du contrôleur version 1 \fIblkio\fP. .TP \fImemory\fP (depuis Linux 4.5) C’est le successeur du contrôleur version 1 \fImemory\fP. .TP \fIperf_event\fP (depuis Linux 4.11) Identique au contrôleur version 1 \fIperf_event\fP. .TP \fIpids\fP (depuis Linux 4.5) Identique au contrôleur version 1 \fIpids\fP. .TP \fIrdma\fP (depuis Linux 4.11) Identique au contrôleur version 1 \fIrdma\fP. .P Il n’existe pas d’équivalent direct des contrôleurs \fInet_cls\fP et \fInet_prio\fP de cgroups version 1. À la place, une prise en charge a été ajoutée à \fBiptables\fP(8) pour permettre aux filtres eBPF qui s’attachent aux noms de chemin de cgroups version 2 de prendre des décisions à partir du trafic réseau selon le cgroup. .P .\" Les contrôleurs version 2 \fIdevices\fP ne fournissent pas de fichiers d’interface. À la place, le contrôle de périphérique est sécurisé en attachant un programme eBPF (\fBBPF_CGROUP_DEVICE\fP) à un cgroup version 2. .SS "Contrôle de sous\-arbres de cgroups version 2" Chaque cgroup dans une hiérarchie version 2 contient les deux fichiers suivants : .TP \fIcgroup.controllers\fP Ce fichier en lecture seule contient une liste des contrôleurs qui sont \fIdisponibles\fP dans ce cgroup. Le contenu de ce fichier correspond au contenu du fichier \fIcgroup.subtree_control\fP dans le cgroup parent. .TP \fIcgroup.subtree_control\fP Ce fichier contient une liste de contrôleurs qui sont \fIactifs\fP (\fIpermis\fP) dans le cgroup. L’ensemble des contrôleurs dans ce fichier est un sous\-ensemble de l’ensemble \fIcgroup.controllers\fP de ce cgroup. L’ensemble des contrôleurs actifs est modifié en écrivant des chaînes dans ce fichier contenant des noms de contrôleurs séparés par des espaces, chacun étant précédé par un « + » (pour autoriser le contrôleur) ou un « \- » (pour interdire le contrôleur), comme dans l’exemple suivant : .IP .in +4n .EX echo \[aq]+pids \-memory\[aq] > x/y/cgroup.subtree_control .EE .in .IP Un essai pour autoriser un contrôleur qui n’est pas présent dans \fIcgroup.controllers\fP provoque une erreur \fBENOENT\fP lors d’une écriture dans le fichier \fIcgroup.subtree_control\fP. .P Parce que la liste de contrôleurs dans \fIcgroup.subtree_control\fP est un sous\-ensemble de ces \fIcgroup.controllers\fP, un contrôleur qui n’est plus autorisé dans un cgroup de la hiérarchie ne peut jamais être réautorisé dans un sous\-arbre de ce cgroup. .P .\" Un fichier \fIcgroup.subtree_control\fP de cgroup détermine l’ensemble des contrôleurs qui sont activés dans les cgroups \fIenfants\fP. Quand un contrôleur (par exemple, \fIpids\fP) est présent dans le fichier \fIcgroup.subtree_control\fP d’un cgroup parent, les fichiers correspondants interface\-contrôleur (par exemple, \fIpids.max\fP) sont automatiquement créés dans l’enfant de ce cgroup et peuvent être utilisés pour exercer le contrôle des ressources dans les cgroups enfants. .SS "Règle « pas de processus internes » pour cgroups version 2" Cgroups version 2 applique une règle appelée « pas de processus internes ». En gros, cette règle veut dire que, à l’exception du cgroup racine, les processus ne peuvent résider que dans les nœuds feuilles (des cgroups ne contenant pas eux\-mêmes de cgroup enfant). Cela évite d'avoir à décider comment partager les ressources entre les processus qui sont membres du cgroup A et les processus dans des cgroups enfants de A. .P Par exemple, si le cgroup \fI/cg1/cg2\fP existe, un processus peut résider dans \fI/cg1/cg2\fP, mais pas dans \fI/cg1\fP. Cela permet d'éviter une ambiguïté dans cgroups version 1 par rapport à la délégation de ressources entre les processus dans \fI/cg1\fP et les cgroups enfants. L’approche recommandée dans cgroups version 2 consiste à créer un sous\-répertoire appelé \fIfeuille\fP pour n’importe quel cgroup non feuille qui contiendrait des processus mais pas de cgroup enfant. Ainsi, les processus qui auparavant seraient allés dans \fI/cg1\fP iraient maintenant dans \fI/cg1/feuille\fP. Cela a l’avantage de rendre explicite la relation entre les processus dans \fI/cg1/feuille\fP et les autres enfants de \fI/cg1\fP. .P La règle « pas de processus internes » est en fait plus subtile que ce qui est décrit ci\-dessus. Plus précisément, la règle stipule qu’un cgroup (non racine) ne peut pas à la fois avoir des processus membres et distribuer des ressources aux cgroups enfants — c’est\-à\-dire avoir un fichier \fIcgroup.subtree_control\fP non vide. Par conséquent, il \fIest\fP possible pour un cgroup d’avoir à la fois des processus membres et des cgroups enfants, mais pour que les contrôleurs puissent être autorisés pour ce cgroup, les processus membres doivent être déplacés en dehors du cgroup (par exemple, dans les cgroups enfants). .P .\" Avec l’addition dans Linux 4.14 du « mode thread » (décrit ci\-après), la règle « pas de processus internes » a été assouplie dans certains cas. .SS "Fichier cgroup.events de cgroups version 2" Chaque cgroup non racine dans la hiérarchie version 2 contient un fichier en lecture seule, \fIcgroup.events\fP, dont le contenu consiste en paires clé\-valeur (délimitées par des caractères de nouvelle ligne, avec les clés et valeurs séparées par des espaces) fournissant des informations d’état sur le cgroup : .P .in +4n .EX $ \fBcat mygrp/cgroup.events\fP populated 1 frozen 0 .EE .in .P Les clés suivantes peuvent apparaître dans ce fichier : .TP \fIpopulated\fP La valeur de cette clé est soit 1 si ce cgroup ou n’importe lequel de ses descendants a des processus membres, soit 0 dans le cas contraire. .TP \fIfrozen\fP (depuis Linux 5.2) .\" commit 76f969e8948d82e78e1bc4beb6b9465908e7487 La valeur de cette clé est 1 si ce cgroup est actuellement gelé ou 0 s’il ne l’est pas. .P .\" Le fichier \fIcgroup.events\fP peut être surveillé dans le but de recevoir des notifications quand la valeur d’une des clés change. Cette surveillance peut être réalisée en utilisant \fBinotify\fP(7), qui notifie les changements tels que les évènements \fBIN_MODIFY\fP ou \fBpoll\fP(2) qui notifie les changements en renvoyant les bits \fBPOLLPRI\fP et \fBPOLLERR\fP dans le champ \fIrevents\fP. .SS "Notification de libération de cgroups version 2" Les cgroups version 2 fournissent un nouveau mécanisme pour recevoir des notifications lorsqu’un cgroup devient vide. Les fichiers cgroups version 1 \fIrelease_agent\fP et \fInotify_on_release\fP sont supprimés et remplacés par la clé \fIpopulated\fP dans le fichier \fIcgroup.events\fP. Cette clé a soit la valeur 0, signifiant que le cgroup (et ses descendants) ne contient aucun processus membre (non zombie), ou 1, signifiant que le cgroup (ou un de ses descendants) contient des processus membres. .P Le mécanisme de notification de libération de cgroups version 2 offre les avantages suivants par rapport au mécanisme \fIrelease_agent\fP de cgroups version 1 : .IP \- 3 IL permet une notification moins coûteuse puisqu’un seul processus peut contrôler plusieurs fichiers \fIcgroup.events\fP (en utilisant les techniques décrites précédemment). En revanche, le mécanisme de cgroups version 1 requiert la charge de créer un processus pour chaque notification. .IP \- .\" Les notifications pour des sous\-hiérarchies différentes de cgroup peuvent être déléguées à des processus différents. En revanche, le mécanisme de cgroups version 1 permet seulement un agent de notification pour la hiérarchie complète. .SS "Fichier cgroup.stat de cgroups version 2" .\" commit ec39225cca42c05ac36853d11d28f877fde5c42e Chaque cgroup d’une hiérarchie version 2 contient un fichier \fIcgroup.stat\fP en lecture seule (introduit en premier dans Linux 4.14) qui consiste en lignes contenant des paires clé\-valeur. Les clés suivantes apparaissent actuellement dans ce fichier : .TP \fInr_descendants\fP C’est le nombre total de cgroups descendants visibles (c’est\-à\-dire en vivants) en dessous de ce cgroup. .TP \fInr_dying_descendants\fP C’est le nombre de cgroups descendants mourants en dessous de ce cgroup. Un cgroup devient mourant après avoir été supprimé. Il reste dans cet état pour une période indéfinie (qui dépend de la charge du système) pendant que les ressources sont libérées avant que le cgroup soit détruit. Remarquez que la présence de quelques cgroups dans l’état mourant est normal et n’indique pas un quelconque problème. .IP .\" Un processus ne peut devenir membre d’un cgroup mourant et celui\-ci ne peut redevenir actif. .SS "Limitation du nombre de cgroups descendants" Chaque cgroup dans une hiérarchie version 2 contient les fichiers suivants qui peuvent être utilisés pour afficher et définir les limites du nombre de cgroups descendants dans ce cgroup : .TP \fIcgroup.max.depth\fP (depuis Linux 4.14) .\" commit 1a926e0bbab83bae8207d05a533173425e0496d1 Ce fichier définit une limite sur le niveau d’imbrication de cgroups descendants. Une valeur de 0 dans ce fichier signifie qu’aucun cgroup descendant ne peut être créé. Un essai de création dont le niveau d’imbrication excède la limite échouera (\fImkdir\fP(2) échoue avec l’erreur \fBEAGAIN\fP). .IP Écrire la chaîne \fI\[dq]max\[dq]\fP dans ce fichier signifie qu’aucune limite n’est imposée. La valeur par défaut dans ce fichier est \fI\[dq]max\[dq]\fP. .TP \fIcgroup.max.descendants\fP (depuis Linux 4.14) .\" commit 1a926e0bbab83bae8207d05a533173425e0496d1 Ce fichier définit une limite du nombre de cgroups descendants actifs que ce cgroup peut posséder. Un essai de créer plus de descendants qu’autorisés par la limite échoue (\fImkdir\fP(2) échoue avec l’erreur \fBEAGAIN\fP). .IP .\" Écrire la chaîne \fI\[dq]max\[dq]\fP dans ce fichier signifie qu’aucune limite n’est imposée. La valeur par défaut dans ce fichier est \fI\[dq]max\[dq]\fP. .SH "DÉLÉGATION DE CGROUPS À UN UTILISATEUR AVEC DES PRIVILÈGES MOINDRES" Dans le contexte de cgroups, déléguer signifie transmettre la gestion d'un sous\-arbre de la hiérarchie de cgroup à un utilisateur non privilégié. Cgroups version 1 fournit une prise en charge de la délégation basée sur les permissions de fichier dans la hiérarchie de cgroup, mais avec des règles de confinement moins strictes que dans la version 2 (comme signalé ci\-dessous). Cgroups version 2 gère la délégation avec confinement selon un modèle explicite. L’explication dans cette section se concentre sur la délégation dans cgroups version 2, avec quelques différences pour cgroups version 1 signalées au fur et à mesure. .P Un peu de terminologie est nécessaire pour expliquer la délégation. Un \fIdélégant\fP est un utilisateur privilégié (c’est\-à\-dire le superutilisateur) qui possède un cgroup parent. Un \fIdélégué\fP est un utilisateur non privilégié à qui sont accordées les permissions nécessaires pour gérer une sous\-hiérarchie sous le cgroup parent, connue comme le \fIsous\-arbre délégué\fP. .P Pour réaliser la délégation, le délégant autorise l'écriture par le délégué sur certains répertoires et fichiers, typiquement en transférant la propriété des objets à l’ID utilisateur du délégué. En supposant une délégation de hiérarchie de racine (par exemple) \fI/dlgt_grp\fP et qu’il n’y a pas encore de cgroup enfant sous ce cgroup, la propriété de ce qui suit est transférée à l’ID utilisateur du délégué : .TP \fI/dlgt_grp\fP Modifier le propriétaire de la racine d’un sous\-arbre signifie que n’importe quel cgroup nouvellement créé dans ce sous\-arbre (et les fichiers qu’il contient) sera aussi la propriété du délégué. .TP \fI/dlgt_grp/cgroup.procs\fP Modifier le propriétaire de ce fichier signifie que le délégué peut déplacer les processus dans la racine du sous\-arbre délégué. .TP \fI/dlgt_grp/cgroup.subtree_control\fP (cgroups version 2 seulement) Modifier le propriétaire de ce fichier signifie que le délégué peut activer des contrôleurs (qui sont présents dans \fI/dlgt_grp/cgroup.controllers\fP) dans le but d’une redistribution postérieure des ressources à des niveaux inférieurs du sous\-arbre. Comme alternative au changement de propriétaire de ce fichier, le délégant pourrait à la place ajouter les contrôleurs sélectionnés dans ce fichier. .TP \fI/dlgt_grp/cgroup.threads\fP (cgroups version 2 seulement) Modifier le propriétaire de ce fichier est nécessaire si un sous\-arbre threaded est sous le coup d’une délégation (consultez la description du « mode thread » ci\-dessous). Cela permet au délégué d’écrire des ID de thread dans ce fichier. Le propriétaire de ce fichier peut être aussi changé lors de la délégation d’un sous\-arbre de domaine, mais actuellement cela ne sert à rien puisque, comme décrit ci\-dessous, il n’est pas possible de déplacer un thread entre des cgroups de domaine en inscrivant son ID de thread dans le fichier \fIcgroup.threads\fP. .IP Pour les cgroups version 1, le fichier correspondant qui doit être délégué est le fichier \fItasks\fP. .P Le délégant ne doit \fIpas\fP changer le propriétaire de n’importe quel fichier d’interface de contrôleur (par exemple, \fIpids.max\fP, \fImemory.high\fP) dans \fIdlgt_grp\fP. Ces fichiers sont utilisés au niveau juste au\-dessus du sous\-arbre délégué dans le but de distribuer les ressources dans le sous\-arbre, et le délégant ne doit pas avoir la permission de modifier les ressources qui sont distribuées dans le sous\-arbre délégué. .P Consultez aussi l’explication dans le fichier \fI/sys/kernel/cgroup/delegate\fP dans NOTES pour des informations sur les autres fichiers délégables dans cgroups version 2. .P .\" Après que les étapes précitées aient été réalisées, le délégué peut créer des cgroups enfants dans le sous\-arbre délégué (les sous\-répertoires et les fichiers de cgroup qu’ils contiennent seront la propriété du délégué) et déplacer des processus entre des cgroups dans le sous\-arbre. Si quelques contrôleurs sont présents dans \fIdlgt_grp/cgroup.subtree_control\fP, ou si la propriété de ce fichier a été transférée au délégué, celui\-ci peut aussi contrôler une prochaine redistribution des ressources correspondantes dans le sous\-arbre délégué. .SS "Délégation de cgroups version 2 : nsdelegate et espace de noms cgroup" .\" commit 5136f6365ce3eace5a926e10f16ed2a233db5ba9 Depuis Linux 4.13, une seconde manière existe pour réaliser une délégation de cgroup dans une hiérarchie de cgroups version 2. Cela est fait en montant ou remontant le système de fichiers de cgroups version 2 avec l’option de montage \fInsdelegate\fP. Par exemple, si un système de fichiers de cgroups version 2 a déjà été monté, il est possible de le remonter avec l’option \fInsdelegate\fP comme suit : .P .in +4n .EX mount \-t cgroup2 \-o remount,nsdelegate \e none /sys/fs/cgroup/unified .EE .in .\" .\" Alternatively, we could boot the kernel with the options: .\" .\" cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller .\" .\" The effect of the latter option is to prevent systemd from employing .\" its "hybrid" cgroup mode, where it tries to make use of cgroups v2. .P L’effet de cette option de montage est que l’espace de noms cgroup deviennent automatiquement les limites de délégation. Plus particulièrement, les restrictions suivantes s’appliquent pour les processus à l’intérieur de l’espace de noms cgroup : .IP \- 3 Inscrire les fichiers des interfaces de contrôleur dans le répertoire racine de l’espace de noms échouera avec l’erreur \fBEPERM\fP. Les processus à l’intérieur de l’espace de noms cgroup peuvent toujours écrire dans les fichiers délégables dans le répertoire racine de l’espace de noms cgroup tels que \fIcgroup.procs\fP et \fIcgroup.subtree_control\fP, et peuvent créer des sous\-hiérarchies au\-dessous du répertoire racine. .IP \- Les essais de migrer des processus à travers des limites d’espace de noms sont interdits (avec l’erreur \fBENOENT\fP). Les processus à l’intérieur d’un espace de noms cgroup peuvent toujours (soumis aux règles de confinement décrites ci\-après) déplacer des processus entre cgroups \fIà l’intérieur\fP de la sous\-hiérarchie sous l’espace de noms racine. .P La possibilité de définir des espaces de noms cgroup comme des limites de délégation rend les espaces de noms cgroup beaucoup plus utiles. Pour en comprendre la raison, supposons qu’il existe déjà une hiérarchie de cgroup qui a été déléguée à un utilisateur non privilégié, \fIcecilia\fP, en utilisant la technique ancienne de délégation décrite ci\-dessus. Supposons que plus tard \fIcecilia\fP veuille déléguer une sous\-hiérarchie sous la hiérarchie déléguée existante (par exemple, la hiérarchie déléguée peut être associée avec un conteneur non privilégié exécuté par \fIcecilia\fP). Même si un espace de noms cgroup était employé, parce que les deux hiérarchies sont la propriété de l’utilisateur \fIcecilia\fP non privilégié, les actions illégitimes suivantes pourraient être réalisées : .IP \- 3 Un processus dans la hiérarchie inférieure pourrait modifier les réglages du contrôleur de ressources dans le répertoire racine de cette hiérarchie (ces réglages sont conçus pour permettre le contrôle à exercer à partir du cgroup \fIparent\fP ; un processus dans le cgroup enfant ne devrait pas pouvoir les modifier) ; .IP \- un processus à l’intérieur de hiérarchie subalterne pourrait déplacer des processus dans ou en dehors de la hiérarchie inférieure si les cgroups dans la hiérarchie supérieure étaient de quelque façon visibles. .P L’utilisation de l’option de montage \fInsdelegate\fP empêche les deux possibilités. .P L’option de montage \fInsdelegate\fP a seulement un effet lorsque elle est utilisée dans l’espace de noms initial montage, dans d’autres espaces de noms montage cette option est ignorée silencieusement. .P \fIRemarque\fP : sur certains systèmes, \fBsystemd\fP(1) monte automatiquement le système de fichiers de cgroup version 2. Dans le but de tester l’opération \fInsdelegate\fP, il peut être utile d’amorcer le noyau avec les options de ligne de commande suivantes : .P .in +4n .EX cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller .EE .in .P .\" Ces options font que le noyau amorce avec les contrôleurs cgroups version 1 désactivés (signifiant que les contrôleurs sont disponibles dans une hiérarchie version 2) et indique à \fBsystemd\fP(1) de ne pas monter et utiliser la hiérarchie de cgroup version 2, de façon que la hiérarchie version 2 puisse être montée manuellement avec les options désirées après l’amorçage. .SS "Règles de confinement de délégation de cgroup" Certaines \fIrègles de confinement\fP de délégation assurent que le délégué peut déplacer des processus entre des cgroups à l’intérieur du sous\-arbre délégué, mais ne puisse pas déplacer les processus de l’extérieur du sous\-arbre délégué dans le sous\-arbre ou vice versa. Un processus non privilégié (c’est\-à\-dire le délégué) peut écrire le PID d’un processus « cible » dans un fichier \fIcgroup.procs\fP seulement si toutes les conditions suivantes sont remplies : .IP \- 3 l’écrivain a la permission d’écriture dans le fichier \fIcgroup.procs\fP du cgroup de destination ; .IP \- l’écrivain a la permission d’écrire dans le fichier \fIcgroup.procs\fP dans le plus proche ancêtre commun des cgroups source et de destination. Remarquez que dans certains cas, ce plus proche ancêtre commun peut être le cgroup source ou celui de destination eux\-mêmes. Ce besoin n’est pas imposé pour les hiérarchies version 1, avec pour conséquence que le confinement dans la version 1 est moins strict que dans la version 2 (par exemple, dans cgroups version 1 l’utilisateur possédant deux sous\-hiérarchies déléguées distinctes peut déplacer un processus entre les hiérarchies) ; .IP \- si le système de fichiers d’un cgroup version 2 a été monté avec l’option \fInsdelegate\fP, l’écrivain doit être capable de voir les cgroups source et destination à partir de son espace de noms cgroup ; .IP \- .\" commit 576dd464505fc53d501bb94569db76f220104d28 Dans cgroups version 1, l’UID effectif de l’écrivain (c’est\-à\-dire le délégué) correspond à l’ID réel utilisateur ou au set\-user\-ID enregistré du processus cible. Avant Linux 4.11, cette exigence s’appliquait aussi dans cgroups version 2 (c’était une exigence historique héritée de cgroups version 1 qui a été plus tard estimée non nécessaire, puisque les autres règles suffisent pour le confinement dans cgroups version 2). .P .\" \fIRemarque\fP : une conséquence des ces règles de confinement de délégation est que le délégué non privilégié ne peut placer le premier processus dans le sous\-arbre délégué. À la place, le délégant doit placer le premier processus (un processus possédé par le délégué) dans le sous\-arbre délégué. .SH "MODE THREAD DE CGROUPS VERSION 2" Parmi les restrictions imposées par cgroups version 2 qui n’étaient pas présentes dans cgroups version 1 : .IP \- 3 \fIpas contrôle de granularité au niveau thread\fP : tous les threads d’un processus doivent être dans le même cgroup ; .IP \- \fIpas de processus internes\fP : un cgroup ne peut à la fois avoir des processus membres et mettre en œuvre des contrôleurs sur des cgroups enfants. .P Ces deux restrictions ont été ajoutées parce que l’absence de ces restrictions a causé des problèmes dans cgroups version 1. En particulier, la possibilité de cgroups version 1 de permettre une granularité au niveau threads pour l’appartenance à un cgroup n’avait aucun sens pour certains contrôleurs. Un exemple notable était le contrôleur \fImemory\fP : puisque les threads partagent un espace d’adressage, cela n’avait aucun sens de répartir les threads à travers des cgroups \fImemory\fP différents. .P Malgré le fait de la décision initiale de conception de cgroups version 2, des cas d’utilisation existaient pour certains contrôleurs, notablement le contrôleur \fIcpu\fP, pour lesquels la granularité au niveau thread du contrôle était justifiée et utile. Pour tenir compte de tels cas, Linux 4.14 a ajouté le \fImode thread\fP pour cgroups version 2. .P Le mode thread permet les choses suivantes : .IP \- 3 la création de \fIsous\-arbres threaded\fP dans lesquels les threads d’un processus peuvent être répartis à travers des cgroups à l’intérieur de l’arbre (un sous\-arbre threaded peut contenir plusieurs processus multithreads) ; .IP \- le concept de \fIcontrôleurs threaded\fP qui peuvent distribuer des ressources à travers les cgroups dans un sous\-arbre threaded ; .IP \- un relâchement de la règle « pas de processus internes », de façon à ce que, à l’intérieur d’un sous\-arbre threaded, un cgroup puisse à la fois avoir des processus membres et mettre en œuvre des contrôleurs de ressources de cgroups enfants. .P Avec l’ajout du mode thread, chaque cgroup non racine contient désormais un nouveau fichier, \fIcgroup.type\fP, qui expose, et dans certaines circonstances qui peut être utilisé pour modifier, le « type » d’un cgroup. Ce fichier contient une des valeurs de type suivantes : .TP \fIdomain\fP C’est un cgroup version 2 normal fournissant un contrôle de niveau de granularité processus. Si un processus est membre de ce cgroup, alors tous les threads de ce processus sont (par définition) dans le même cgroup. C’est le type par défaut de cgroup et il fournit le même comportement qui était fourni pour les cgroups dans l’implémentation initiale de cgroups version 2. .TP \fIthreaded\fP Ce cgroup est un membre d’un sous\-arbre threaded. Des threads peuvent être ajoutés à ce cgroup et des contrôleurs peuvent être activés pour le cgroup. .TP \fIdomain threaded\fP C’est un cgroup domain qui sert de racine à un sous\-arbre threaded. Ce type de cgroup est aussi connu comme « threaded root ». .TP \fIdomain invalid\fP C’est un cgroup à l’intérieur d’un sous\-arbre threaded qui est dans un état « invalid ». Un processus ne peut être ajouté au cgroup et un contrôleur ne peut être activé pour le cgroup. La seule chose qui puisse être faite avec ce cgroup (à part le supprimer) est de le convertir en cgroup \fIthreaded\fP en inscrivant la chaine \fI« threaded »\fP dans le fichier \fIcgroup.type\fP. .IP .\" La raison de l’existence de ce type « transitoire » lors de la création d’un sous\-arbre threaded (plutôt que le noyau ne convertisse simplement immédiatement tous les cgroups sous la racine threaded au type \fIthreaded\fP) est de permettre des extensions futures au modèle de mode thread. .SS "Threaded versus contrôleurs de domaine" Avec l’ajout du mode threads, cgroups version 2 distingue désormais deux types de contrôleurs de ressource : .IP \- 3 .\" In the kernel source, look for ".threaded[ \t]*= true" in .\" initializations of struct cgroup_subsys contrôleurs \fIThreaded\fP : ces contrôleurs gèrent la granularité au niveau thread pour le contrôle des ressources et peuvent être activés à l’intérieur de sous\-arbres threaded avec pour résultat que les fichiers de l’interface de contrôleur correspondants apparaissent dans les cgroups du sous\-arbre threaded. Depuis Linux 4.19, les contrôleurs suivants sont threaded : \fIcpu\fP, \fIperf_event\fP, et \fIpids\fP ; .IP \- .\" contrôleurs \fIDomain\fP : ces contrôleurs gèrent seulement une granularité au niveau processus pour le contrôle de ressource. Du point de vue contrôleur de domaine, tous les threads d’un processus sont toujours dans le même cgroup. Les contrôleurs de domaine ne peuvent être activés à l’intérieur d’un sous\-arbre threaded. .SS "Création d’un sous\-arbre threaded" Il existe deux manières qui conduisent à la création de sous\-arbre threaded. La première manière fonctionne comme ceci : .IP (1) 5 Nous écrivons La chaine \fI« threaded »\fP dans le fichier \fIcgroup.type\fP d’un cgroup \fIy/z\fP ayant actuellement le type \fIdomain\fP. Cela a les effets suivants : .RS .IP \- 3 le type du cgroup \fIy/z\fP devient \fIthreaded\fP ; .IP \- le type du cgroup parent, \fIy\fP, devient \fIdomain threaded\fP. Le cgroup parent est la racine d’un sous\-arbre threaded (aussi connu comme « threaded root » – racine threaded) ; .IP \- Tous les autres cgroups sous \fIy\fP qui n’étaient pas déjà de type \fIthreaded\fP (parce qu’ils étaient déjà dans des sous\-arbres threaded existants sous la nouvelle racine root threaded) sont convertis au type \fIdomain invalid\fP. Tout cgroup créé après sous \fIy\fP aura aussi le type \fIdomain invalid\fP. .RE .IP (2) Nous écrivons La chaine \fI« threaded »\fP pour chacun des cgroups \fIdomain invalid\fP sous \fIy\fP, dans le but de les convertir au type \fIthreaded\fP. Comme conséquence de cette étape, tous les threads sous la racine threaded ont désormais le type \fIthreaded\fP et le sous\-arbre threaded est désormais pleinement utilisable. Les conditions nécessaires pour écrire \fI« threaded »\fP pour chacun de ces cgroups sont quelque peu laborieuses, mais permettent de futures extensions au modèle de mode thread. .P La second manière de créer un sous\-arbre threaded est la suivante : .IP (1) 5 Dans un cgroup existant, \fIz\fP, qui actuellement a le type \fIdomain\fP, nous (1.1) activons un ou plusieurs contrôleurs threaded et (1.2) faisons d’un processus un membre de \fIz\fP (ces deux étapes pouvant être réalisées dans n’importe quel ordre). Cela a les conséquences suivantes : .RS .IP \- 3 le type de \fIz\fP devient \fIdomain threaded\fP ; .IP \- tous les cgroups descendants de \fIz\fP qui n’étaient déjà de type \fIthreaded\fP sont convertis au type \fIdomain invalid\fP. .RE .IP (2) Comme auparavant, nous rendons le sous\-arbre threaded utilisable en écrivant la chaine \fI« threaded »\fP pour chacun des cgroups \fIdomain invalid\fP sous \fIz\fP, dans le but de les convertir au type \fIthreaded\fP. .P .\" Une des conséquences des manières ci\-dessus de créer un sous\-arbre threaded est qu’un cgroup de racine threaded peut être un parent pour seulement des cgroups \fIthreaded\fP (et \fIdomain invalid\fP). Le cgroup racine threaded ne peut pas être un parent d’un cgroup \fIdomain\fP et un cgroup \fIthreaded\fP ne peut avoir de frère qui soit un cgroup \fIdomain\fP. .SS "Utilisation de sous\-arbre threaded" À l’intérieur d’un sous\-arbre threaded, des contrôleurs threaded peuvent être activés dans chaque sous\-groupe dont le type a été changé à \fIthreaded\fP. Ce faisant, les fichiers de l’interface de contrôleur correspondants apparaissent dans l’enfant de ce cgroup. .P Un processus peut être déplacé dans un sous\-arbre threaded en écrivant son PID dans le fichier \fIcgroup.procs\fP dans un des cgroups de l’arbre. Cela a pour effet de rendre tous les threads du processus membres du cgroup correspondant et de faire du processus un membre du sous\-arbre threaded. Les threads du processus peuvent être répartis à travers le sous\-arbre threaded en écrivant leurs ID de thread (voir \fBgettid\fP(2)) dans les fichiers \fIcgroup.threads\fP dans différents cgroups à l’intérieur du sous\-arbre. Les threads d’un processus doivent tous résider dans le même sous\-arbre threaded. .P Comme pour l’écriture dans \fIcgroup.procs\fP, quelques règles de confinement s’appliquent pour l’écriture dans le fichier \fIcgroup.threads\fP : .IP \- 3 l’écrivain doit avoir la permission d’écriture dans le fichier \fIcgroup.threads\fP dans le cgroup de destination ; .IP \- l’écrivain doit avoir la permission d’écriture dans le fichier \fIcgroup.procs\fP dans l’ancêtre commun des cgroups source et destination (dans certains cas, cet ancêtre peut être le cgroup source ou destination eux\-mêmes) ; .IP \- les cgroups source et destination doivent être dans le même sous\-arbre threaded (en dehors d’un sous\-arbre threaded, un essai de déplacer un thread en écrivant son ID de thread dans le fichier \fIcgroup.threads\fP dans un cgroup \fIdomain\fP différent échoue avec l’erreur \fBEOPNOTSUPP\fP). .P Le fichier \fIcgroup.threads\fP est présent dans chaque cgroup (incluant les cgroups \fIdomain\fP) et peut être lu pour découvrir l’ensemble de threads présents dans le cgroup. L’ensemble d’ID de threads obtenu lors de la lecture de ce fichier n’est pas garanti d’être ordonné ou ne pas avoir de doublons. .P Le fichier \fIcgroup.procs\fP dans la racine threaded affiche le PID de tous les processus membres du sous\-arbre threaded. Les fichiers \fIcgroup.procs\fP dans les autres cgroups du sous\-arbre ne sont pas lisibles. .P Les contrôleurs de domaine ne peuvent être activés dans un sous\-arbre threaded. Aucun fichier d’interface de contrôleur n’apparait dans les cgroups sous la racine threaded. Du point de vue du contrôleur de domaine, les sous\-arbres threaded sont invisibles : un processus multithreaded à l’intérieur d’un sous\-arbre threaded apparait pour un contrôleur de domaine comme un processus qui réside dans le cgroup racine threaded. .P .\" Dans un sous\-arbre threaded, la règle « pas de processus internes » ne s’applique pas : un cgroup peut contenir des processus membres (ou des threads) et utiliser des contrôleurs sur des cgroups enfants. .SS "Règles pour écrire dans cgroup.type et créer des sous\-arbres threaded" Un certain nombre de règles s’appliquent lors de l’écriture dans le fichier \fIcgroup.type\fP : .IP \- 3 seule la chaine \fI« threaded »\fP peut être écrite. En d’autres mots, la seule transition explicite possible est de convertir un cgroup \fIdomain\fP au type \fIthreaded\fP ; .IP \- l’effet d’écrire \fI« threaded »\fP dépend de la valeur en cours dans \fIcgroup.type\fP, comme suit : .RS .IP \- 3 \fIdomain\fP ou \fIdomain threaded\fP : début de la création d’un sous\-arbre threaded (dont la racine est le parent de ce cgroup) à l’aide de la première des manières décrites ci\-dessus, .IP \- \fIdomain\ invalid\fP : conversion de ce cgroup (qui est à l’intérieur d’un sous\-arbre threaded) pour être dans un état utilisable (c’est\-à\-dire \fIthreaded\fP), .IP \- \fIthreaded\fP : aucun effet (une « no\-op ») ; .RE .IP \- il n’est pas possible d’écrire dans un fichier \fIcgroup.type\fP si le type du parent est \fIdomain invalid\fP. En d’autres mots, les cgroups d’un sous\-arbre threaded doivent être convertis dans l’état \fIthreaded\fP d’une manière descendante. .P Quelques contraintes doivent aussi être satisfaites pour créer un sous\-arbre threaded dont la racine est le cgroup \fIx\fP : .IP \- 3 il ne peut exister de processus membres dans les cgroups descendants de \fIx\fP (le cgroup_\fIx\fP peut lui avoir des processus membres) ; .IP \- aucun contrôleur de domaine ne peut être activé dans le fichier \fIcgroup.subtree_control\fP de \fIx\fP. .P .\" Si n’importe laquelle des contraintes ci\-dessus n’est pas satisfaite, alors un essai d’écrire \fI« threaded »\fP dans un fichier \fIcgroup.type\fP échouera avec l’erreur \fBENOTSUP\fP. .SS "Le type « domain threaded » de cgroup" Selon les chemins décrits ci\-dessus, le type d’un cgroup peut changer à \fIdomain threaded\fP dans chacun des cas suivants : .IP \- 3 la chaine \fI« threaded »\fP est écrite pour un cgroup enfant ; .IP \- un contrôleur threaded est activé dans le cgroup et un processus est fait membre du cgroup. .P Un cgroup \fIdomain threaded\fP, \fIx\fP, peut redevenir du type \fIdomain\fP si les conditions ci\-dessus ne sont plus vraies, c’est\-à\-dire si tous les cgroups enfants \fIthreaded\fP de \fIx\fP ont été supprimés et si \fIx\fP n’a plus de contrôleurs threaded activés ou n’a plus de processus membres. .P Quand un cgroup \fIdomain threaded\fP \fIx\fP redevient du type \fIdomain\fP : .IP \- 3 tous les descendants \fIdomain invalid\fP de \fIx\fP qui ne sont pas dans des sous\-arbres threaded de bas niveau redeviennent du type \fIdomain\fP ; .IP \- .\" les cgroups racines dans n’importe quels sous\-arbres threaded de bas niveau redeviennent de type \fIdomain threaded\fP. .SS "Exceptions pour le cgroup racine" Le cgroup racine de la hiérarchie version 2 est traité exceptionnellement : il peut être le parent à la fois de cgroups \fIdomain\fP et \fIthreaded\fP. Si la chaine \fI« threaded »\fP est écrite dans le fichier \fIcgroup.type\fP d’un des enfants du cgroup racine, alors : .IP \- 3 le type de ce cgroup devient \fIthreaded\fP ; .IP \- le type de tous les descendants de ce cgroup qui ne fait pas partie de sous\-arbres threaded de bas niveau change à \fIdomain invalid\fP. .P Remarquez que dans ce cas, il n’y a pas de cgroup qui deviennent \fIdomain threaded\fP (théoriquement, le cgroup racine peut être considéré comme la racine threaded pour le cgroup dont le type a été changé à \fIthreaded\fP). .P .\" Le but de ce traitement exceptionnel pour le cgroup racine est de permettre à un cgroup threaded qui emploie le contrôleur \fIcpu\fP d’être placé aussi haut que possible dans la hiérarchie, de façon à minimiser le (faible) coût de parcourir la hiérarchie de cgroup. .SS "Le contrôleur « cpu » de cgroups version 2 et les threads en temps réel" Depuis Linux 4.19, le contrôleur \fIcpu\fP de cgroups version 2 ne prend pas en charge le contrôle des threads en temps réel (particulièrement les threads ordonnancés sous les politiques \fBSCHED_FIFO\fP, \fBSCHED_RR\fP, \fBSCHED_DEADLINE\fP ; voir \fBsched\fP(7)). Par conséquent, le contrôleur \fIcpu\fP ne peut être activé dans le cgroup racine seulement si tous les threads en temps réel sont dans le cgroup racine (si des threads en temps réel sont dans des cgroups non racines, alors une écriture \fBwrite\fP(2) de la chaine \fI« +cpu »\fP dans le fichier \fIcgroup.subtree_control\fP échoue avec l’erreur \fBEINVAL\fP). .P .\" Dans certains systèmes, \fBsystemd\fP(1) place certains threads en temps réel dans des cgroups non racines dans la hiérarchie version 2. Pour de tels systèmes, ces threads doivent d’abord être déplacés dans le cgroup racine avant que le contrôleur \fIcpu\fP ne soit activé. .SH ERREURS Les erreurs suivantes peuvent survenir pour \fBmount\fP(2) : .TP \fBEBUSY\fP Un essai de monter un système de fichiers cgroup version 1 n’indiquait ni l’option \fIname=\fP (pour monter une hiérarchie nommée) ni un nom de contrôleur (ou \fIall\fP). .SH NOTES Un processus enfant créé à l’aide de \fBfork\fP(2) hérite des appartenances de cgroup de son parent. Les appartenances de cgroup de processus sont préservées à travers \fBexecve\fP(2). .P .\" Le drapeau \fBCLONE_INTO_CGROUP\fP de \fBclone3\fP(2) peut être utilisé pour créer un processus enfant qui débute son existence dans un cgroup version 2 différent du processus parent. .SS "Fichiers /proc" .TP \fI/proc/cgroups\fP (depuis Linux 2.6.24) Ce fichier contient des informations sur les contrôleurs qui sont compilés dans le noyau. Un exemple du contenu de ce fichier (reformaté pour une meilleure lisibilité) est ce qui suit : .IP .in +4n .EX #subsys_name hierarchy num_cgroups enabled cpuset 4 1 1 cpu 8 1 1 cpuacct 8 1 1 blkio 6 1 1 memory 3 1 1 devices 10 84 1 freezer 7 1 1 net_cls 9 1 1 perf_event 5 1 1 net_prio 9 1 1 hugetlb 0 1 0 pids 2 1 1 .EE .in .IP Les champs dans ce fichier sont de gauche à droite : .RS .IP [1] 5 Le nom du contrôleur. .IP [2] L’ID unique de la hiérarchie de cgroup pour laquelle le contrôleur est monté. Si plusieurs contrôleurs de cgroups version 1 sont liés à la même hiérarchie, chacun d'entre eux affichera le même ID de hiérarchie dans ce champ. La valeur dans ce champ sera zéro si : .RS .IP \- 3 le contrôleur n’est pas monté pour une hiérarchie de cgroups version 1 ; .IP \- le contrôleur est lié à la seule hiérarchie unifiée de cgroups version 2 ; .IP \- le contrôleur est désactivé (voir ci\-dessous). .RE .IP [3] Le nombre de groupes de contrôle dans cette hiérarchie utilisant ce contrôleur. .IP [4] Ce champ contient la valeur 1 si le contrôleur est activé ou zéro s’il a été désactivé (à l’aide du paramètre \fIcgroup_disable\fP d’amorçage du noyau dans la ligne de commande). .RE .TP \fI/proc/\fPpid\fI/cgroup\fP (depuis Linux 2.6.24) Ce fichier décrit les groupes de contrôle auxquels le processus ayant le PID correspondant appartient. L’information affichée diffère pour les hiérarchies version 1 et version 2 de cgroups. .IP Pour chaque hiérarchie de cgroup dont le processus est membre, il existe une entrée contenant trois champs séparés par des deux\-points : .IP .in +4n .EX ID_hiérarchie:liste_contrôleurs:chemin_cgroup .EE .in .IP Par exemple : .IP .in +4n .EX 5:cpuacct,cpu,cpuset:/daemons .EE .in .IP De gauche à droite, ces trois champs séparés par des deux\-points sont : .RS .IP [1] 5 Pour les hiérarchies de cgroups version 1, ce champ contient un numéro d’ID unique de hiérarchie qui peut être comparé avec un ID de hiérarchie dans \fI/proc/cgroups\fP. Pour les hiérarchies de cgroups version 2, ce champ contient la valeur 0. .IP [2] Pour les hiérarchies de cgroups version 1, ce champ contient une liste séparée par des virgules de contrôleurs liés à la hiérarchie. Pour les hiérarchies de cgroups version 2, ce champ est vide. .IP [3] Ce champ contient le chemin du groupe de contrôle dans la hiérarchie à laquelle le processus appartient. Ce chemin est relatif au point de montage de la hiérarchie. .RE .\" .SS "Fichiers /sys/kernel/cgroup" .TP \fI/sys/kernel/cgroup/delegate\fP (depuis Linux 4.15) .\" commit 01ee6cfb1483fe57c9cbd8e73817dfbf9bacffd3 Ce fichier exporte une liste de fichiers cgroups version 2 (un par ligne) qui sont délégables (c’est\-à\-dire dont la propriété peut être changée à l’ID utilisateur du délégué). Dans le futur, l’ensemble des fichiers délégables peut être modifié ou grossir, et ce fichier fournit un moyen pour le noyau d’informer les applications en espace utilisateur quels fichiers doivent être délégués. Depuis Linux 4.15, il est possible de voir ce qui suit lors de l’inspection de ce fichier : .IP .in +4n .EX $ \fBcat /sys/kernel/cgroup/delegate\fP cgroup.procs cgroup.subtree_control cgroup.threads .EE .in .TP \fI/sys/kernel/cgroup/features\fP (depuis Linux 4.15) .\" commit 5f2e673405b742be64e7c3604ed4ed3ac14f35ce Avec le temps, l’ensemble de fonctionnalités de cgroups version 2 fournies par le noyau peut évoluer ou grossir, ou certaines fonctionnalités pourraient ne pas être activées par défaut. Ce fichier fournit un moyen aux applications en espace utilisateur de découvrir quelles fonctionnalités le noyau utilisé gère et a d’activées. Les fonctionnalités sont listées, une par ligne : .IP .in +4n .EX $ \fBcat /sys/kernel/cgroup/features\fP nsdelegate memory_localevents .EE .in .IP Les entrées pouvant apparaitre dans ce fichier sont : .RS .TP \fImemory_localevents\fP (depuis Linux 5.2) Le noyau gère l’option de montage \fImemory_localevents\fP. .TP \fInsdelegate\fP (depuis Linux 4.15) Le noyau gère l’option de montage \fInsdelegate\fP. .TP \fImemory_recursiveprot\fP (depuis Linux 5.7) .\" commit 8a931f801340c2be10552c7b5622d5f4852f3a36 Le noyau gère l’option de montage \fImemory_recursiveprot\fP. .RE .SH "VOIR AUSSI" \fBprlimit\fP(1), \fBsystemd\fP(1), \fBsystemd\-cgls\fP(1), \fBsystemd\-cgtop\fP(1), \fBclone\fP(2), \fBioprio_set\fP(2), \fBperf_event_open\fP(2), \fBsetrlimit\fP(2), \fBcgroup_namespaces\fP(7), \fBcpuset\fP(7), \fBnamespaces\fP(7), \fBsched\fP(7), \fBuser_namespaces\fP(7) .P Le fichier des sources du noyau \fIDocumentation/admin\-guide/cgroup\-v2.rst\fP. .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot et Jean-Paul Guillonneau . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .