URL: https://linuxfr.org/news/systemd-pour-les-administrateurs-partie-1-et-2 Title: systemd pour les administrateurs, partie 1 et 2 Authors: ariasuni esdeem, Davy Defaud, Sébastien Koechlin, BAud, palm123, j, Benoît Sibaud, Nÿco et tuiu pol Date: 2014年06月06日T00:14:27+02:00 License: CC By-SA Tags: systemd, mageia, debian, lennart_poettering, systemd_pour_les_admins, administration_système et opensuse Score: 85 On vous parle depuis longtemps de _[[systemd]]_. On vous dit que c’est très bien. La plupart des distributions l’ont adopté (Fedora, openSUSE, Mageia, Frugalware, Arch, etc.), vont l’adopter (Debian, Ubuntu) ou vous permettent de l’utiliser de manière optionnelle (Gentoo, etc.). Mais, savez‐vous l’utiliser ? Voici une série d’articles didactiques pour apprendre à utiliser _systemd_ et vous permettre de mieux l’appréhender et de comprendre les avantages qu’il apporte par rapport aux systèmes précédents. Les informations ci‐dessous sont tirées, traduites et adaptées du _blog_ de [[Lennart Poettering]] et sont accessibles dans la langue de Shakespeare aux adresses ci‐dessous : ---- [systemd for Administrators, Part 1](http://0pointer.de/blog/projects/systemd-for-admins-1.html) [systemd for Administrators, Part 2](http://0pointer.de/blog/projects/systemd-for-admins-2.html) ---- # Partie 1 : vérifier le démarrage Comme vous le savez, _systemd_ est le mécanisme d’initialisation de nombreuses distributions. Il est également en cours d’adoption par de nombreuses autres distributions (comme Debian et Ubuntu). _systemd_ fournit une variété de nouvelles fonctionnalités, modifie et facilite les processus d’administration du système. Cet article est le premier d’une série — dans chacun d’eux, j’essaierai d’expliquer une nouvelle fonctionnalité de _systemd_. Ces fonctionnalités sont souvent simples. Ces articles devraient donc intéresser un large public. Cependant, de temps en temps, nous plongerons plus en détail dans les nouveautés géniales que _systemd_ apporte. Traditionnellement, lorsque l’on démarre un système Linux, on voit une liste de petits messages défiler à l’écran. Comme nous travaillons à accélérer et paralléliser le processus de démarrage, ces messages défilent de plus en plus vite et sont de moins en moins lisibles — sans compter que les machines deviennent de plus en plus rapides et que les systèmes de démarrage graphique comme [[Plymouth]] masquent carrément ces informations. Malgré tout, les informations de démarrage restent toujours très utiles parce qu’elles vous montrent, pour chaque service, s’il a réussi à démarrer correctement ou non (à l’aide des indicateurs `[ OK ]` verts et `[ FAILED ]` rouges). Pour rendre cette information plus accessible, nous avons rajouté une fonctionnalité à _systemd_ qui surveille et enregistre pour chaque service s’il a démarré correctement, s’il s’est terminé avec un code de sortie différent de zéro ou s’il s’est terminé de façon anormale (par erreur de segmentation ou similaire). Et ceci, non seulement au démarrage, mais aussi s’il a un problème par la suite. En tapant simplement `systemctl` dans votre terminal, vous pouvez interroger l’état de tous les services, tant _systemd_ que [SysV](https://fr.wikipedia.org/wiki/Syst%C3%A8me_V "UNIX System V")/[LSB](https://fr.wikipedia.org/wiki/Linux_Standard_Base "Linux Standard Base") : ``` [root@lambda] ~# systemctl UNIT LOAD ACTIVE SUB JOB DESCRIPTION [...] netfs.service loaded active exited LSB: Mount and unmount network filesystems. NetworkManager.service loaded active running Network Manager ntpd.service loaded maintenance maintenance Network Time Service polkitd.service loaded active running Policy Manager prefdm.service loaded active running Display Manager [...] LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. JOB = Pending job for the unit. 221 units listed. Pass --all to see inactive units, too. [root@lambda] ~# ``` _J’ai un peu raccourci la sortie ci‐dessus et supprimé quelques lignes sans intérêt pour cet article._ Regardez la colonne _ACTIVE_. Elle vous montre l’état général d’un service (ou de n’importe quelle sorte d’unité que _systemd_ maintient, qui peut être plus qu’un service — mais nous y jetterons un œil lors d’un futur article). Il est soit actif (en cours d’exécution), soit inactif (arrêté), soit dans n’importe quel autre état. Si vous regardez attentivement, vous remarquerez un élément dans la liste étiqueté « maintenance » en rouge (NdT : malheureusement, pas de couleur sur _LinuxFr.org_ !). Ce signalement vous informe qu’un service n’a pu s’exécuter ou a rencontré un problème. Dans le cas présent, il s’agit de [`ntpd`](https://fr.wikipedia.org/wiki/Ntpd "Network Time Protocol"). Regardons maintenant ce qu’il s’est passé avec `ntpd` grâce la commande `systemctl status` : ``` [root@lambda] ~# systemctl status ntpd.service ntpd.service - Network Time Service Loaded: loaded (/etc/systemd/system/ntpd.service) Active: maintenance Main PID: 953 (code=exited, status=255) CGroup: name=systemd:/systemd-1/ntpd.service [root@lambda] ~# ``` La sortie nous montre que le service NTP s’est terminé brutalement (il avait alors l’identifiant de processus 953) et nous donne la condition d’erreur exacte : le processus s’est terminé avec le code de sortie 255. Dans une prochaine version de _systemd_, nous avons l’intention de le relier à [ABRT](https://fedoraproject.org/wiki/Features/ABRT "Automated Bug-Reporting Tool"), dès que cette demande d’amélioration aura été honorée. Alors, lorsque `systemctl status` vous affichera les informations concernant un service qui aura planté, il vous redirigera directement sur la vidange de plantage (_crash dump_) adéquate dans ABRT. **Résumé :** `systemctl` et `systemctl status` sont des remplaçants modernes et sont plus complets que les traditionnels messages d’état des services SysV au démarrage. `systemctl status` enregistre non seulement plus de détails, mais montre aussi les erreurs qui ont eu lieu après le démarrage. # Partie 2 : quels services possèdent quels processus ? Sur la plupart des systèmes GNU/Linux, le nombre de processus en fonctionnement est important. Il est de plus en plus difficile de savoir quel processus fait quoi et d’où il vient. Certains ont même plusieurs processus de travail qui surchargent la sortie de `ps` avec beaucoup de processus additionnels souvent difficiles à reconnaître. Ça se complique encore avec les démons qui lancent des processus tiers, comme Apache le fait avec les processus CGI ou [_cron_](http://fr.wikipedia.org/wiki/Cron) avec les tâches utilisateurs. Souvent, le seul demi‐remède consiste à regarder l’arbre d’héritage des processus tel qu’il est donné par `ps xaf`, mais ce n’est généralement pas fiable. Les processus orphelins sont réassignés au processus 1 et, par conséquent, toutes les informations d’héritage sont perdues. En faisant deux _forks()_ successifs, un processus peut perdre sa relation avec celui qui l’a lancé (c’est supposé être une fonctionnalité et cela repose sur le comportement traditionnel de création de démons sous UNIX). Par ailleurs, les processus peuvent à leur convenance changer leur nom grâce à `PR_SETNAME` ou en modifiant `argv[0]`, rendant ainsi leur reconnaissance plus difficile. En fait, ils peuvent ainsi jouer à cache‐cache avec l’administrateur assez aisément. Avec _systemd_, nous plaçons chaque processus engendré dans un groupe de contrôle (_cgroup_) nommé d’après le service. Les groupes de contrôle, du point de vue le plus élémentaire, sont simplement des groupes de processus qui peuvent être classés hiérarchiquement et étiquetés individuellement. Quand des processus engendrent d’autres processus, ces enfants sont automatiquement membres du _cgroup_ de leur parent. Quitter un _cgroup_ n’est pas possible pour un processus sans privilège. C’est pourquoi les _cgroups_ peuvent être utilisés pour étiqueter tous les processus d’un service efficacement et indépendamment du nombre de *forks()* ou de renommages. En allant plus loin, les _cgroups_ peuvent être utilisés pour tuer proprement un service et tous les processus qu’il a créés, sans exception. Dans le billet d’aujourd’hui, je veux vous présenter deux commandes permettant de faire le lien entre les services créés par _systemd_ et les processus. La première est la commande bien connue `ps`, qui a été mise à jour pour afficher les informations _cgroup_ à côté des autres informations. Ça ressemble à ceci : ``` $ ps xawf -eo pid,user,cgroup,args PID USER CGROUP COMMAND 2 root - [kthreadd] 3 root - \_ [ksoftirqd/0] 4281 root - \_ [flush-8:0] 1 root name=systemd:/systemd-1 /sbin/init 455 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d 8188 root name=systemd:/systemd-1/sysinit.service \_ /sbin/udevd -d 8191 root name=systemd:/systemd-1/sysinit.service \_ /sbin/udevd -d 1131 root name=systemd:/systemd-1/auditd.service auditd 1133 root name=systemd:/systemd-1/auditd.service \_ /sbin/audispd 1171 root name=systemd:/systemd-1/NetworkManager.service /usr/sbin/NetworkManager --no-daemon 4028 root name=systemd:/systemd-1/NetworkManager.service \_ /sbin/dhclient -d -4 -sf /usr/libex[...] 1193 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -c 4 1195 root name=systemd:/systemd-1/cups.service cupsd -C /etc/cups/cupsd.conf 1210 root name=systemd:/systemd-1/irqbalance.service irqbalance 1216 root name=systemd:/systemd-1/dbus.service /usr/sbin/modem-manager 1219 root name=systemd:/systemd-1/dbus.service /usr/libexec/polkit-1/polkitd 1332 root name=systemd:/systemd-1/getty@.service/tty2 /sbin/mingetty tty2 1339 root name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3 1344 root name=systemd:/systemd-1/crond.service crond 1362 root name=systemd:/systemd-1/sshd.service /usr/sbin/sshd 1376 root name=systemd:/systemd-1/prefdm.service /usr/sbin/gdm-binary -nodaemon 1391 root name=systemd:/systemd-1/prefdm.service \_ /usr/libexec/gdm-simple-slave --displa[...] 1394 root name=systemd:/systemd-1/prefdm.service \_ /usr/bin/Xorg :0 -nr -verb[...] 1495 root name=systemd:/user/lennart/1 \_ pam: gdm-password 1521 lennart name=systemd:/user/lennart/1 \_ gnome-session 1621 lennart name=systemd:/user/lennart/1 \_ metacity 1635 lennart name=systemd:/user/lennart/1 \_ gnome-panel 1638 lennart name=systemd:/user/lennart/1 \_ nautilus 1453 root name=systemd:/systemd-1/dbus.service /usr/libexec/upowerd 1473 rtkit name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon ``` _Notez que la sortie est un peu raccourcie. J’ai supprimé la plupart des tâches du noyau ici, car elles n’ont pas d’intérêt pour cet article._ Dans la troisième colonne, vous pouvez voir le _cgroup_ _systemd_ assigné à chaque processus. Vous verrez que les processus _udev_ sont rassemblés dans le _cgroup_ `name=systemd:/systemd-1/sysinit.service`. C’est le _cgroup_ utilisé pour tous les processus démarrés par le service `sysinit.service`, qui s’occupe du début du démarrage. Je recommande personnellement de créer pour la commande `ps` ci‐dessus l’alias suivant : `alias psc='ps xawf -eo pid,user,cgroup,args'` Avec ce service, les informations sur les processus ne sont plus qu’à quatre touches de distance ! L’outil `systemd-cgls` fourni avec _systemd_ est un autre moyen de présenter ces mêmes informations. Il affiche la hiérarchie des _cgroups_ sous forme d’arbre. Sa sortie ressemble à ceci : ``` $ systemd-cgls + 2 [kthreadd] [...] + 4281 [flush-8:0] + user | \ lennart | \ 1 | + 1495 pam: gdm-password | + 1521 gnome-session | + 1621 metacity | + 1635 gnome-panel | + 1638 nautilus | \ 29519 systemd-cgls \ systemd-1 + 1 /sbin/init + rtkit-daemon.service | \ 1473 /usr/libexec/rtkit-daemon + prefdm.service | + 1376 /usr/sbin/gdm-binary -nodaemon | + 1391 /usr/libexec/gdm-simple-slave --disp[...] | \ 1394 /usr/bin/Xorg :0 -nr -verbose -auth [...] + getty@.service | + tty3 | | \ 1339 /sbin/mingetty tty3 | \ tty2 | \ 1332 /sbin/mingetty tty2 + crond.service | \ 1344 crond + sshd.service | \ 1362 /usr/sbin/sshd + irqbalance.service | \ 1210 irqbalance + NetworkManager.service | + 1171 /usr/sbin/NetworkManager --no-daemon | \ 4028 /sbin/dhclient -d -4 -sf /usr/libexe[...] + rsyslog.service | \ 1193 /sbin/rsyslogd -c 4 + cups.service | \ 1195 cupsd -C /etc/cups/cupsd.conf + auditd.service | + 1131 auditd | \ 1133 /sbin/audispd | \ 1135 /usr/sbin/sedispatch \ dbus.service + 1216 /usr/sbin/modem-manager \ 1219 /usr/libexec/polkit-1/polkitd ``` _Cette sortie est également raccourcie._ Comme vous pouvez le constater, cette commande montre les processus par leur _cgroup_ et ainsi leur service, car _systemd_ nomme les _cgroups_ d’après les services. Par exemple, vous pouvez facilement voir que le service d’audit _auditd.service_ lance trois processus indépendants, _auditd_, _audisp_ et _sedispatch_. Si vous y regardez de plus près, vous remarquerez que plusieurs processus ont été assignés au _cgroups_ `/user/1`. Pour le moment, restons en là : _systemd_ non seulement maintient des services dans les _cgroups_, mais aussi les processus de session utilisateur. Dans le prochain épisode, nous parlerons plus en détail de ce sujet. C’est tout pour aujourd’hui ! La suite au prochain épisode !

AltStyle によって変換されたページ (->オリジナル) /