Provided by: manpages-fr_4.21.0-2_all bug

NOM

       systemd-analyze — Analyser et déboguer le gestionnaire du système

SYNOPSIS

       systemd-analyze [OPTIONS...] [time]

       systemd-analyze [OPTIONS...] blame

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

       systemd-analyze [OPTIONS...] dump [MOTIF...]

       systemd-analyze [OPTIONS...] plot [>fichier.svg]

       systemd-analyze [OPTIONS...] dot [MOTIF...] [>fichier.dot]

       systemd-analyze [OPTIONS...] unit-files

       systemd-analyze [OPTIONS...] unit-paths

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

       systemd-analyze [OPTIONS...] capability [CAPACITÉ...]

       systemd-analyze [OPTIONS...] condition CONDITION...

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

       systemd-analyze [OPTIONS...] filesystems [ENSEMBLE...]

       systemd-analyze [OPTIONS...] calendar SPEC...

       systemd-analyze [OPTIONS...] timestamp HORODATAGE...

       systemd-analyze [OPTIONS...] timespan DURÉE...

       systemd-analyze [OPTIONS...] cat-config NOM|CHEMIN...

       systemd-analyze [OPTIONS...] compare-versions VERSION1 [OP] VERSION2

       systemd-analyze [OPTIONS...] verify [FICHIER...]

       systemd-analyze [OPTIONS...] security UNITÉ...

       systemd-analyze [OPTIONS...] inspect-elf FICHIER...

       systemd-analyze [OPTIONS...] malloc [D-BUS SERVICE...]

       systemd-analyze [OPTIONS...] fdstore [UNITÉ...]

       systemd-analyze [OPTIONS...] image-policy POLITIQUE...

       systemd-analyze [OPTIONS...] pcrs [PCR...]

       systemd-analyze [OPTIONS...] srk > FILE

DESCRIPTION

       systemd-analyze peut être utilisée pour déterminer les statistiques de performance du
       démarrage du système et récupérer d'autres informations d'état et de traçage du système et
       du gestionnaire de services, et vérifier la justesse des fichiers d'unité. Elle est aussi
       utilisée pour accéder à des fonctions spéciales utiles au débogage avancé du gestionnaire
       du système.

       Si aucune commande n'est passée, systemd-analyze-time est implicite.

   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. Evaluer 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 :

       •   instructions et sections inconnues.

       •   dépendances nécessaires au démarrage de l'unité donnée manquantes.

       •   pages de manuel listées dans Documentation= qui sont introuvables dans le système.

       •   commandes listées dans ExecStart= et similaires qui sont introuvables dans le système
           ou non exécutables.

       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...]
       This command analyzes the specified image policy string, as per systemd.image-policy(7).
       The policy is normalized and simplified. For each currently defined partition identifier
       (as per the Discoverable Partitions Specification[2]) the effect of the image policy
       string is shown in tabular form.

       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 > FILE
       This command reads the Storage Root Key (SRK) from the TPM2 device, and writes it in
       marshalled TPM2B_PUBLIC format to stdout. Example:

           systemd-analyze srk > srk.tpm2b_public

