systemd-analyze time

Cette commande affiche le temps écoulé dans le noyau avant que l'espace utilisateur n'ait été atteint, le temps écoulé dans l'initrd avant que l'espace utilisateur normal du système ne soit atteint, et le temps pris par l'espace utilisateur normal du système pour s'initialiser. Notez que ces mesures ne font que mesurer le temps écoulé jusqu'au moment où tous les services du système ont été lancés, mais pas nécessairement jusqu'à ce qu'ils aient terminé leur initialisation ou que le disque soit inactif.

Exemple 1. Afficher la durée de l'amorçage (boot)

# dans un conteneur
$ systemd-analyze time
Startup finished in 296ms (userspace)
multi-user.target reached after 275ms in userspace
# sur une vraie machine
$ systemd-analyze time
Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
multi-user.target reached after 47.820s in userspace

systemd-analyze blame

Cette commande affiche une liste de toutes les unités en service, classées en fonction du temps passé à s'initialiser. Cette information peut être utilisée pour optimiser les temps d'amorçage. Prenez en compte que la sortie peut être trompeuse étant donné que l'initialisation d'un service peut apparaître lente simplement parce qu'il attend l'initialisation d'un autre service pour se finaliser. Notez aussi : systemd-analyze blame n'affiche pas de résultats pour les services avec Type=simple, car systemd considère de tels services comme démarrant immédiatement, ce qui fait qu'aucune mesure de délai d'initialisation ne peut être faite. Notez aussi que cette commande ne montre que le temps pris par les unités pour démarrer, elle ne montre pas combien de temps ont passé les tâches de l'unité dans la file d'attente d'exécutions. Cela montre en particulier le temps que l'unité a passé en état « actif », lequel n'est pas défini pour les unités telles que les unités périphériques qui effectuent une transition directement d'« inactive » à « active ». Cette commande donne ainsi une impression de la performance du code du programme, mais ne peut refléter avec exactitude la latence introduite par l'attente du matériel et d'évènements similaires.

Exemple 2. Afficher quelles unités prennent le plus de temps lors de l'amorçage

$ systemd-analyze blame
         32.875s pmlogger.service
         20.905s systemd-networkd-wait-online.service
         13.299s dev-vda1.device
         ...
            23ms sysroot.mount
            11ms initrd-udevadm-cleanup-db.service
             3ms sys-kernel-config.mount

systemd-analyze critical-chain [UNITÉ...]

Cette commande affiche un arbre de la chaîne de temps critique d'unités (pour chacune des UNITÉs indiquées ou pour la cible par défaut sinon). Le temps écoulé pour que l'unité soit active ou démarrée est affiché après le caractère « @ ». Le temps pris par l'unité pour démarrer est affiché après le caractère « + ». Notez que la sortie peut être inexacte dans la mesure où l'initialisation de services pourrait dépendre de l'activation d'un socket et à cause de l'exécution en parallèle d'unités. Aussi, à l'instar de la commande blame, cette commande ne prend en compte que le temps passé par les unités en état d'« activation », et donc ne couvre pas les unités qui ne sont jamais passées par un état d'« activation » (telles les unités de périphériques d'unité qui passent directement de l'état « inactif » à « actif »). En outre, elle ne montre pas d'information sur les tâches (et en particulier sur les tâches achevées).

Exemple 3. systemd-analyze critical-chain

$ systemd-analyze critical-chain
multi-user.target @47.820s
└─pmie.service @35.968s +548ms
  └─pmcd.service @33.715s +2.247s
    └─network-online.target @33.712s
      └─systemd-networkd-wait-online.service @12.804s +20.905s
        └─systemd-networkd.service @11.109s +1.690s
          └─systemd-udevd.service @9.201s +1.904s
            └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
              └─kmod-static-nodes.service @6.976s +177ms
                └─systemd-journald.socket
                  └─system.slice
                    └─-.slice

systemd-analyze dump [motif...]

