Une partie du travail de l'administrateur système consiste à analyser les performances des systèmes et à rechercher et résoudre les problèmes qui entraînent de mauvaises performances et de longs temps de démarrage. Les administrateurs système doivent également vérifier d'autres aspects de la configuration et de l'utilisation de systemd.
Le système systemd init fournit le systemd-analyze outil qui peut aider à découvrir les problèmes de performances et d'autres informations systemd importantes. Dans un article précédent, Analyser le calendrier et les périodes de systemd , j'ai utilisé systemd-analyze pour analyser les horodatages et les périodes dans les minuteurs systemd, mais cet outil a de nombreuses autres utilisations, dont certaines que j'explorerai dans cet article.
Présentation du démarrage
La séquence de démarrage Linux est un bon endroit pour commencer à explorer car de nombreux systemd-analyze les fonctions de l'outil sont ciblées au démarrage. Mais d'abord, il est important de comprendre la différence entre le démarrage et le démarrage. La séquence de démarrage commence par l'autotest de mise sous tension (POST) du BIOS et se termine lorsque le noyau a fini de se charger et prend le contrôle du système hôte, ce qui est le début du démarrage et le moment où le journal systemd commence.
Dans le deuxième article de cette série, Comprendre systemd au démarrage sous Linux , j'aborde le démarrage un peu plus en détail en ce qui concerne ce qui se passe et dans quel ordre. Dans cet article, je souhaite examiner la séquence de démarrage pour examiner le temps nécessaire au démarrage et les tâches qui prennent le plus de temps.
Les résultats que je vais montrer ci-dessous proviennent de mon poste de travail principal, ce qui est beaucoup plus intéressant que les résultats d'une machine virtuelle. Cette station de travail se compose d'une carte mère ASUS TUF X299 Mark 2, d'un processeur Intel i9-7960X avec 16 cœurs et 32 processeurs (threads) et de 64 Go de RAM. Certaines des commandes ci-dessous peuvent être exécutées par un utilisateur non root, mais j'utiliserai root dans cet article pour éviter d'avoir à changer d'utilisateur.
Il existe plusieurs options pour examiner la séquence de démarrage. La forme la plus simple de systemd-analyze La commande affiche un aperçu du temps passé dans chacune des sections principales du démarrage, du démarrage du noyau, du chargement et de l'exécution de initrd (c'est-à-dire, le disque virtuel initial, une image système temporaire utilisée pour initialiser du matériel et monter le / système de fichiers [racine]) et l'espace utilisateur (où tous les programmes et démons nécessaires pour amener l'hôte à un état utilisable sont chargés). Si aucune sous-commande n'est transmise à la commande, systemd-analyze time est sous-entendu :
[root@david ~]$ systemd-analyze
Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233s
graphical.target reached after 10.071s in userspace
[root@david ~]#
La donnée la plus notable de cette sortie est le temps passé dans le firmware (BIOS) :près de 54 secondes. C'est une quantité de temps extraordinaire, et aucun de mes autres systèmes physiques ne prend autant de temps pour passer par le BIOS.
Mon ordinateur portable System76 Oryx Pro ne passe que 8,506 secondes dans le BIOS, et tous mes systèmes maison prennent un peu moins de 10 secondes. Après quelques recherches en ligne, j'ai découvert que cette carte mère est connue pour son temps de démarrage du BIOS excessivement long. Ma carte mère ne "démarre jamais". Il se bloque toujours, et je dois faire un cycle de mise hors/sous tension, puis le BIOS démarre avec une erreur, et je dois appuyer sur F1 pour entrer dans la configuration du BIOS, à partir de laquelle je peux sélectionner le lecteur de démarrage et terminer le démarrage. C'est de là que vient le temps supplémentaire.
Tous les hôtes n'affichent pas les données du micrologiciel. Mes expériences non scientifiques m'amènent à croire que ces données ne sont présentées que pour les processeurs Intel de génération 9 ou supérieure. Mais cela pourrait être incorrect.
Cet aperçu du processus de démarrage au démarrage est intéressant et fournit de bonnes informations (bien que limitées), mais il y a beaucoup plus d'informations disponibles sur le démarrage, comme je le décrirai ci-dessous.
Attribuer un blâme
Vous pouvez utiliser systemd-analyze blame pour découvrir quelles unités systemd prennent le plus de temps à s'initialiser. Les résultats sont affichés dans l'ordre du temps qu'ils mettent à s'initialiser, du plus au moins :
[root@david ~]$ systemd-analyze blame
5.417s NetworkManager-wait-online.service
3.423s dracut-initqueue.service
2.715s systemd-udev-settle.service
2.519s fstrim.service
1.275s udisks2.service
1.271s smartd.service
996ms upower.service
637ms lvm2-monitor.service
533ms lvm2-pvscan@8:17.service
520ms dmraid-activation.service
460ms vboxdrv.service
396ms initrd-switch-root.service
<SNIP – removed lots of entries with increasingly small times>
Étant donné que bon nombre de ces services démarrent en parallèle, les chiffres peuvent s'additionner considérablement plus que le total donné par systemd-analyze time pour tout après le BIOS. Ce sont tous de petits nombres, donc je ne peux pas trouver d'économies significatives ici.
Les données de cette commande peuvent fournir des indications sur les services que vous pourriez envisager pour améliorer les temps de démarrage. Les services non utilisés peuvent être désactivés. Il ne semble pas y avoir de service unique qui prenne trop de temps au cours de cette séquence de démarrage. Vous pouvez voir des résultats différents pour chaque démarrage et démarrage.
Chaînes critiques
Comme le chemin critique en gestion de projet, une chaîne critique montre la chaîne d'événements critiques dans le temps qui ont lieu pendant le démarrage. Ce sont les unités systemd que vous souhaitez examiner si le démarrage est lent, car ce sont elles qui entraîneraient des retards. Cet outil n'affiche pas toutes les unités qui démarrent, uniquement celles de cette chaîne d'événements critiques :
[root@david ~]# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @10.071s
└─lxdm.service @10.071s
└─plymouth-quit.service @10.047s +22ms
└─systemd-user-sessions.service @10.031s +7ms
└─remote-fs.target @10.026s
└─remote-fs-pre.target @10.025s
└─nfs-client.target @4.636s
└─gssproxy.service @4.607s +28ms
└─network.target @4.604s
└─NetworkManager.service @4.383s +219ms
└─dbus-broker.service @4.434s +136ms
└─dbus.socket @4.369s
└─sysinit.target @4.354s
└─systemd-update-utmp.service @4.345s +9ms
└─auditd.service @4.301s +42ms
└─systemd-tmpfiles-setup.service @4.254s +42ms
└─import-state.service @4.233s +19ms
└─local-fs.target @4.229s
└─Virtual.mount @4.019s +209ms
└─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s +274ms
└─local-fs-pre.target @3.726s
└─lvm2-monitor.service @356ms +637ms
└─dm-event.socket @319ms
└─-.mount
└─system.slice
└─-.slice
[root@david ~]#
Les nombres précédés de @ affiche le nombre absolu de secondes depuis le début du démarrage lorsque l'unité devient active. Les chiffres précédés de + affiche le temps nécessaire au démarrage de l'unité.
État du système
Parfois, vous devez déterminer l'état actuel du système. Le systemd-analyze dump la commande vide un massif quantité de données sur l'état actuel du système. Il commence par une liste des horodatages de démarrage principaux, une liste de chaque unité systemd et une description complète de l'état de chacun :
[root@david ~]# systemd-analyze dump
Timestamp firmware: 1min 7.983523s
Timestamp loader: 3.872325s
Timestamp kernel: Wed 2020-08-26 12:33:35 EDT
Timestamp initrd: Wed 2020-08-26 12:33:38 EDT
Timestamp userspace: Wed 2020-08-26 12:33:42 EDT
Timestamp finish: Wed 2020-08-26 16:33:56 EDT
Timestamp security-start: Wed 2020-08-26 12:33:42 EDT
Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT
Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT
Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT
-> Unit system.slice:
Description: System Slice
Instance: n/a
Unit Load State: loaded
Unit Active State: active
State Change Timestamp: Wed 2020-08-26 12:33:38 EDT
Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Exit Timestamp: n/a
Inactive Enter Timestamp: n/a
May GC: no
<SNIP – Deleted a bazillion lines of output>
Sur mon poste de travail principal, cette commande a généré un flux de 49 680 lignes et environ 1,66 Mo. Cette commande est très rapide, vous n'avez donc pas besoin d'attendre les résultats.
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
J'aime la richesse des détails fournis pour les différents appareils connectés, comme le stockage. Chaque unité systemd a une section avec des détails tels que les modes pour divers runtimes, le cache et les répertoires de journaux, la ligne de commande utilisée pour démarrer l'unité, l'ID de processus (PID), l'horodatage de démarrage, ainsi que les limites de mémoire et de fichiers. /P>
La page de manuel pour systemd-analyze affiche le systemd-analyze --user dump option, qui est destinée à afficher des informations sur l'état interne du gestionnaire d'utilisateurs. Cela échoue pour moi, et les recherches sur Internet indiquent qu'il peut y avoir un problème avec cela. Dans systemd, --user les instances sont utilisées pour gérer et contrôler les ressources de la hiérarchie des processus appartenant à chaque utilisateur. Les processus de chaque utilisateur font partie d'un groupe de contrôle, dont je parlerai dans un prochain article.
Graphiques analytiques
La plupart des patrons aux cheveux pointus (PHB) et de nombreux bons managers trouvent les jolis graphiques plus faciles à lire et à comprendre que les données de performances du système basées sur du texte que je préfère habituellement. Parfois, même si j'aime un bon graphique, et systemd-analyze offre la possibilité d'afficher les données de démarrage/démarrage dans une charte graphique vectorielle SVG.
La commande suivante génère un fichier graphique vectoriel qui affiche les événements qui se produisent lors de l'amorçage et du démarrage. Cela ne prend que quelques secondes pour générer ce fichier :
[root@david ~]# systemd-analyze plot > /tmp/bootup.svgCette commande crée un SVG, qui est un fichier texte qui définit une série de vecteurs graphiques que les applications, y compris Image Viewer, Ristretto, Okular, Eye of Mate, LibreOffice Draw et autres, utilisent pour générer un graphique. Ces applications traitent les fichiers SVG pour créer une image.
J'ai utilisé LibreOffice Draw pour afficher un graphique. Le graphique est énorme et vous devez zoomer considérablement pour distinguer les détails. En voici une petite partie :
La séquence de démarrage est à gauche du zéro (0) sur la chronologie du graphique, et la séquence de démarrage est à droite du zéro. Cette petite partie montre le noyau, initrd , et les processus initrd commencé.
Ce graphique montre en un coup d'œil ce qui a commencé quand, combien de temps il a fallu pour démarrer et les principales dépendances. Le chemin critique est surligné en rouge.
Une autre commande qui génère une sortie graphique est systemd-analyze plot . Il génère des descriptions textuelles des graphiques de dépendance au format DOT. Le flux de données résultant est ensuite acheminé via le dot , qui fait partie d'une famille de programmes pouvant être utilisés pour générer des fichiers graphiques vectoriels à partir de divers types de données. Ces fichiers SVG peuvent également être traités par les outils listés ci-dessus.
Tout d'abord, générez le fichier. Cela a pris près de neuf minutes sur mon poste de travail principal :
[root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg
Color legend: black = Requires
dark blue = Requisite
dark grey = Wants
red = Conflicts
green = After
real 8m37.544s
user 8m35.375s
sys 0m0.070s
[root@david ~]#
Je ne reproduirai pas la sortie ici car le graphique résultant est à peu près des spaghettis. Mais vous devriez l'essayer et voir le résultat pour voir ce que je veux dire.
Conditions
L'une des fonctionnalités les plus intéressantes, mais quelque peu génériques, que j'ai découvertes en lisant le systemd-analyze(1) la page de manuel est la condition sous-commande. (Oui, je lis les pages de manuel, et c'est incroyable ce que j'ai appris de cette façon !) Cette condition la sous-commande peut être utilisée pour tester les conditions et les assertions pouvant être utilisées dans les fichiers d'unité systemd.
Il peut également être utilisé dans des scripts pour évaluer une ou plusieurs conditions. Il renvoie un zéro (0) si toutes sont remplies ou un (1) si une condition n'est pas remplie. Dans les deux cas, il crache également du texte sur ses découvertes.
L'exemple ci-dessous, tiré de la page de manuel, est un peu complexe. Il teste pour une version de noyau comprise entre 4.0 et 5.1, que l'hôte fonctionne sur secteur, que l'architecture du système est tout sauf ARM et que le répertoire /etc/os-release existe. J'ai ajouté le echo $? déclaration pour imprimer le code de retour.
[root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release' ; \
echo $?
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
0
[root@david ~]#
La liste des conditions et des assertions commence vers la ligne 600 sur le systemd.unit(5) page de manuel.
Liste des fichiers de configuration
Le systemd-analyze L'outil fournit un moyen d'envoyer le contenu de divers fichiers de configuration à STDOUT , comme indiqué ici. Le répertoire de base est /etc/ :
[root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service
# /etc/systemd/system/display-manager.service
[Unit]
Description=LXDM (Lightweight X11 Display Manager)
#Documentation=man:lxdm(8)
[email protected]
After=systemd-user-sessions.service [email protected] plymouth-quit.service livesys-late.service
#Conflicts=plymouth-quit.service
[Service]
ExecStart=/usr/sbin/lxdm
Restart=always
IgnoreSIGPIPE=no
#BusName=org.freedesktop.lxdm
[Install]
Alias=display-manager.service
[root@david ~]#
C'est beaucoup de frappe pour ne rien faire de plus qu'un cat standard la commande le fait. Je trouve la commande suivante un tout petit peu utile. Il peut rechercher des fichiers avec le modèle spécifié dans les emplacements systemd standard :
[root@david ~]# systemctl cat backup*
# /etc/systemd/system/backup.timer
# This timer unit runs the local backup program
# (C) David Both
# Licensed under GPL V2
#
[Unit]
Description=Perform system backups
Requires=backup.service
[Timer]
Unit=backup.service
OnCalendar=*-*-* 00:15:30
[Install]
WantedBy=timers.target
# /etc/systemd/system/backup.service
# This service unit runs the rsbu backup program
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Backup services using rsbu
Wants=backup.timer
[Service]
Type=oneshot
Environment="HOME=/root"
ExecStart=/usr/local/bin/rsbu -bvd1
ExecStart=/usr/local/bin/rsbu -buvd2
[Install]
WantedBy=multi-user.target
[root@david ~]#
Ces deux commandes font précéder le contenu de chaque fichier d'une ligne de commentaire contenant le chemin d'accès complet et le nom du fichier.
Vérification du fichier d'unité
Après avoir créé un nouveau fichier unité, il peut être utile de vérifier que sa syntaxe est correcte. C'est ce que le verify la sous-commande le fait. Il peut répertorier les directives mal orthographiées et appeler les unités de service manquantes :
[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.serviceAdhérant à la philosophie Unix/Linux selon laquelle "le silence est d'or", l'absence de messages de sortie signifie qu'il n'y a pas d'erreurs dans le fichier analysé.
Sécurité
La security la sous-commande vérifie le niveau de sécurité des services spécifiés. Cela ne fonctionne que sur les unités de service et pas sur les autres types de fichiers d'unité :
[root@david ~]# systemd-analyze security display-manager
NAME DESCRIPTION >
✗ PrivateNetwork= Service has access to the host's network >
✗ User=/DynamicUser= Service runs as root user >
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities >
✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges >
✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities >
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets >
✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces >
✗ RestrictAddressFamilies=~… Service may allocate exotic sockets >
✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres>
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks >
✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges >
✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules
<SNIP>
✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() >
✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system >
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets >
→ Overall exposure level for backup.service: 9.6 UNSAFE ?
lines 34-81/81 (END)
Oui, l'emoji fait partie de la sortie. Mais, bien sûr, de nombreux services ont besoin d'un accès à peu près complet à tout pour faire leur travail. J'ai exécuté ce programme sur plusieurs services, y compris mon propre service de sauvegarde ; les résultats peuvent différer, mais le résultat final semble être essentiellement le même.
Cet outil serait très utile pour vérifier et réparer les unités de service de l'espace utilisateur dans les environnements critiques pour la sécurité. Je ne pense pas qu'il ait grand-chose à offrir à la plupart d'entre nous.
Réflexions finales
Cet outil puissant offre des options intéressantes et incroyablement utiles. Une grande partie de ce que cet article explore concerne l'utilisation de systemd-analyze pour fournir des informations sur les performances de démarrage de Linux à l'aide de systemd. Il peut également analyser d'autres aspects de systemd.
Certains de ces outils sont d'une utilité limitée, et quelques-uns devraient être complètement oubliés. Mais la plupart peuvent être utilisés à bon escient lors de la résolution de problèmes de démarrage et d'autres fonctions systemd.
Ressources
De nombreuses informations sur systemd sont disponibles sur Internet, mais la plupart sont concises, obtuses ou même trompeuses. En plus des ressources mentionnées dans cet article, les pages Web suivantes offrent des informations plus détaillées et fiables sur le démarrage de systemd. Cette liste s'est allongée depuis que j'ai commencé cette série d'articles pour refléter les recherches que j'ai effectuées.
- La page de manuel systemd.unit(5) contient une belle liste de sections de fichiers unitaires et leurs options de configuration, ainsi que des descriptions concises de chacune.
- Le projet Fedora propose un bon guide pratique de systemd. Il contient à peu près tout ce que vous devez savoir pour configurer, gérer et entretenir un ordinateur Fedora à l'aide de systemd.
- Le projet Fedora a également une bonne feuille de triche qui renvoie les anciennes commandes SystemV à des commandes systemd comparables.
- La documentation Red Hat contient une bonne description de la structure des fichiers Unit ainsi que d'autres informations importantes.
- Pour des informations techniques détaillées sur systemd et les raisons de sa création, consultez la description de systemd par Freedesktop.org.
- Linux.com's "More systemd fun" propose des informations et des conseils plus avancés sur systemd.
Il existe également une série d'articles profondément techniques pour les administrateurs système Linux par Lennart Poettering, le concepteur et développeur principal de systemd. Ces articles ont été écrits entre avril 2010 et septembre 2011, mais ils sont tout aussi pertinents aujourd'hui qu'ils l'étaient alors. Une grande partie de tout ce qui a été écrit sur systemd et son écosystème est basé sur ces articles.
- Repenser le PID 1
- systemd pour les administrateurs, partie I
- systemd pour les administrateurs, partie II
- systemd pour les administrateurs, partie III
- systemd pour les administrateurs, partie IV
- systemd pour les administrateurs, partie V
- systemd pour les administrateurs, partie VI
- systemd pour les administrateurs, partie VII
- systemd pour les administrateurs, partie VIII
- systemd pour les administrateurs, partie IX
- systemd pour les administrateurs, partie X
- systemd pour les administrateurs, partie XI