OPTIONS

       Les options suivantes sont comprises :

       --system
           Agir sur l'instance systemd du système. C'est l'option implicite par défaut.

           Added in version 209.

       --user
           Agir sur l'instance systemd de l'utilisateur.

           Added in version 186.

       --global
           Agir sur la configuration de l'ensemble du système pour l'instance systemd de
           l'utilisateur.

           Added in version 238.

       --order, --require
           Ces options sélectionnent quelles dépendances seront montrées dans le graphe de
           dépendances, lorsqu'utilisées conjointement à la commande dot (voir ci-dessus). Si
           --order est passée, seules les dépendances du type After= ou Before= sont affichées.
           Si --require est passée, seules les dépendances du type Requires=, Requisite, Wants=
           et Conflicts= sont affichées. Si aucune n'est passée, les dépendances de tous ces
           types seront affichées.

           Added in version 198.

       --from-pattern=, --to-pattern=
           Ces options sélectionnent quelles relations sont montrées dans le graphe de
           dépendances lorsqu'utilisées avec la commande dot (voir ci-dessus). Les deux options
           nécessitent un motif glob(7) comme argument qui sera comparé au côté droit et au côté
           gauche, respectivement, des nœuds de la relation.

           Chacune d'elles peut être utilisée plus d'une fois, auquel cas le nom de l'unité doit
           correspondre à l'une de ces valeurs. Une relation doit passer les deux tests pour être
           affichée lorsque les tests pour les deux côtés de la relation sont présents. Quand les
           motifs sont aussi spécifiés comme argument de position, ils doivent correspondre a
           minima à l'un des côtés de la relation. En d'autres termes, les motifs indiqués dans
           ces deux options réduiront la liste des extrémités correspondant aux arguments de
           position, s'il y en a de donnés, et détermineront totalement la liste des extrémités
           qui seront affichées sinon.

           Added in version 201.

       --fuzz=durée
           Lorsqu'utilisée conjointement avec la commande critical-chain (voir ci-dessus), cette
           option montrera aussi les unités qui ont fini leur durée avant la dernière unité sur
           le même niveau. L'unité de la durée est la seconde, à moins qu'une unité différente
           soit spécifiée, par exemple « 50ms ».

           Added in version 203.

       --man=no
           Ne pas invoquer man(1) pour vérifier la présence de pages de manuel listées dans
           Documentation=.

           Added in version 235.

       --generators
           Invoquer les générateurs d'unités, consulter systemd.generator(7). Certains
           générateurs nécessitent les privilèges du superutilisateur. Fonctionner avec les
           générateurs activés en tant qu'utilisateur normal résultera en général en plusieurs
           avertissements.

           Added in version 235.

       --recursive-errors=MODE
           Contrôler la vérification des unités et leurs dépendances et si systemd-analyze verify
           finit avec un code de retour différent de zéro ou pas. Avec yes, renvoyer un code de
           retour de processus différent de zéro lorsque des avertissements surviennent pendant
           la vérification de l'unité spécifiée ou de l'une de ses dépendances associées. Avec
           no, renvoyer un code de retour de processus différent de zéro lorsque des
           avertissements surviennent durant la vérification de l'unité spécifiée uniquement.
           Avec one, renvoyer un code de retour de processus différent de zéro lorsque des
           avertissements surviennent lors de la vérification de l'unité indiquée ou de ses
           dépendances immédiates. Si cette option n'est pas spécifiée, zéro est renvoyé comme
           code de retour, que des avertissements surviennent ou pas lors de la vérification.

           Added in version 250.

       --root=CHEMIN
           Opérer sur les fichiers sous le chemin racine spécifié CHEMIN, avec cat-files et
           verify.

           Added in version 239.

       --image=CHEMIN
           Avec cat-files et verify, opérer sur les fichiers dans le chemin d'image spécifié
           CHEMIN.

           Added in version 250.

       --image-policy=politique
           Prendre une chaîne de politique d'image comme argument, comme pour
           systemd.image-policy(7). L'application de la politique est imposée lors d'opération
           sur l'image disque indiquée à l'aide de --image ; voir ci-dessus. Si rien n'est
           indiqué, c'est par défaut la politique « * », c'est-à-dire tous les systèmes de
           fichiers reconnus de l'image sont utilisés.

       --offline=BOOL
           Avec security, effectuer un audit de sécurité hors-ligne des fichiers d'unité
           spécifiés, c'est-à-dire ne pas dépendre du PID 1 pour avoir des informations de
           sécurité sur les fichiers de la même façon que la commande security lorsqu'utilisée
           seule. Cela signifie que --offline= peut être utilisée aussi bien avec --root= qu'avec
           --image=. Si le niveau d'exposition global d'une unité est plus élevé que ce qui est
           défini par --threshold= (dont la valeur par défaut est 100), --offline= enverra une
           erreur.

           Added in version 250.

       --profile=CHEMIN
           Avec security --offline=, prend en considération le profil portable indiqué lors de
           l'accession aux réglages de l'unité. Le profil peut être passé sous la forme d'un nom,
           auquel cas son emplacement connu sur le système sera cherché, ou il peut être un
           chemin complet vers un fichier de remplacement spécifique.

           Added in version 250.

       --threshold=NOMBRE
           Avec security, autorise l'utilisateur à définir une valeur personnalisée à comparer au
           niveau d'exposition global pour les fichiers d'unité indiqués. Si le niveau
           d'exposition global d'une unité est supérieur à ce qui a été défini par l'utilisateur,
           security renverra une erreur. --threshold= peut aussi être utilisé avec --offline= et
           sa valeur par défaut est 100.

           Added in version 250.

       --security-policy=CHEMIN
           Avec security, permettre à l'utilisateur de définir un ensemble personnalisé
           d'exigences formatées comme un fichier JSON auquel comparer le(s) fichier(s) d'unité
           spécifié(s) et déterminer leur niveau d'exposition global aux menaces de sécurité.

           Table 1. Identificateurs de test d'évaluation acceptés
           Voir l'exemple « JSON Policy » ci-dessous.

           Added in version 250.

       --json=MODE
           Avec la commande security, générer une sortie formatée JSON de la table d'analyse de
           sécurité. Le format est un tableau JSON avec des objets contenant les champs
           suivants : réglage qui indique si le réglage est activé ou pas, nom qui est ce qui est
           utilisé pour se référer au réglage, champ_json qui est l'identifiant compatible JSON
           du réglage, description qui est un aperçu de l'état du réglage et exposition qui est
           un nombre dans l'intervalle de 0.0...10.0, où une valeur haute correspond à une menace
           de sécurité élevée. La version JSON de la table est affichée dans la sortie standard.
           Le MODE passé à l'option peut être l'un des trois suivants : off la valeur par défaut,
           pretty et short qui renvoient respectivement une version enjolivée ou courte de la
           version JSON de la table de sécurité. Avec la commande plot, générer une sortie
           formatée JSON des données horaires brutes. Le format est un tableau JSON avec des
           objets contenant les champs suivant : nom qui est le nom de l'unité, activated qui est
           le temps mis par le service pour être activé après le démarrage, activating qui est le
           temps mis par le service pour être initialement lancé après le démarrage, time qui est
           le temps mis par le service pour s'activer à partir du moment où il a été démarré
           initialement, desactivated qui est le temps mis par le service pour se désactiver
           après le démarrage, desactivating qui est le temps après lequel il a été initialement
           demandé au service de se désactiver après le démarrage.

           Added in version 250.

       --iterations=NOMBRE
           Lorsqu'utilisée avec la commande calendar, cette option affiche le nombre spécifique
           d'itérations de prochaines échéances de l'expression calendaire indiquée. La valeur
           par défaut est 1.

           Added in version 242.

       --base-time=HORODATAGE
           Lorsqu'utilisée avec la commande calendar, cette option affiche les prochaines
           itérations relatives à un moment indiqué. Si rien n'est spécifié, ce sera l'heure
           actuelle par défaut.

           Added in version 244.

       --unit=UNITÉ
           Lorsqu'utilisée avec la commande condition, cette option permet d'évaluer toutes les
           assignations Condition*=... et Assert*=... dans le fichier de l'unité indiquée. Le
           chemin complet de recherche de l'unité est formé en combinant les répertoires de
           l'unité indiquée avec 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 de chargement des unités ; consulter
           systemd.unit(5). Tous les fichiers d'unités présents dans le répertoire contenant
           l'unité indiquée seront utilisés de préférence aux autres chemins.

           Added in version 250.

       --table
           Lorsqu'utilisée avec la commande plot, la sortie des données horaires brutes s'affiche
           sous la forme d'un tableau.

           Added in version 253.

       --no-legend
           Lorsqu'utilisé avec la commande plot combinée avec soit --table ou --json=, aucune
           légende ou indication ne sont inclues dans la sortie.

           Added in version 253.

       -H, --host=
           Effectuer l'opération à distance. Indiquez un nom d'hôte, ou un nom d'utilisateur et
           un nom d'hôte séparés par un « @ », auquel se connecter. Le nom de l'hôte peut, de
           façon optionnelle, être suffixé par un port sur lequel ssh écoute, séparé par un
           « : », puis le nom d'un conteneur, séparé par un « / », ce qui connecte alors
           directement à un conteneur donné sur l'hôte. Cela utilisera SSH pour dialoguer avec le
           contrôleur de la machine distante. Les noms des conteneurs peuvent être énumérés avec
           machinectl -H HOST. Mettre les adresses IPv6 entre crochets.

       -M, --machine=
           Effectuer l'opération dans un conteneur local. Précisez le nom d'un conteneur auquel
           se connecter, optionnellement préfixé par le nom sous lequel se connecter et un
           caractère de séparation « @ ». Si la chaîne spéciale « .host » est utilisée à la place
           du nom du conteneur, une connexion au système local se produit (ce qui est utile pour
           se connecter à un utilisateur particulier )'s user bus: « --user
           --machine=lennart@.host »). Si la syntaxe « @ » n'est pas utilisée, la connexion est
           réalisée en tant que superutilisateur. Si la syntaxe « @ » est utilisée, le côté
           gauche ou le côté droit peuvent être omis (mais pas les deux à la fois), auquel cas le
           nom de l'utilisateur local et « .host » sont implicites.

       --quiet
           Supprimer les notes et sorties non essentielles.

           Added in version 250.

       --tldr
           With cat-config, only print the "interesting" parts of the configuration files,
           skipping comments and empty lines and section headers followed only by comments and
           empty lines.

           Added in version 255.

       -h, --help
           Afficher un aide-mémoire succinct et quitter.

       --version
           Afficher une information de version courte et quitter.

       --no-pager
           Ne pas rediriger (pipe) la sortie vers un afficheur (pager).