Sans aucun paramètre, cette commande renvoie une sérialisation lisible (habituellement très longue) de l'état complet du gestionnaire de services. Un motif global (glob) facultatif peut être spécifié, limitant la sortie aux unités dont les noms correspondent à l'un des motifs. Le format de sortie est susceptible d'être modifié sans préavis et ne devrait pas être soumis à l'analyse par des applications. Cette commande a un débit limité pour les utilisateurs non privilégiés.

Exemple 4. Afficher l'état interne du gestionnaire utilisateur

$ systemd-analyze --user dump
Timestamp userspace: Thu 2019-03-14 23:28:07 CET
Timestamp finish: Thu 2019-03-14 23:28:07 CET
Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
-> Unit proc-timer_list.mount:
        Description: /proc/timer_list
        ...
-> Unit default.target:
        Description: Main user target
...

systemd-analyze malloc [D-Bus service...]

Cette commande peut être utilisée pour demander la sortie de l'état de la mémoire interne (comme renvoyé par malloc_info(3)) d'un service D-Bus. Si aucun service n'est indiqué, la demande sera envoyée à org.freedesktop.systemd1 (le gestionnaire de services système ou utilisateur). La stabilité du format de sortie n'est pas garantie et ne devrait pas être analysé par les applications.

Le service doit implémenter l'interface org.freedesktop.MemoryAllocation1. Dans la suite systemd, elle est actuellement implémentée seulement par le gestionnaire.

systemd-analyze plot

Cette commande affiche un graphique SVG détaillant quels services du système ont démarré à quel moment, mettant en évidence le temps passé à leur initialisation, ou les données horaires brutes en format JSON ou tableau.

Exemple 5. Tracer un graphique d'amorçage

$ systemd-analyze plot >bootup.svg
$ eog bootup.svg&

Il convient de noter que ce graphique est basé sur les données les plus récentes relatives à la synchronisation des unités chargées. Cela signifie que si une unité démarre, est stoppée et redémarre encore, les informations affichées ne couvriront que le cycle de démarrage le plus récent, pas le premier. Par conséquent, il est conseillé de consulter ces informations peu de temps après l'amorçage, pour que cette distinction importe peu. En outre, les unités qui ne sont référencées par aucune autre unité par le biais d'une dépendance peuvent être déchargées par le gestionnaire de service une fois qu'elles se terminent (et qu'elles n'ont pas échoué). Ces unités n'apparaîtront pas dans le graphique.

systemd-analyze dot [motif...]

Cette commande génère une description textuelle du graphe de dépendances au format dot pour un traitement ultérieur avec l'outil GraphViz dot(1). Utilisez une ligne de commande telle que systemd-analyze dot | dot -Tsvg >systemd.svg pour générer un arbre de dépendances graphique. À moins que --order ou --require ne soit passées, le graphe obtenu montrera à la fois les dépendances d'ordre et d'exigence. Le motif optionnel de spécifications de style globbing (par exemple *.cible) peut être donné à la fin. Une dépendance d'unité n'est inclue dans le graphe que si l'un des motifs correspond à la fois au nœud d'origine ou de destination.

Exemple 6. Tracer toutes les dépendances des unités dont le nom commence avec « avahi-daemon »

$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
$ eog avahi.svg

Exemple 7. Tracer les dépendances entre toutes les unités cibles connues

$ systemd-analyze dot --to-pattern='*.cible' --from-pattern='*.cible' \
      | dot -Tsvg >cibles.svg
$ eog cibles.svg

systemd-analyze unit-paths

Cette commande affiche une liste de tous les répertoires desquels les fichiers d'unité, .d overrides, et les liens symboliques .wants, .requires doivent être chargés. À combiner avec -- user pour retrouver la liste pour l'instance du gestionnaire utilisateur, et -- global pour la configuration globale des instances du gestionnaire utilisateur.

Exemple 8. Afficher tous les chemins pour les unités générées

$ systemd-analyze unit-paths | grep '^/run'
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/run/systemd/generator.late

