SYSTEMD-ANALYZE(1) systemd-analyze SYSTEMD-ANALYZE(1) NOM systemd-analyze -- Analyser et deboguer le gestionnaire du systeme SYNOPSIS systemd-analyze [OPTIONS...] [time] systemd-analyze [OPTIONS...] blame systemd-analyze [OPTIONS...] critical-chain [UNITE...] 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 [ETAT...] systemd-analyze [OPTIONS...] capability [CAPACITE...| {-m | --mask} MASQUE] 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 DUREE... systemd-analyze [OPTIONS...] cat-config NOM|CHEMIN... systemd-analyze [OPTIONS...] compare-versions VERSION1 [OP] VERSION2 systemd-analyze [OPTIONS...] verify FICHIER... systemd-analyze [OPTIONS...] security [UNITE...] systemd-analyze [OPTIONS...] inspect-elf FICHIER... systemd-analyze [OPTIONS...] malloc [D-BUS SERVICE...] systemd-analyze [OPTIONS...] fdstore UNITE... systemd-analyze [OPTIONS...] image-policy POLITIQUE... systemd-analyze [OPTIONS...] has-tpm2 systemd-analyze [OPTIONS...] pcrs [PCR...] systemd-analyze [OPTIONS...] srk [>FICHIER] systemd-analyze [OPTIONS...] architectures [NOM...] systemd-analyze [OPTIONS...] smbios11 DESCRIPTION systemd-analyze peut etre utilisee pour determiner les statistiques de performance du demarrage du systeme et recuperer d'autres informations d'etat et de tracage du systeme et du gestionnaire de services, et verifier la justesse des fichiers d'unite. Elle est aussi utilisee pour acceder a des fonctions speciales utiles au debogage avance du gestionnaire du systeme. Si aucune commande n'est passee, systemd-analyze-time est implicite. systemd-analyze time Cette commande affiche le temps ecoule dans le noyau avant que l'espace utilisateur n'ait ete atteint, le temps ecoule dans l'initrd avant que l'espace utilisateur normal du systeme ne soit atteint, et le temps pris par l'espace utilisateur normal du systeme pour s'initialiser. Notez que ces mesures ne font que mesurer le temps ecoule jusqu'au moment ou tous les services du systeme ont ete lances, mais pas necessairement jusqu'a ce qu'ils aient termine leur initialisation ou que le disque soit inactif. Exemple 1. Afficher la duree de l'amorcage (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 unites en service, classees en fonction du temps passe a s'initialiser. Cette information peut etre utilisee pour optimiser les temps d'amorcage. Prenez en compte que la sortie peut etre trompeuse etant donne que l'initialisation d'un service peut apparaitre lente simplement parce qu'il attend l'initialisation d'un autre service pour se finaliser. Notez aussi : systemd-analyze blame n'affiche pas de resultats pour les services avec Type=simple, car systemd considere de tels services comme demarrant immediatement, ce qui fait qu'aucune mesure de delai d'initialisation ne peut etre faite. Notez aussi que cette commande ne montre que le temps pris par les unites pour demarrer, elle ne montre pas combien de temps ont passe les taches de l'unite dans la file d'attente d'executions. Cela montre en particulier le temps que l'unite a passe en etat << actif >>, lequel n'est pas defini pour les unites telles que les unites peripheriques qui effectuent une transition directement d'<< inactive >> a << active >>. Cette commande donne ainsi une impression de la performance du code du programme, mais ne peut refleter avec exactitude la latence introduite par l'attente du materiel et d'evenements similaires. Exemple 2. Afficher quelles unites prennent le plus de temps lors de l'amorcage $ 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 [UNITE...] Cette commande affiche un arbre de la chaine de temps critique d'unites (pour chacune des UNITEs indiquees ou pour la cible par defaut sinon). Le temps ecoule pour que l'unite soit active ou demarree est affiche apres le caractere << @ >>. Le temps pris par l'unite pour demarrer est affiche apres le caractere << + >>. Notez que la sortie peut etre inexacte dans la mesure ou l'initialisation de services pourrait dependre de l'activation d'un socket et a cause de l'execution en parallele d'unites. Aussi, a l'instar de la commande blame, cette commande ne prend en compte que le temps passe par les unites en etat d'<< activation >>, et donc ne couvre pas les unites qui ne sont jamais passees par un etat d'<< activation >> (telles les unites de peripheriques d'unite qui passent directement de l'etat << inactif >> a << actif >>). En outre, elle ne montre pas d'information sur les taches (et en particulier sur les taches achevees). 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 parametre, cette commande renvoie une serialisation lisible (habituellement tres longue) de l'etat complet du gestionnaire de services. Un motif global (glob) facultatif peut etre specifie, limitant la sortie aux unites dont les noms correspondent a l'un des motifs. Le format de sortie est susceptible d'etre modifie sans preavis et ne devrait pas etre soumis a l'analyse par des applications. Cette commande a un debit limite pour les utilisateurs non privilegies. Exemple 4. Afficher l'etat 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 etre utilisee pour demander la sortie de l'etat de la memoire interne (comme renvoye par malloc_info(3)) d'un service D-Bus. Si aucun service n'est indique, la demande sera envoyee a org.freedesktop.systemd1 (le gestionnaire de services systeme ou utilisateur). La stabilite du format de sortie n'est pas garantie et ne devrait pas etre analyse par les applications. Le service doit implementer l'interface org.freedesktop.MemoryAllocation1. Dans la suite systemd, elle est actuellement implementee seulement par le gestionnaire. systemd-analyze plot Cette commande affiche un graphique SVG detaillant quels services du systeme ont demarre a quel moment, mettant en evidence le temps passe a leur initialisation, ou les donnees horaires brutes en format JSON ou tableau. Exemple 5. Tracer un graphique d'amorcage $ systemd-analyze plot >bootup.svg $ eog bootup.svg& Il convient de noter que ce graphique est base sur les donnees les plus recentes relatives a la synchronisation des unites chargees. Cela signifie que si une unite demarre, est stoppee et redemarre encore, les informations affichees ne couvriront que le cycle de demarrage le plus recent, pas le premier. Par consequent, il est conseille de consulter ces informations peu de temps apres l'amorcage, pour que cette distinction importe peu. En outre, les unites qui ne sont referencees par aucune autre unite par le biais d'une dependance peuvent etre dechargees par le gestionnaire de service une fois qu'elles se terminent (et qu'elles n'ont pas echoue). Ces unites n'apparaitront pas dans le graphique. systemd-analyze dot [motif...] Cette commande genere une description textuelle du graphe de dependances au format dot pour un traitement ulterieur avec l'outil GraphViz dot(1). Utilisez une ligne de commande telle que systemd-analyze dot | dot -Tsvg >systemd.svg pour generer un arbre de dependances graphique. A moins que --order ou --require ne soit passees, le graphe obtenu montrera a la fois les dependances d'ordre et d'exigence. Le motif optionnel de specifications de style globbing (par exemple *.cible) peut etre donne a la fin. Une dependance d'unite n'est inclue dans le graphe que si l'un des motifs correspond a la fois au noeud d'origine ou de destination. Exemple 6. Tracer toutes les dependances des unites dont le nom commence avec << avahi-daemon >> $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg $ eog avahi.svg Exemple 7. Tracer les dependances entre toutes les unites 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 repertoires desquels les fichiers d'unite, .d overrides, et les liens symboliques .wants, .requires doivent etre charges. A 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 unites generees $ 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 compilee a l'interieur de systemd-analyze et ne communique pas avec le gestionnaire en cours d'execution. Utilisez systemctl [--user] [--global] show -p UnitPath --value pour retrouver la liste reellement utilisee par le gestionnaire, avec tout repertoire vide omis. systemd-analyze exit-status [ETAT...] Cette commande affiche une liste des codes de retour avec leur << classe >>, c'est-a-dire la source de la definition (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 indique, tous les etats connus sont affiches. Sinon, seules les definitions pour les codes indiques sont affichees. Exemple 9. Afficher quelques exemples de noms d'etat 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 [CAPACITE... | {-m | --mask} MASQUE] Cette commande affiche une liste des capacites (capabilities) de Linux avec leur identifiant numerique. Consulter capabilities(7) pour les details. Si aucun argument n'est indique, la liste entiere des capacites connues du gestionnaire de services et du noyau est affichee. Les capacites definies par le noyau, mais inconnues du gestionnaire de services sont affichees en tant que << cap_??? >>. En option, si des arguments sont specifies, ils doivent se referer aux capacites specifiees par leur nom ou identifiant numerique, auquel cas seules les capacites indiquees sont montrees dans la table. De facon alternative, si --mask est passe, un argument numerique unique doit etre indique, qui est interprete comme un masque de capacites hexadecimal. Dans ce cas, seules les capacites presentes dans le masque sont affichees dans la table. Ce mode est concu pour aider a decoder les reglages de capacites disponibles avec diverses interfaces de debogage (par exemple << /proc/PID/status >>). Exemple 10. Afficher quelques exemples de noms de capacite $ 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 Exemple 11. Decoder un masque de capacites extrait de /proc $ systemd-analyze capability -m 0000000000003c00 NAME NUMBER cap_net_bind_service 10 cap_net_broadcast 11 cap_net_admin 12 cap_net_raw 13 systemd-analyze condition CONDITION... Cette commande evaluera les affectations Condition*=... et Assert*=... et affichera leurs valeurs et la valeur resultante de l'ensemble de conditions jointes. Consulter systemd.unit(5) pour une liste des conditions disponibles et assertions. Exemple 12. Evaluer les conditions qui verifient 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 systeme contenus dans l'ensemble des appels systeme indique ENSEMBLE, ou tout ensemble si aucun ensemble n'est specifie. L'argument ENSEMBLE doit inclure le prefixe << @ >>. systemd-analyze filesystems [ENSEMBLE...] Cette commande listera les systemes de fichiers dans l'ensemble de systemes de fichiers indique ENSEMBLE, ou tout ensemble connu si aucun ensemble n'est specifie. L'argument ENSEMBLE doit inclure le prefixe << @ >>. systemd-analyze calendar EXPRESSION... Cette commande va analyser et normaliser les evenements calendaires repetitifs et calculera la prochaine echeance. Elle prend la meme entree que le OnCalendar= defini dans systemd.timer(5), en suivant la syntaxe decrite dans systemd.time(7). Seule la prochaine echeance de l'expression moment calendaire a survenir est montree par defaut : utiliser -- iterations= pour afficher le nombre de fois indique des prochaines echeances ou l'expression se produira. Chaque moment ou l'expression se deroule forme un horodatage, voir le verbatim timestamp ci-dessous. Exemple 13. 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-a-dire un simple point dans le temps) et renvoie la forme normalisee et la difference entre cet horodatage et maintenant. L'horodatage doit se conformer a la syntaxe documentee dans systemd.time(7), section << PARSING TIMESTAMPS >> (analyse des horodatages). Exemple 14. 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-a-dire la difference entre deux horodatages) et renvoie la forme normalisee et la valeur equivalente en microsecondes. La duree doit se conformer a la syntaxe documentee dans systemd.time(7), section << PARSING TIME SPANS >> (analyse de durees). Les valeurs sans unite sont analysees comme etant des secondes. Exemple 15. Afficher l'analyse des durees $ 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 a systemctl cat, mais opere 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 repertoires et des regles de priorite habituel de systemd. Chaque argument doit etre soit un chemin absolu incluant le prefixe (tel que /etc/systemd/logind.conf ou /usr/lib/systemd/logind.conf) ou un nom relatif au prefixe (tel que systemd/logind.conf). Exemple 16. 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 derogation d'un autre paquet # /etc/systemd/logind.conf.d/50-override.conf ... quelque derogation d'un administrateur systemd-analyze compare-versions VERSION1 [OP] VERSION2 Cette commande a deux modes operatoires distincts, selon que l'operateur OP est specifie ou non. Dans le premier mode -- lorsque OP n'est pas indique --, cette commande comparera les deux chaines de version et affichera soit << VERSION1 < VERSION2 >>, ou << VERSION1 == VERSION2 >>, ou << VERSION1 > VERSION2 >> en fonction du resultat. 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 a la convention utilisee par rpmdev-vercmp). Dans le second mode (lorsque OP est indique), cette commande comparera les deux chaines de version en utilisant l'operation OP et renverra 0 (succes) si les conditions sont satisfaites, et 1 (echec) sinon . OP peut etre it, te, eq, ne, ge, gt. Dans ce mode, aucun retour n'est affiche (cela correspond a la convention utilisee par dpkg(1) --compare-versions). Exemple 17. 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'unite et affichera des avertissements si des erreurs sont detectees. Les fichiers indiques sur la ligne de commande seront charges, mais aussi toute autre unite referencee par eux. Un nom d'unite sur disque peut etre remplace en specifiant un alias apres un << deux-points >> ; voir ci-dessous pour un exemple. Le chemin de recherche complet de l'unite est forme en combinant les repertoires de tous les arguments de la ligne de commande et les chemins habituels de chargement des unites. La variable $SYSTEMD_UNIT_PATH est prise en charge et peut etre utilisee pour remplacer ou augmenter l'ensemble compile des chemins des unites chargees ; consulter systemd.unit(5). Tous les fichiers presents dans les repertoires contenant les arguments de ligne de commande seront utilises en preference aux autres chemins. Si une unite modele n'a pas de nom d'instance indique (par exemple truc@.service), << test_instance >> sera utilise comme nom d'instance, ce dernier pouvant etre controle par l'option --instance=. Les erreurs suivantes sont souvent detectees : o instructions et sections inconnues ; o dependances necessaires au demarrage de l'unite donnee manquantes ; o pages de manuel listees dans Documentation= qui sont introuvables dans le systeme ; o commandes listees dans ExecStart= et similaires qui sont introuvables dans le systeme ou non executables. Exemple 18. Directives mal ecrites $ 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 19. Unites 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 20. Faire un alias d'une unite $ 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 [UNITE...] Cette commande analyse la securite et l'ensemble des bacs a sable pour une ou plusieurs unites de service. Si au moins un nom d'unite est specifie, les reglages des unites du service specifiees sont inspectes et une analyse detaillee est affichee. Si aucun nom d'unite n'est specifie, toutes les unites de service chargees et en fonctionnement sont inspectees et un tableau succinct des resultats est affiche. La commande verifie differents reglages relatifs a la securite du service, assignant a chacun une valeur de << niveau d'exposition >>, en fonction de l'importance du reglage. Elle calcule ensuite un niveau d'exposition global pour l'ensemble de l'unite, qui est une estimation dans l'intervalle de 0.0...10.0 indiquant le degre d'exposition d'un service en matiere de securite. Des degres d'exposition eleves indiquent un << bac a sable >> tres peu applique. Les faibles niveaux d'exposition indiquent une application du bac a sable serree et des restrictions de securite tres strictes. Notez que cette commande n'analyse que les fonctionnalites de securite par service que systemd lui-meme met en oeuvre. Cela signifie que tout mecanisme de securite supplementaire applique par le code du service lui-meme n'est pas pris en compte. Le niveau d'exposition determine de cette maniere ne doit pas etre mal compris : un haut niveau d'exposition ne signifie pas qu'il n'y a pas de bac a sable effectif applique par le code du service lui-meme, ni que le service est reellement vulnerable a des attaques a distance ou locales. De hauts niveaux d'exposition indiquent que le service pourrait beneficier de reglages supplementaires. Veuillez prendre en compte que la plupart des reglages individuels pour le bac a sable ou la securite peuvent etre contournes -- a moins d'etre combines avec d'autres. Par exemple, si un service conserve le privilege d'etablir ou de demonter des points de montage, beaucoup des options du bac a sable peuvent etre defaites par le code du service lui-meme. C'est pour cela qu'il est essentiel que chaque service use de reglages de bac a sable et de securite les plus exhaustifs et stricts possibles. L'outil prendra en compte quelques-unes de ces combinaisons et relations entre les reglages, mais pas toutes. Remarquez aussi que les reglages de bac a sable et de securite analyses ici ne concernent que les operations faites par le code du service lui-meme. Si un service a acces a un systeme IPC (tel que D-Bus), il pourrait necessiter des operations de la part d'autres services qui ne sont pas astreints aux memes restrictions. Toute analyse exhaustive de bac a sable et de securite est donc incomplete si la politique d'acces IPC n'est pas aussi validee. Exemple 21. 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 specifies et, s'ils sont des objets ELF (executables, bibliotheques, fichier core, etc.), elle analysera les metadonnees d'empaquetage incorporees, si presentes et les affichera dans une table ou au format json. Voir la documentation Packaging Metadata[1] pour plus d'information. Exemple 22. 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 UNITE... Cette commande liste les contenus actuels du magasin de descripteurs de fichier de l'unite de service specifiee et affiche les noms, les types d'inoeud, les numeros de peripherique, les numeros d'inoeud, les chemins et les modes d'ouverture des descripteurs de fichier ouverts. Les unites indiquees doivent avoir FileDescriptorStoreMax= active ; consultez systemd.service(5) pour les details. Exemple 23. 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 >> designe les numeros majeur/mineur du noeud du peripherique associe au systeme de fichiers dans lequel se trouve le noeud du descripteur de fichier. La colonne << RDEVNO >> designe les numeros majeur/mineur du noeud du peripherique lui-meme, si le descripteur de fichier s'y refere. Comparer avec les champs correspondants a .st_dev et .st_rdev dans struct stat (voir stat(2) pour les details). Les numeros d'inoeuds de la colonne << INODE >> sont sur le systeme de fichiers indique par << DEVNO >>. systemd-analyze image-policy POLITIQUE... Cette commande analyse la chaine de politique de l'image indiquee, comme pour systemd.image-policy(7). Cette politique est normalisee et simplifiee. Pour chaque identifiant de partition defini actuellement (comme pour la Specification des Partitions Detectables[2]) l'effet de la chaine de politique de l'image est affiche sous la forme de tableau. Exemple 24. 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 has-tpm2 Indique si le systeme est equipe d'un peripherique TPM2 utilisable. Si un peripherique TPM2 a ete decouvert, qu'il est pris en charge et utilise par le micrologiciel, par les pilotes du noyau du systeme d'exploitation et par l'espace utilisateur (c'est-a-dire systemd), cette commande affiche << yes >> et quitte avec un code de retour de zero. Si aucun peripherique n'est decouvert/pris en charge/utilise, << no >> s'affiche. Sinon, << partial >> est affiche. Dans les deux cas, la sortie est un code retour different de zero. Cette commande montre aussi cinq lignes indiquant separement si le micrologiciel, les pilotes, le systeme, le noyau et les bibliotheques ont decouvert/gere/utilise TPM2. Actuellement, les bibliotheques requises sont libtss2-esys.so.0, libtss2-rc.so.0 et libtss2-mu.so.0. Ces prerequis pourront changer dans le futur. Notez que cela ne verifie que les peripheriques TPM 2.0, et ignore totalement les peripheriques TPM 1.2. Combiner avec --quiet pour supprimer la sortie. Exemple 25. Exemple de sortie yes +firmware +driver +system +subsystem +libraries +libtss2-esys.so.0 +libtss2-rc.so.0 +libtss2-mu.so.0 Ajoute dans la version 257. systemd-analyze pcrs [PCR...] Cette commande affiche les PCR TPM2 connus avec leurs noms d'identification et leurs valeurs actuelles. Exemple 26. 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 cle racine de stockage (SRK) du dispositif TPM2 et l'ecrit au format TPM2B_PUBLIC serialisee sur la sortie. La sortie est une donnee non imprimable, et devrait donc etre redirigee dans un fichier ou un tube. Exemple 27. Sauvegarder la clef racine de stockage (Storage Root Key) dans srk.tpm2b_public systemd-analyze srk >srk.tpm2b_public systemd-analyze architectures [NOM...] Lister toutes les architectures connues de CPU et lesquelles sont natives. Les noms d'architectures listees sont ceux pris en charge par ConditionArchitecture=, voir systemd.unit(5) pour les details. Si des noms d'architectures sont specifies, seuls ceux indiques sont listes. Exemple 28. Sortie sous forme de table $ systemd-analyze architectures NAME SUPPORT alpha foreign arc foreign arc-be foreign arm foreign arm64 foreign ... sparc foreign sparc64 foreign tilegx foreign x86 secondary x86-64 native systemd-analyze smbios11 Afficher une liste des chaines SMBIOS Type #11 passees au systeme. Consultez aussi smbios-type-11(7). Exemple 29. Exemple de sortie $ systemd-analyze smbios11 io.systemd.stub.kernel-cmdline-extra=console=ttyS0 io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSURGd20xbFp4WlRGclJteG9ZQlozOTYzcE1uYlJCaDMwM1MxVXhLSUM2NmYgbGVubmFydEB6ZXRhCg== io.systemd.credential:vmm.notify_socket=vsock-stream:2:254570042 3 SMBIOS Type #11 strings passed. Ajoute dans la version 257. OPTIONS Les options suivantes sont comprises : --system Agir sur l'instance systemd du systeme. C'est l'option implicite par defaut. Ajoute dans la version 206. --user Agir sur l'instance systemd de l'utilisateur. Ajoute dans la version 186. --global Agir sur la configuration de l'ensemble du systeme pour l'instance systemd de l'utilisateur. Ajoute dans la version 238. --order, --require Ces options selectionnent quelles dependances seront montrees dans le graphe de dependances, lorsqu'utilisees conjointement a la commande dot (voir ci-dessus). Si --order est passee, seules les dependances du type After= ou Before= sont affichees. Si --require est passee, seules les dependances du type Requires=, Requisite=, BindsTo=, Wants= et Conflicts= sont affichees. Si aucune n'est passee, les dependances de tous ces types seront affichees. Ajoute dans la version 198. --from-pattern=, --to-pattern= Ces options selectionnent quelles relations sont montrees dans le graphe de dependances lorsqu'utilisees avec la commande dot (voir ci-dessus). Les deux options necessitent un motif glob(7) comme argument qui sera compare au cote droit et au cote gauche, respectivement, des noeuds de la relation. Chacune d'elles peut etre utilisee plus d'une fois, auquel cas le nom de l'unite doit correspondre a l'une de ces valeurs. Une relation doit passer les deux tests pour etre affichee lorsque les tests pour les deux cotes de la relation sont presents. Quand les motifs sont aussi specifies comme argument de position, ils doivent correspondre a minima a l'un des cotes de la relation. En d'autres termes, les motifs indiques dans ces deux options reduiront la liste des extremites correspondant aux arguments de position, s'il y en a de donnes, et determineront totalement la liste des extremites qui seront affichees sinon. Ajoute dans la version 201. --fuzz=duree Lorsqu'utilisee conjointement avec la commande critical-chain (voir ci-dessus), cette option montrera aussi les unites qui ont fini leur duree avant la derniere unite sur le meme niveau. L'unite de la duree est la seconde, a moins qu'une unite differente soit specifiee, par exemple << 50ms >>. Ajoute dans la version 203. --man=no Ne pas invoquer man(1) pour verifier la presence de pages de manuel listees dans Documentation=. Ajoute dans la version 235. --generators Invoquer les generateurs d'unites, consulter systemd.generator(7). Certains generateurs necessitent les privileges du superutilisateur. Fonctionner avec les generateurs actives en tant qu'utilisateur normal resultera en general en plusieurs avertissements. Ajoute dans la version 235. --instance=NOM Indiquer un nom d'instance de secours pour les unites modele. A utiliser lorsqu'une ou plusieurs unites modele sans nom d'instance (par exemple truc@.service) sont indiquees par systemd-analyze condition avec --unit=, systemd-analyze security et systemd-analyze verify. Si non indique, << test_instance >> sera utilise. Ajoute dans la version 257. --recursive-errors=MODE Controler la verification des unites et leurs dependances et si systemd-analyze verify finit avec un code de retour different de zero ou pas. Avec yes, renvoyer un code de retour de processus different de zero lorsque des avertissements surviennent pendant la verification de l'unite specifiee ou de l'une de ses dependances associees. Avec no, renvoyer un code de retour de processus different de zero lorsque des avertissements surviennent durant la verification de l'unite specifiee uniquement. Avec one, renvoyer un code de retour de processus different de zero lorsque des avertissements surviennent lors de la verification de l'unite indiquee ou de ses dependances immediates. Si cette option n'est pas specifiee, zero est renvoye comme code de retour, que des avertissements surviennent ou pas lors de la verification. Ajoute dans la version 250. --root=CHEMIN Avec cat-config, verify, condition et security lorsqu'utilises avec --offline=, operer sur les fichiers sous le chemin racine specifie CHEMIN. Ajoute dans la version 239. --image=CHEMIN Avec cat-config, verify, condition et security lorsqu'utilises avec --offline=, operer sur les fichiers dans le chemin d'image specifie CHEMIN. Ajoute dans la version 250. --image-policy=politique Cette option prend pour argument une image de chaine de politique, comme pour systemd.image-policy(7). La politique est imposee lors d'une operation sur l'image disque indiquee par --image=, voir ci-dessus. C'est par defaut la politique << * >> si rien n'est indique, c'est-a-dire tous les systemes de fichiers reconnus de l'image sont utilises. --offline=BOOL Avec security, effectuer un audit de securite hors-ligne des fichiers d'unite specifies, c'est-a-dire ne pas dependre du PID 1 pour avoir des informations de securite sur les fichiers de la meme facon que la commande security lorsqu'utilisee seule. Cela signifie que --offline= peut etre utilisee aussi bien avec --root= qu'avec --image=. Si le niveau d'exposition global d'une unite est plus eleve que ce qui est defini par --threshold= (dont la valeur par defaut est 100), --offline= enverra une erreur. Ajoute dans la version 250. --profile=CHEMIN Avec security --offline=, prend en consideration le profil portable indique lors de l'accession aux reglages de l'unite. Le profil peut etre passe sous la forme d'un nom, auquel cas son emplacement connu sur le systeme sera cherche, ou il peut etre un chemin complet vers un fichier de remplacement specifique. Ajoute dans la version 250. --threshold=NOMBRE Avec security, autorise l'utilisateur a definir une valeur personnalisee a comparer au niveau d'exposition global pour les fichiers d'unite indiques. Si le niveau d'exposition global d'une unite est superieur a ce qui a ete defini par l'utilisateur, security renverra une erreur. --threshold= peut aussi etre utilise avec --offline= et sa valeur par defaut est 100. Ajoute dans la version 250. --security-policy=CHEMIN Avec security, permettre a l'utilisateur de definir un ensemble personnalise d'exigences formatees comme un fichier JSON auquel comparer le(s) fichier(s) d'unite specifie(s) et determiner leur niveau d'exposition global aux menaces de securite. Table 1. Identificateurs de test d'evaluation acceptes +---------------------------------------------------------+ |Identificateurs de test d'evaluation | +---------------------------------------------------------+ |UserOrDynamicUser | +---------------------------------------------------------+ |SupplementaryGroups | +---------------------------------------------------------+ |PrivateMounts | +---------------------------------------------------------+ |PrivateDevices | +---------------------------------------------------------+ |PrivateTmp | +---------------------------------------------------------+ |PrivateNetwork | +---------------------------------------------------------+ |PrivateUsers | +---------------------------------------------------------+ |ProtectControlGroups | +---------------------------------------------------------+ |ProtectKernelModules | +---------------------------------------------------------+ |ProtectKernelTunables | +---------------------------------------------------------+ |ProtectKernelLogs | +---------------------------------------------------------+ |ProtectClock | +---------------------------------------------------------+ |ProtectHome | +---------------------------------------------------------+ |ProtectHostname | +---------------------------------------------------------+ |ProtectSystem | +---------------------------------------------------------+ |RootDirectoryOrRootImage | +---------------------------------------------------------+ |LockPersonality | +---------------------------------------------------------+ |MemoryDenyWriteExecute | +---------------------------------------------------------+ |NoNewPrivileges | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_ADMIN | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SET_UID_GID_PCAP | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_PTRACE | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_TIME | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_NET_ADMIN | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_RAWIO | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_MODULE | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_AUDIT | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYSLOG | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_NICE_RESOURCE | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_MKNOD | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_CHOWN_FSETID_SETFCAP | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_DAC_FOWNER_IPC_OWNER | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_KILL | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_NET_BIND_SERVICE_BROADCAST_RAW | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_BOOT | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_MAC | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_LINUX_IMMUTABLE | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_IPC_LOCK | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_CHROOT | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_BLOCK_SUSPEND | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_WAKE_ALARM | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_LEASE | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_SYS_TTY_CONFIG | +---------------------------------------------------------+ |CapabilityBoundingSet_CAP_BPF | +---------------------------------------------------------+ |UMask | +---------------------------------------------------------+ |KeyringMode | +---------------------------------------------------------+ |ProtectProc | +---------------------------------------------------------+ |ProcSubset | +---------------------------------------------------------+ |NotifyAccess | +---------------------------------------------------------+ |RemoveIPC | +---------------------------------------------------------+ |Delegate | +---------------------------------------------------------+ |RestrictRealtime | +---------------------------------------------------------+ |RestrictSUIDSGID | +---------------------------------------------------------+ |RestrictNamespaces_user | +---------------------------------------------------------+ |RestrictNamespaces_mnt | +---------------------------------------------------------+ |RestrictNamespaces_ipc | +---------------------------------------------------------+ |RestrictNamespaces_pid | +---------------------------------------------------------+ |RestrictNamespaces_cgroup | +---------------------------------------------------------+ |RestrictNamespaces_uts | +---------------------------------------------------------+ |RestrictNamespaces_net | +---------------------------------------------------------+ |RestrictAddressFamilies_AF_INET_INET6 | +---------------------------------------------------------+ |RestrictAddressFamilies_AF_UNIX | +---------------------------------------------------------+ |RestrictAddressFamilies_AF_NETLINK | +---------------------------------------------------------+ |RestrictAddressFamilies_AF_PACKET | +---------------------------------------------------------+ |RestrictAddressFamilies_OTHER | +---------------------------------------------------------+ |SystemCallArchitectures | +---------------------------------------------------------+ |SystemCallFilter_swap | +---------------------------------------------------------+ |SystemCallFilter_obsolete | +---------------------------------------------------------+ |SystemCallFilter_clock | +---------------------------------------------------------+ |SystemCallFilter_cpu_emulation | +---------------------------------------------------------+ |SystemCallFilter_debug | +---------------------------------------------------------+ |SystemCallFilter_mount | +---------------------------------------------------------+ |SystemCallFilter_module | +---------------------------------------------------------+ |SystemCallFilter_raw_io | +---------------------------------------------------------+ |SystemCallFilter_reboot | +---------------------------------------------------------+ |SystemCallFilter_privileged | +---------------------------------------------------------+ |SystemCallFilter_resources | +---------------------------------------------------------+ |IPAddressDeny | +---------------------------------------------------------+ |DeviceAllow | +---------------------------------------------------------+ |AmbientCapabilities | +---------------------------------------------------------+ Voir l'exemple << JSON Policy >> ci-dessous. Ajoute dans la version 250. --json=MODE Avec la commande security, generer une sortie formatee JSON de la table d'analyse de securite. Le format est un tableau JSON avec des objets contenant les champs suivants : reglage qui indique si le reglage est active ou pas, nom qui est ce qui est utilise pour se referer au reglage, champ_json qui est l'identifiant compatible JSON du reglage, description qui est un apercu de l'etat du reglage et exposition qui est un nombre dans l'intervalle de 0.0...10.0, ou une valeur haute correspond a une menace de securite elevee. La version JSON de la table est affichee dans la sortie standard. Le MODE passe a l'option peut etre l'un des trois suivants : off la valeur par defaut, pretty et short qui renvoient respectivement une version enjolivee ou courte de la version JSON de la table de securite. Avec la commande plot, generer une sortie formatee JSON des donnees horaires brutes. Le format est un tableau JSON avec des objets contenant les champs suivant : nom qui est le nom de l'unite, activated qui est le temps mis par le service pour etre active apres le demarrage, activating qui est le temps mis par le service pour etre initialement lance apres le demarrage, time qui est le temps mis par le service pour s'activer a partir du moment ou il a ete demarre initialement, desactivated qui est le temps mis par le service pour se desactiver apres le demarrage, desactivating qui est le temps apres lequel il a ete initialement demande au service de se desactiver apres le demarrage. Ajoute dans la version 250. --iterations=NOMBRE Lorsqu'utilisee avec la commande calendar, cette option affiche le nombre specifique d'iterations de prochaines echeances de l'expression calendaire indiquee. La valeur par defaut est 1. Ajoute dans la version 242. --base-time=HORODATAGE Lorsqu'utilisee avec la commande calendar, cette option affiche les prochaines iterations relatives a un moment indique. Si rien n'est specifie, ce sera l'heure actuelle par defaut. Ajoute dans la version 244. --unit=UNITE Lorsqu'utilisee avec la commande condition, cette option permet d'evaluer toutes les assignations Condition*=... et Assert*=... dans le fichier de l'unite indiquee. Le chemin complet de recherche de l'unite est forme en combinant les repertoires de l'unite indiquee avec les chemins habituels de chargement des unites. La variable $SYSTEMD_UNIT_PATH est prise en charge et peut etre utilisee pour remplacer ou augmenter l'ensemble compile des chemins de chargement des unites ; consulter systemd.unit(5). Tous les fichiers d'unites presents dans le repertoire contenant l'unite indiquee seront utilises de preference aux autres chemins. Si une unite modele sans nom d'instance est indiquee (par exemple truc@.service), << test_instance >> sera utilise comme nom d'instance, ce dernier pouvant etre controle par l'option --instance=. Ajoute dans la version 250. --table Lorsqu'utilisee avec la commande plot, la sortie des donnees horaires brutes s'affiche sous la forme d'un tableau. Ajoute dans la version 253. --no-legend Lorsqu'utilise avec la commande plot combinee avec soit --table ou --json=, aucune legende ou indication ne sont inclues dans la sortie. Ajoute dans la version 253. -H, --host= Effectuer l'operation a distance. Indiquer un nom d'hote, ou un nom d'utilisateur et un nom d'hote separes par un << @ >>, auquel se connecter. Le nom d'hote peut, de facon optionnelle, etre suffixe par un port sur lequel ssh ecoute, separe par un << : >>, puis le nom d'un conteneur, separe par un << / >>, ce qui connecte alors directement a un conteneur donne sur l'hote specifie. SSH sera utilise pour dialoguer avec l'instance du gestionnaire de la machine distante. Les noms de conteneur peuvent etre enumeres avec machinectl -H HOTE. Mettre les adresses IPv6 entre crochets. -M, --machine= Effectuer l'operation dans un conteneur local. Preciser le nom d'un conteneur auquel se connecter, optionnellement prefixe par le nom d'utilisateur sous lequel se connecter et un caractere de separation << @ >>. Si la chaine speciale << .host >> est utilisee a la place du nom du conteneur, une connexion au systeme local est effectuee (ce qui est utile pour se connecter au bus utilisateur d'un utilisateur particulier : << --user --machine=lennart@.host >>). Si la syntaxe << @ >> n'est pas utilisee, la connexion est realisee en tant que superutilisateur. Si la syntaxe << @ >> est utilisee, le cote gauche ou le cote droit peuvent etre omis (mais pas les deux a la fois), auquel cas le nom de l'utilisateur local et << .host >> sont implicites. -q, --quiet Supprimer les notes et sorties non essentielles. Ajoute dans la version 250. --tldr Avec cat-config, n'afficher que les parties << interessantes >> des fichiers de configuration, sauter les commentaires et les lignes vides ainsi que les en-tetes de section suivis uniquement de commentaires et de lignes vides. Ajoute dans la version 255. --scale-svg=FACTEUR Lorsque utilisee avec la commande plot, l'axe des x du trace peut etre etire par FACTEUR (par defaut : 1.0). Ajoute dans la version 257. --detailed Lorsque utilisee avec la commande plot, les details des horodatages d'activation peuvent etre observes dans le trace SVG. Ajoute dans la version 257. -h, --help Afficher un aide-memoire 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 For most verbs, 0 is returned on success, and a non-zero failure code otherwise. For the verb compare-versions, in the two-argument form, 12, 0, or 11 are returned if the second version string is respectively larger than, equal to, or smaller than the first. In the three-argument form, 0 or 1 are returned when the condition is respectively true or false. For the verb has-tpm2, 0 is returned if a TPM2 device is discovered, supported, and used by firmware, driver, and userspace (i.e. systemd). Otherwise, the OR combination of the value 1 (in case firmware support is missing), 2 (in case driver support is missing), and 4 (in case userspace support is missing). If no TPM2 support is available at all, value 7 is hence returned. ENVIRONNEMENT $SYSTEMD_LOG_LEVEL Le niveau maximal de journalisation de messages emis (messages avec un niveau de journalisation superieur, c'est-a-dire les moins importants seront supprimes). Cette variable prend une liste de valeurs separees par des virgules. Une valeur peut etre (par ordre d'importance decroissante) emerg, alert, crit, err, warning, notice, info, debug ou un entier dans l'intervalle 0...7. Consultez syslog(3) pour davantage d'informations. Chaque valeur peut etre optionnellement prefixee avec console, syslog, kmsg ou journal suivi d'un deux-points (:) pour definir le niveau de journalisation maximal pour la cible specifique de journal (par exemple SYSTEMD_LOG_LEVEL=debug,console:info indique de journaliser au niveau debug excepte pour la journalisation vers la console qui doit s'effectuer au niveau info). Notez que le niveau maximal de journalisation globale est prioritaire sur tout niveau maximal de journalisation par cible. $SYSTEMD_LOG_COLOR Un booleen. Si la valeur est vrai, les messages ecrits sur le terminal seront colores selon la priorite. Ce reglage est utile uniquement quand les messages sont ecrits directement dans un terminal ou un fichier parce que journalctl(1) et d'autres outils qui affichent des journaux coloreront par eux-memes les messages selon le niveau de journalisation. $SYSTEMD_LOG_TIME Un booleen. Si la valeur est vrai, les messages du journal de la console seront prefixes d'un horodatage. Ce reglage est utile uniquement quand les messages sont ecrits directement dans un terminal ou un fichier parce que journalctl(1) et d'autres outils qui affichent des journaux attacheront par eux-memes un horodatage selon les metadonnees de l'entree. $SYSTEMD_LOG_LOCATION Un booleen. Si la valeur est vrai, les messages seront prefixes par un nom de fichier et du numero de ligne du code source d'ou vient le message. Notez que l'emplacement du journal est souvent attache comme metadonnee aux entrees du journal de toute facon. L'inclure directement dans le texte du message peut neanmoins etre opportun lors du debogage de programmes. $SYSTEMD_LOG_TID Un booleen. Si la valeur est vrai, les messages seront prefixes par l'identifiant numerique du thread actuel (TID). Notez que cette information est attachee comme metadonnee aux entrees du journal de toute facon. L'inclure directement dans le texte du message peut neanmoins etre opportun lors du debogage de programmes. $SYSTEMD_LOG_TARGET Destination pour journaliser les messages. Une des destinations parmi console (journaliser dans le terminal attache), console-prefixed (journaliser dans le terminal attache, mais avec des prefixes 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 (determiner automatiquement la cible appropriee de journalisation, c'est la destination par defaut), null (desactive la sortie de journalisation). $SYSTEMD_LOG_RATELIMIT_KMSG Que ce soit pour le taux de requete kmsg ou pas. Prend un booleen. Par defaut << true >>. Si desactive, systemd ne limitera pas le taux des messages ecrits a kmsg. $SYSTEMD_PAGER, $PAGER Afficheur a utiliser lorsque --no-pager n'est pas precise. $SYSTEMD_PAGER est utilise s'il est defini ; autrement, $PAGERest utilise. Si ni $SYSTEMD_PAGER, ni $PAGER n'ont de valeur, un ensemble d'afficheurs bien connus sont essayes a tour de role, incluant less(1) et more(1), jusqu'a ce qu'il y en ait un qui soit trouve. Si aucun afficheur n'est trouve, aucun afficheur n'est appele. Definir ces variables d'environnement a une chaine vide ou a << cat >> est equivalent a l'utilisation de --no-pager. Remarque : si $SYSTEMD_PAGERSECURE n'est pas defini, $SYSTEMD_PAGER et $PAGER ne peuvent etre utilises que pour desactiver l'afficheur (avec << cat >> ou << "" >>) et autrement seront ignores. $SYSTEMD_LESS Outrepasser les options passees a less (par defaut << FRSXMK >>). Les utilisateurs voudront peut-etre changer deux options en particulier : K Cette option ordonne a l'afficheur de quitter immediatement lorsque Ctrl+C est entre. Pour permettre a less de gerer Ctrl+C lui-meme le retour a 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 appele est less, Ctrl+C sera ignore par l'executable et doit etre gere par l'afficheur. X Cette option ordonne a l'afficheur de ne pas envoyer les chaines d'initialisation et de desinitialisation de termcap au terminal. C'est le choix par defaut afin de permettre aux sorties des commandes de rester visibles dans le terminal meme apres que l'afficheur soit ferme. Toutefois, cela empeche quelques fonctionnalites de l'afficheur de fonctionner, en particulier, il n'est pas possible de faire defiler les sorties affichees avec la souris. Notez que le reglage de la variable d'environnement $LESS normale n'a aucun effet sur les invocations de less par les outils de systemd. Voir less(1) pour plus de details. $SYSTEMD_LESSCHARSET Outrepasser le jeu de caracteres passe a less (par defaut << utf-8 >>, si le terminal invoque est compatible avec l'UTF-8). Notez que le reglage de la variable d'environnement $LESSCHARSET normale n'a aucun effet sur les invocations de less par les outils de systemd. $SYSTEMD_PAGERSECURE Les commandes d'afficheur courantes comme less(1), en plus de << l'affichage >>, c'est-a-dire le defilement de la sortie, prennent en charge l'ouverture et l'ecriture d'autres fichiers et l'execution de commandes d'interpreteur arbitraires. Quand les commandes sont invoquees avec des privileges eleves, par exemple sous sudo(8) ou pkexec(1), l'afficheur devient une limite de securite. Il convient de veiller a ce que seuls des programmes avec des fonctionnalites strictement limitees soient utilises comme afficheurs et que les fonctionnalites comme l'ouverture ou la creation de nouveaux fichiers ou le demarrage de sous-processus ne soient pas autorisees. Un << mode securise >> pour l'afficher peut etre active comme decrit ci-dessous, si l'afficheur le prend en charge<= (la plupart des afficheurs ne sont pas ecrits de facon a prendre cela en consideration). Il est recommande soit d'activer explicitement le << mode securise >> soit de desactiver completement l'afficheur en utilisant --no-pager ou PAGER=cat lorsque des utilisateurs non fiables sont autorises a executer des commandes avec des privileges eleves. Cette option prend un argument booleen. Lorsqu'elle est definie a vrai, le << mode securise >> de l'afficheur est active. En << mode securise >>, LESSSECURE=1 est defini lors de l'invocation de l'afficheur, ce qui lui indique de desactiver les commandes qui ouvrent ou creent des fichiers, ou qui demarrent un nouveau sous-processus. Actuellement, seul less(5) est connu pour comprendre cette variable et implementer le << mode securise >>. Quand l'option est definie a faux, aucune limitation n'est imposee a l'afficheur. Definir SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de l'environnement herite peut permettre a l'utilisateur d'invoquer des commandes arbitraires. Quand $SYSTEMD_PAGERSECURE n'est pas defini, les outils de systemd tentent de determiner automatiquement si le << mode securise >> doit etre active et si l'afficheur le prend en charge. Le << mode securise >> est active si l'UID effectif est different de celui du proprietaire de la session de connexion (voir geteuid(2)) et sd_pid_get_owner_uid(3)) ou lors de l'execution sous sudo(8) ou des outils similaires ($SUDO_UID est defini a [3]). Dans ces cas, SYSTEMD_PAGERSECURE=1 sera defini et les afficheurs qui ne sont pas connus pour implementer le << mode securise >> ne seront pas du tout utilises. Notez que cette detection automatique ne couvre que les mecanismes les plus courants d'elevation des privileges et qu'elle est concue pour faciliter la tache. Il est recommande de definir explicitement $SYSTEMD_PAGERSECURE ou de desactiver l'afficheur. Notez que si les variables $SYSTEMD_PAGER ou $PAGER doivent etre respectees, sauf pour desactiver l'afficheur, $SYSTEMD_PAGERSECURE doit aussi etre defini. $SYSTEMD_COLORS Prend un argument booleen. Quand c'est << vrai >>, systemd et les utilitaires lies utiliseront la couleur pour leurs sorties, autrement, la sortie sera monochrome. En plus, la variable peut prendre une des valeurs speciales suivantes : 16 ou 256 pour limiter l'usage des couleurs aux couleurs ANSI base 16 ou base 256 respectivement. Cela peut etre precise pour outrepasser la decision automatique prise sur $TERM et quel que soit ce a quoi la console est connectee. $SYSTEMD_URLIFY La valeur doit etre un booleen. Controle si les liens cliquables doivent etre generes dans la sortie pour des emulateurs de terminaux le prenant en charge. Cela peut etre indique pour passer outre la decision faite par systemd basee sur $TERM et d'autres conditions. EXEMPLES Exemple 30. Politique JSON Le fichier JSON passe comme parametre de chemin a --security-policy= a un objet JSON de haut niveau dont les cles sont les identifiants des tests d'evaluation mentionnes ci-dessus. Les valeurs dans le fichier doivent etre des objets JSON avec un ou plusieurs des champs suivants : description_na (chaine), description_good (chaine), description_bad (chaine), weight (entier non signe) et range (entier non signe). Si l'un de ces champs correspondant a un identifiant specifique d'un fichier d'unite est manquant dans l'objet JSON, la valeur du champ interne par defaut correspondant a ce meme identifiant est utilisee comme valeur par defaut pour l'analyse de securite. Les champs weight et range sont utilises pour determiner le niveau d'exposition global des fichiers de l'unite : un score de mediocrite est assigne comme valeur a chaque reglage, qui est multiplie par le poids de la politique et divise par la plage de politique pour determiner l'exposition globale que ce reglage implique. Le degre de mediocrite calcule est additionne a tous les parametres du fichier de l'unite, normalise dans l'intervalle de 1 a 100 et utilise pour determiner le niveau d'exposition global de l'unite. En autorisant les utilisateurs a manipuler ces champs, la commande << security >> leur donne le choix de decider eux-memes 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 reglage ne sera pas verifie. { "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 metadonnees https://systemd.io/COREDUMP_PACKAGE_METADATA/ 2. Specification des partitions detectables https://uapi-group.org/specifications/specs/discoverable_partitions_specification 3. Il est recommande pour les autres outils de definir et verifier $SUDO_UID comme il convient, en le considerant comme une interface courante. TRADUCTION La traduction francaise de cette page de manuel a ete creee par bubu Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . systemd 257.8 SYSTEMD-ANALYZE(1)