CODE DE RETOUR

       Pour la plupart des commandes, 0 est renvoyé en cas de succès et un code d'échec différent
       de zéro sinon.

       Avec le verbatim compare-versions sous la forme de deux arguments, 12, 0 ou 11 est renvoyé
       si la seconde chaîne de version est respectivement plus grande, égale ou plus petite que
       la première. Sous la forme de trois arguments, 0 ou 1 est renvoyé si la condition est
       respectivement vraie ou fausse.

ENVIRONNEMENT

       $SYSTEMD_LOG_LEVEL
           Le niveau maximal de journalisation des messages émis (les messages avec un niveau de
           journalisation plus élevé, c'est-à-dire les moins importants seront supprimés). Soit
           un de ces niveaux (par ordre d'importance décroissante) emerg, alert, crit, err,
           warning, notice, info, debug ou un entier dans l'intervalle 0...7. Consultez syslog(3)
           pour plus d'informations.

       $SYSTEMD_LOG_COLOR
           Un booléen. Si la valeur est vrai, les messages écrits sur le terminal seront colorés
           selon la priorité.

           Ce réglage est utile uniquement quand les messages sont écrits directement dans un
           terminal ou un fichier parce que journalctl(1) et d'autres outils qui affichent des
           journaux coloreront par eux-mêmes les messages selon le niveau de journalisation.

       $SYSTEMD_LOG_TIME
           Un booléen. Si la valeur est vrai, les messages du journal de la console seront
           préfixés d'un horodatage.

           Ce réglage est utile uniquement quand les messages sont écrits directement dans un
           terminal ou un fichier parce que journalctl(1) et d'autres outils qui affichent des
           journaux attacheront par eux-mêmes un horodatage selon les métadonnées de l'entrée.

       $SYSTEMD_LOG_LOCATION
           Un booléen. Si la valeur est vrai, les messages seront préfixés par un nom de fichier
           et du numéro de ligne du code source d'où vient le message.

           Notez que l'emplacement du journal est souvent attaché comme métadonnée aux entrées du
           journal de toute façon. L'inclure directement dans le texte du message peut néanmoins
           être opportun lors du débogage de programmes.

       $SYSTEMD_LOG_TID
           Un booléen. Si la valeur est vrai, les messages seront préfixés par l'identifiant
           numérique du thread actuel (TID).

           Notez que cette information est attachée comme métadonnée aux entrées du journal de
           toute façon. L'inclure directement dans le texte du message peut néanmoins être
           opportun lors du débogage de programmes.

       $SYSTEMD_LOG_TARGET
           Destination pour journaliser les messages. Une des destinations parmi console
           (journaliser dans le terminal attaché), console-prefixed (journaliser dans le terminal
           attaché, mais avec des préfixes qui codent le niveau et le « service » de
           journalisation, consultez syslog(3)), kmsg (journaliser dans le tampon de
           journalisation circulaire du noyau), journal (journaliser dans le journal),
           journal-or-kmsg (journaliser dans le journal s'il est disponible et sinon dans kmsg),
           auto (déterminer automatiquement la cible appropriée de journalisation , c'est la
           destination par défaut), null (désactive la sortie de journalisation).

       $SYSTEMD_LOG_RATELIMIT_KMSG
           Limiter ou pas le taux de messages kmsg. Prend un booléen. Par défaut « vrai ». Si
           désactivé, systemd ne limitera pas le taux de messages écrits à kmsg.

       $SYSTEMD_PAGER
           Afficheur à utiliser lorsque --no-pager n'est pas précisé ; outrepasse $PAGER. Si ni
           $SYSTEMD_PAGER, ni $PAGER n'ont de valeur, un ensemble d’afficheurs bien connus sont
           essayés à tour de rôle, incluant less(1) et more(1), jusqu'à ce qu'il y en ait un qui
           soit trouvé. Si aucun afficheur n'est trouvé, aucun afficheur n'est appelé. Définir
           cette variable d'environnement à une chaîne vide ou à « cat » est équivalent à
           l'utilisation de --no-pager.

           Remarque : si $SYSTEMD_PAGERSECURE n'est pas défini, $SYSTEMD_PAGER (tout comme
           $PAGER) sera ignoré silencieusement.

       $SYSTEMD_LESS
           Outrepasser les options passées à less (par défaut « FRSXMK »).

           Les utilisateurs voudront peut-être changer deux options en particulier :

           K
               Cette option ordonne à l’afficheur de quitter immédiatement lorsque Ctrl+C est
               entré. Pour permettre à less de gérer Ctrl+C lui-même le retour à l'invite de
               commande de l’afficheur, ne pas fournir cette option.

               Si la valeur de $SYSTEMD_LESS n'inclut pas « K » et si l’afficheur appelé est
               less, Ctrl+C sera ignoré par l'exécutable, et doit être géré par l’afficheur.

           X
               Cette option ordonne à l’afficheur de ne pas envoyer les chaînes d'initialisation
               et de désinitialisation de termcap au terminal. C'est le choix par défaut afin de
               permettre aux sorties des commandes de rester visibles dans le terminal même après
               que l’afficheur soit fermé. Toutefois, cela empêche quelques fonctionnalités de
               l’afficheur de fonctionner, en particulier, il n'est pas possible de faire défiler
               les sorties affichées avec la souris.

           Voir less(1) pour plus de détails.

       $SYSTEMD_LESSCHARSET
           Outrepasser le jeu de caractères passé à less (par défaut « utf-8 », si le terminal
           invoqué est compatible avec l'UTF-8).

       $SYSTEMD_PAGERSECURE
           Prend un argument booléen. Quand c'est « vrai », le mode « secure » de l'afficheur est
           activé et quand c'est « faux », il est désactivé. Si $SYSTEMD_PAGERSECURE n'est pas du
           tout défini, le mode « secure » est activé si l'UID effectif n'est pas le même que
           celle du propriétaire de la session connectée, consulter geteuid(2) et
           sd_pid_get_owner_uid(3). En mode « secure », LESSSECURE=1 sera défini lors de
           l'invocation de l'afficheur, et l'afficheur désactivera les commandes qui ouvrent ou
           créent de nouveaux fichiers ou lancent de nouveaux sous-processus. Quand
           $SYSTEMD_PAGERSECURE n'est pas du tout défini, les afficheurs qui ne sont pas reconnus
           comme implémentant le mode « secure » ne seront pas utilisés. (Actuellement seul
           less(1) implémente le mode « secure ».)

           Note : quand des commandes sont invoquées avec des privilèges élevés, par exemple avec
           sudo(8) ou pkexec(1), des précautions doivent être prises pour s'assurer que des
           fonctions interactives indésirables ne sont pas activées. Le mode « Secure » de
           l'afficheur interactif peut être activé automatiquement comme décrit plus haut.
           Définir SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de l'environnement hérité
           autorise l'utilisateur à invoquer des commandes arbitraires. Notez que si les
           variables $SYSTEMD_PAGER ou $PAGER doivent être respectées, $SYSTEMD_PAGERSECURE doit
           aussi être défini. Il pourrait être raisonnable de désactiver complètement l'afficheur
           interactif en utilisant plutôt --no-pager.

       $SYSTEMD_COLORS
           Prend un argument booléen. Quand c'est « vrai », systemd et les utilitaires liés
           utiliseront la couleur pour leurs sorties, autrement, la sortie sera monochrome. En
           plus, la variable peut prendre une des valeurs spéciales suivantes : 16 ou 256 pour
           limiter l'usage des couleurs aux couleurs ANSI base 16 ou base 256 respectivement.
           Cela peut être précisé pour outrepasser la décision automatique prise sur $TERM et
           quel que soit ce à quoi la console est connectée.

       $SYSTEMD_URLIFY
           La valeur doit être un booléen. Contrôle si les liens cliquables doivent être générés
           dans la sortie pour des émulateurs de terminaux le prenant en charge. Cela peut être
           indiqué pour passer outre la décision faite par systemd basée sur $TERM et d'autres
           conditions.

EXEMPLES

       Exemple 25. Politique JSON

       Le fichier JSON passé comme paramètre de chemin à --security-policy= a un objet JSON de
       haut niveau dont les clés sont les identifiants des tests d'évaluation mentionnés
       ci-dessus. Les valeurs dans le fichier doivent être des objets JSON avec un ou plusieurs
       des champs suivants : description_na (chaîne), description_good (chaîne), description_bad
       (chaîne), weight (entier non signé) et range (entier non signé). Si l'un de ces champs
       correspondant à un identifiant spécifique d'un fichier d'unité est manquant dans l'objet
       JSON, la valeur du champ interne par défaut correspondant à ce même identifiant est
       utilisée comme valeur par défaut pour l'analyse de sécurité. Les champs weight et range
       sont utilisés pour déterminer le niveau d'exposition global des fichiers de l'unité : un
       score de médiocrité est assigné comme valeur à chaque réglage, qui est multiplié par le
       poids de la politique et divisé par la plage de politique pour déterminer l'exposition
       globale que ce réglage implique. Le degré de médiocrité calculé est additionné à tous les
       paramètres du fichier de l'unité, normalisé dans l'intervalle de 1 à 100 et utilisé pour
       déterminer le niveau d'exposition global de l'unité. En autorisant les utilisateurs à
       manipuler ces champs, la commande « security » leur donne le choix de décider eux-mêmes
       quels identifiants sont plus importants et donc susceptibles d'avoir un impact plus grand
       sur le niveau d'exposition. Un poids de 0 signifie que le réglage ne sera pas vérifié.

           {
             "PrivateDevices":
               {
               "description_good": "Service has no access to hardware devices",
               "description_bad": "Service potentially has access to hardware devices",
               "weight": 1000,
               "range": 1
               },
             "PrivateMounts":
               {
               "description_good": "Service cannot install system mounts",
               "description_bad": "Service may install system mounts",
               "weight": 1000,
               "range": 1
               },
             "PrivateNetwork":
               {
               "description_good": "Service has no access to the host's network",
               "description_bad": "Service has access to the host's network",
               "weight": 2500,
               "range": 1
               },
             "PrivateTmp":
               {
               "description_good": "Service has no access to other software's temporary files",
               "description_bad": "Service has access to other software's temporary files",
               "weight": 1000,
               "range": 1
               },
             "PrivateUsers":
               {
               "description_good": "Service does not have access to other users",
               "description_bad": "Service has access to other users",
               "weight": 1000,
               "range": 1
               }
           }

VOIR AUSSI

       systemd(1), systemctl(1)

NOTES

        1. Empaquetage de métadonnées
           https://systemd.io/COREDUMP_PACKAGE_METADATA/

        2. Spécification des partitions détectables
           https://uapi-group.org/specifications/specs/discoverable_partitions_specification

TRADUCTION

       La traduction française de cette page de manuel a été créée par bubu <bubub@no-log.org>

       Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General
       Public License version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à ⟨debian-l10n-french@lists.debian.org⟩.