Remarquez que cette commande affiche la liste qui est compilée à l'intérieur de systemd-analyze et ne communique pas avec le gestionnaire en cours d'exécution. Utilisez

systemctl [--user] [--global] show -p UnitPath --value

pour retrouver la liste réellement utilisée par le gestionnaire, avec tout répertoire vide omis.

systemd-analyze exit-status [ÉTAT...]

Cette commande affiche une liste des codes de retour avec leur « classe », c'est-à-dire la source de la définition (une parmi « glibc », « systemd », « LSB » ou « BSD »), voir la section des codes retour des processus dans systemd.exec(5). Si aucun autre argument n'est indiqué, tous les états connus sont affichés. Sinon, seules les définitions pour les codes indiqués sont affichées.

Exemple 9. Afficher quelques exemples de noms d'état de retour

$ systemd-analyze exit-status 0 1 {63..65}
NAME    STATUS CLASS
SUCCESS 0      glibc
FAILURE 1      glibc
-       63     -
USAGE   64     BSD
DATAERR 65     BSD

systemd-analyze capability [CAPACITÉ...]

Cette commande affiche une liste des capacités (capabilities) de Linux avec leur identifiant numérique. Consulter capabilities(7) pour les détails. Si aucun argument n'est indiqué, la liste entière des capacités connues du gestionnaire de services et du noyau est affichée. Les capacités définies par le noyau, mais inconnues du gestionnaire de services sont affichées en tant que « cap_??? ». En option, si des arguments sont spécifiés, ils doivent se référer aux capacités spécifiées par leur nom ou identifiant numérique, auquel cas seules les capacités indiquées sont montrées dans la table.

Exemple 10. Afficher quelques exemples de noms de capacité

$ systemd-analyze capability 0 1 {30..32}
NAME              NUMBER
cap_chown              0
cap_dac_override       1
cap_audit_control     30
cap_setfcap           31
cap_mac_override      32

systemd-analyze condition CONDITION...

Cette commande évaluera les affectations Condition*=... et Assert*=... et affichera leurs valeurs et la valeur résultante de l'ensemble de conditions jointes. Consulter systemd.unit(5) pour une liste des conditions disponibles et assertions.

Exemple 11. Évaluer les conditions qui vérifient les versions du noyau

$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
        'ConditionKernelVersion = >=5.1' \
        'ConditionACPower=|false' \
        'ConditionArchitecture=|!arm' \
        'AssertPathExists=/etc/os-release'
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.

systemd-analyze syscall-filter [ENSEMBLE...]

Cette commande listera tous les appels système contenus dans l'ensemble des appels système indiqué ENSEMBLE, ou tout ensemble si aucun ensemble n'est spécifié. L'argument ENSEMBLE doit inclure le préfixe « @ ».

systemd-analyze filesystems [ENSEMBLE...]

Cette commande listera les systèmes de fichiers dans l'ensemble de systèmes de fichiers indiqué ENSEMBLE, ou tout ensemble connu si aucun ensemble n'est spécifié. L'argument ENSEMBLE doit inclure le préfixe « @ ».

systemd-analyze calendar EXPRESSION...

Cette commande va analyser et normaliser les événements calendaires répétitifs et calculera la prochaine échéance. Elle prend la même entrée que le OnCalendar= défini dans systemd.timer(5), en suivant la syntaxe décrite dans systemd.time(7). Seule la prochaine échéance de l'expression moment calendaire à survenir est montrée par défaut : utiliser -- iterations= pour afficher le nombre de fois indiqué des prochaines échéances où l'expression se produira. Chaque moment où l'expression se déroule forme un horodatage, voir le verbatim timestamp ci-dessous.

Exemple 12. Afficher les jours bissextiles dans un futur proche

$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
  Original form: *-2-29 0:0:0
Normalized form: *-02-29 00:00:00
    Next elapse: Sat 2020-02-29 00:00:00 UTC
       From now: 11 months 15 days left
       Iter. #2: Thu 2024-02-29 00:00:00 UTC
       From now: 4 years 11 months left
       Iter. #3: Tue 2028-02-29 00:00:00 UTC
       From now: 8 years 11 months left
       Iter. #4: Sun 2032-02-29 00:00:00 UTC
       From now: 12 years 11 months left
       Iter. #5: Fri 2036-02-29 00:00:00 UTC
       From now: 16 years 11 months left

systemd-analyze timestamp HORODATAGE...

Cette commande analyse un horodatage (c'est-à-dire un simple point dans le temps) et renvoie la forme normalisée et la différence entre cet horodatage et maintenant. L'horodatage doit se conformer à la syntaxe documentée dans systemd.time(7), section « PARSING TIMESTAMPS » (analyse des horodatages).

Exemple 13. Afficher l'analyse d'horodatages

$ systemd-analyze timestamp yesterday now tomorrow
  Original form: yesterday
Normalized form: Mon 2019-05-20 00:00:00 CEST
       (in UTC): Sun 2019-05-19 22:00:00 UTC
   UNIX seconds: @15583032000
       From now: 1 day 9h ago
  Original form: now
Normalized form: Tue 2019-05-21 09:48:39 CEST
       (in UTC): Tue 2019-05-21 07:48:39 UTC
   UNIX seconds: @1558424919.659757
       From now: 43us ago
  Original form: tomorrow
Normalized form: Wed 2019-05-22 00:00:00 CEST
       (in UTC): Tue 2019-05-21 22:00:00 UTC
   UNIX seconds: @15584760000
       From now: 14h left

systemd-analyze timespan EXPRESSION...

Cette commande analyse un laps de temps (timespan) (c'est-à-dire la différence entre deux horodatages) et renvoie la forme normalisée et la valeur équivalente en microsecondes. La durée doit se conformer à la syntaxe documentée dans systemd.time(7), section « PARSING TIME SPANS » (analyse de durées). Les valeurs sans unités sont analysées comme des secondes.

Exemple 14. Afficher l'analyse des durées

$ systemd-analyze timespan 1s 300s '1year 0.000001s'
Original: 1s
      μs: 1000000
   Human: 1s
Original: 300s
      μs: 300000000
   Human: 5min
Original: 1year 0.000001s
      μs: 31557600000001
   Human: 1y 1us

systemd-analyze cat-config NOM|CHEMIN...

Cette commande est similaire à systemctl cat, mais opère sur les fichiers de configuration. Elle copiera les contenus d'un fichier de configuration et autres bagatelles dans la sortie standard, en utilisant l'ensemble des répertoires et des règles de priorité habituel de systemd. Chaque argument doit être soit un chemin absolu incluant le préfixe (tel que /etc/systemd/logind.conf ou /usr/lib/systemd/logind.conf) ou un nom relatif au préfixe (tel que systemd/logind.conf).

Exemple 15. Afficher la configuration de logind

$ systemd-analyze cat-config systemd/logind.conf
# /etc/systemd/logind.conf
...
[Login]
NAutoVTs=8
...
# /usr/lib/systemd/logind.conf.d/20-test.conf
... quelque dérogation d'un autre paquet
# /etc/systemd/logind.conf.d/50-override.conf
... quelque dérogation d'un administrateur

systemd-analyze compare-versions VERSION1 [OP] VERSION2

Cette commande a deux modes opératoires distincts, selon que l'opérateur OP est spécifié ou non.

Dans le premier mode — lorsque OP n'est pas indiqué — cette commande comparera les deux chaînes de version et affichera soit « VERSION1 < VERSION2 », ou « VERSION1 == VERSION2 », ou « VERSION1 > VERSION2 » en fonction du résultat.

Le code retour est 0 si les versions sont identiques, 11 si la version de droite est plus petite et 12 si la version de gauche est plus petite (cela correspond à la convention utilisée par rpmdev-vercmp).

Dans le second mode (lorsque OP est indiqué), cette commande comparera les deux chaînes de version en utilisant l'opération OP et renverra 0 (succès) si les conditions sont satisfaites, et 1 (échec) sinon . OP peut être it, te, eq, ne, ge, gt. Dans ce mode, aucun retour n'est affiché (cela correspond à la convention utilisée par dpkg(1) --compare-versions).

Exemple 16. Comparer les versions d'un paquet

$ systemd-analyze compare-versions systemd-250~rc1.fc36.aarch64 systemd-251.fc36.aarch64
systemd-250~rc1.fc36.aarch64 < systemd-251.fc36.aarch64
$ echo $?
$ systemd-analyze compare-versions 1 lt 2; echo $?
0
$ systemd-analyze compare-versions 1 ge 2; echo $?
1

systemd-analyze verify FICHIER...

Cette commande chargera les fichiers d'unité et affichera des avertissements si des erreurs sont détectées. Les fichiers indiqués sur la ligne de commande seront chargés, mais aussi toute autre unité référencée par eux. Un nom d'unité sur disque peut être remplacé en spécifiant un alias après un « deux-points » ; voir ci-dessous pour un exemple. Le chemin de recherche complet de l'unité est formé en combinant les répertoires de tous les arguments de la ligne de commande et les chemins habituels de chargement des unités. La variable $SYSTEMD_UNIT_PATH est prise en charge et peut être utilisée pour remplacer ou augmenter l'ensemble compilé des chemins des unités chargées ; consulter systemd.unit(5). Tous les fichiers présents dans les répertoires contenant les arguments de ligne de commande seront utilisés en préférence aux autres chemins.

Les erreurs suivantes sont souvent détectées :

Exemple 17. Directives mal écrites

$ cat ./user.slice
[Unit]
WhatIsThis=11
Documentation=man:nosuchfile(1)
Requires=different.service
[Service]
Description=x
$ systemd-analyze verify ./user.slice
[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
[./user.slice:13] Unknown section 'Service'. Ignoring.
Error: org.freedesktop.systemd1.LoadFailed:
   Unit different.service failed to load:
   No such file or directory.
Failed to create user.slice/start: Invalid argument
user.slice: man nosuchfile(1) command failed with code 16

Exemple 18. Unités de service manquantes

$ tail ./a.socket ./b.socket
==> ./a.socket <==
[Socket]
ListenStream=100
==> ./b.socket <==
[Socket]
ListenStream=100
Accept=yes
$ systemd-analyze verify ./a.socket ./b.socket
Service a.service not loaded, a.socket cannot be started.
Service b@0.service not loaded, b.socket cannot be started.

Exemple 19. Faire un alias d'une unité

$ cat /tmp/source
[Unit]
Description=Hostname printer
[Service]
Type=simple
ExecStart=/usr/bin/echo %H
MysteryKey=true
$ systemd-analyze verify /tmp/source
Failed to prepare filename /tmp/source: Invalid argument
$ systemd-analyze verify /tmp/source:alias.service
alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.

systemd-analyze security [UNITÉ...]

Cette commande analyse la sécurité et l'ensemble des bacs à sable pour une ou plusieurs unités de service. Si au moins un nom d'unité est spécifié, les réglages des unités du service spécifiées sont inspectés et une analyse détaillée est affichée. Si aucun nom d'unité n'est spécifié, toutes les unités de service chargées et en fonctionnement sont inspectées et un tableau succinct des résultats est affiché. La commande vérifie différents réglages relatifs à la sécurité du service, assignant à chacun une valeur de « niveau d'exposition », en fonction de l'importance du réglage. Elle calcule ensuite un niveau d'exposition global pour l'ensemble de l'unité, qui est une estimation dans l'intervalle de 0.0...10.0 indiquant le degré d'exposition d'un service en matière de sécurité. Des degrés d'exposition élevés indiquent un « bac à sable » très peu appliqué. Les faibles niveaux d'exposition indiquent une application du bac à sable serrée et des restrictions de sécurité très strictes. Notez que cette commande n'analyse que les fonctionnalités de sécurité par service que systemd lui-même met en œuvre. Cela signifie que tout mécanisme de sécurité supplémentaire appliqué par le code du service lui-même n'est pas pris en compte. Le niveau d'exposition déterminé de cette manière ne doit pas être mal compris : un haut niveau d'exposition ne signifie pas qu'il n'y a pas de bac à sable effectif appliqué par le code du service lui-même, ni que le service est réellement vulnérable à des attaques à distance ou locales. De hauts niveaux d'exposition indiquent que le service pourrait bénéficier de réglages supplémentaires.

Veuillez prendre en compte que la plupart des réglages individuels pour le bac à sable ou la sécurité peuvent être contournés — à moins d'être combinés avec d'autres. Par exemple, si un service conserve le privilège d'établir ou de démonter des points de montage, beaucoup des options du bac à sable peuvent être défaites par le code du service lui-même. C'est pour cela qu'il est essentiel que chaque service use de réglages de bac à sable et de sécurité les plus exhaustifs et stricts possibles. L'outil prendra en compte quelques-unes de ces combinaisons et relations entre les réglages, mais pas toutes. Remarquez aussi que les réglages de bac à sable et de sécurité analysés ici ne concernent que les opérations faites par le code du service lui-même. Si un service a accès à un système IPC (tel que D-Bus), il pourrait nécessiter des opérations de la part d'autres services qui ne sont pas astreints aux mêmes restrictions. Toute analyse exhaustive de bac à sable et de sécurité est donc incomplète si la politique d'accès IPC n'est pas aussi validée.

Exemple 20. Analyser systemd-logind.service

$ systemd-analyze security --no-pager systemd-logind.service
  NAME                DESCRIPTION                              EXPOSURE
✗ PrivateNetwork=     Service has access to the host's network      0.5
✗ User=/DynamicUser=  Service runs as root user                     0.4
✗ DeviceAllow=        Service has no device ACL                     0.2
✓ IPAddressDeny=      Service blocks all IP address ranges
...
→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂

systemd-analyze inspect-elf FICHIER...

Cette commande charge les fichiers spécifiés et, s'ils sont des objets ELF (exécutables, bibliothèques, fichier core, etc.), elle analysera les métadonnées d'empaquetage incorporées, si présentes et les affichera dans une table ou au format json. Voir la documentation Packaging Metadata[1] pour plus d'information.

Exemple 21. Afficher les informations d'un fichier core au format JSON

$ systemd-analyze inspect-elf --json=pretty \
        core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
{
        "elfType" : "coredump",
        "elfArchitecture" : "AMD x86-64",
        "/home/bluca/git/fsverity-utils/fsverity" : {
                "type" : "deb",
                "name" : "fsverity-utils",
                "version" : "1.3-1",
                "buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"
        },
        "/home/bluca/git/fsverity-utils/libfsverity.so.0" : {
                "type" : "deb",
                "name" : "fsverity-utils",
                "version" : "1.3-1",
                "buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"
        }
}

systemd-analyze fdstore UNITÉ...

Cette commande liste les contenus actuels du magasin de descripteurs de fichier de l'unité de service spécifiée et affiche les noms, les types d'inœud, les numéros de périphérique, les numéros d'inœud, les chemins et les modes d'ouverture des descripteurs de fichier ouverts. Les unités indiquées doivent avoir FileDescriptorStoreMax= activé ; consultez systemd.service(5) pour les détails.

Exemple 22. Sortie sous forme de table

$ systemd-analyze fdstore systemd-journald.service
FDNAME TYPE DEVNO   INODE RDEVNO PATH             FLAGS
stored sock 0:8   4218620 -      socket:[4218620] ro
stored sock 0:8   4213198 -      socket:[4213198] ro
stored sock 0:8   4213190 -      socket:[4213190] ro
...

Remarque : la colonne « DEVNO » désigne les numéros majeur/mineur du nœud du périphérique associé au système de fichiers dans lequel se trouve le nœud du descripteur de fichier. La colonne « RDEVNO » désigne les numéros majeur/mineur du nœud du périphérique lui-même, si le descripteur de fichier s'y réfère. Comparer avec les champs correspondants à .st_dev et .st_rdev dans struct stat (voir stat(2) pour les détails). Les numéros d'inœuds de la colonne « INODE » sont sur le système de fichiers indiqué par « DEVNO ».

systemd-analyze image-policy POLITIQUE...

Cette commande analyse la chaîne de politique de l'image indiquée, comme pour systemd.image-policy(7). Cette politique est normalisée et simplifiée. Pour chaque identifiant de partition défini actuellement (comme pour la Spécification des Partitions Détectables[2]) l'effet de la chaîne de politique de l'image est affiché sous la forme de tableau.

Exemple 23. Exemple de sortie

$ systemd-analyze image-policy swap=encrypted:usr=read-only-on+verity:root=encrypted
Analyzing policy: root=encrypted:usr=verity+read-only-on:swap=encrypted
       Long form: root=encrypted:usr=verity+read-only-on:swap=encrypted:=unused+absent
PARTITION       MODE        READ-ONLY GROWFS
root            encrypted   -         -
usr             verity      yes       -
home            ignore      -         -
srv             ignore      -         -
esp             ignore      -         -
xbootldr        ignore      -         -
swap            encrypted   -         -
root-verity     ignore      -         -
usr-verity      unprotected yes       -
root-verity-sig ignore      -         -
usr-verity-sig  ignore      -         -
tmp             ignore      -         -
var             ignore      -         -
default         ignore      -         -

systemd-analyze pcrs [PCR...]

Cette commande affiche les PCR TPM2 connus avec leurs noms d’identification et leurs valeurs actuelles.

Exemple 24. Exemple de sortie

$ systemd-analyze pcrs
NR NAME                SHA256
 0 platform-code       bcd2eb527108bbb1f5528409bcbe310aa9b74f687854cc5857605993f3d9eb11
 1 platform-config     b60622856eb7ce52637b80f30a520e6e87c347daa679f3335f4f1a600681bb01
 2 external-code       1471262403e9a62f9c392941300b4807fbdb6f0bfdd50abfab752732087017dd
 3 external-config     3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
 4 boot-loader-code    939f7fa1458e1f7ce968874d908e524fc0debf890383d355e4ce347b7b78a95c
 5 boot-loader-config  864c61c5ea5ecbdb6951e6cb6d9c1f4b4eac79772f7fe13b8bece569d83d3768
 6 -                   3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
 7 secure-boot-policy  9c905bd9b9891bfb889b90a54c4b537b889cfa817c4389cc25754823a9443255
 8 -                   0000000000000000000000000000000000000000000000000000000000000000
 9 kernel-initrd       9caa29b128113ef42aa53d421f03437be57211e5ebafc0fa8b5d4514ee37ff0c
10 ima                 5ea9e3dab53eb6b483b6ec9e3b2c712bea66bca1b155637841216e0094387400
11 kernel-boot         0000000000000000000000000000000000000000000000000000000000000000
12 kernel-config       627ffa4b405e911902fe1f1a8b0164693b31acab04f805f15bccfe2209c7eace
13 sysexts             0000000000000000000000000000000000000000000000000000000000000000
14 shim-policy         0000000000000000000000000000000000000000000000000000000000000000
15 system-identity     0000000000000000000000000000000000000000000000000000000000000000
16 debug               0000000000000000000000000000000000000000000000000000000000000000
17 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000

systemd-analyze srk > FICHIER

Cette commande lit la clé racine de stockage (SRK) du dispositif TPM2 et l'écrit au format TPM2B_PUBLIC rassemblé sur la sortie. Exemple :

systemd-analyze srk > srk.tpm2b_public