Man page - systemctl(1)

Packages contains this manual

Package: systemctl
apt-get install systemctl

Manuals in package:

systemctl(1)

Documentations in package:

systemctl

Package: systemd
apt-get install systemd

Manuals in package:

Documentations in package:

systemd

Available languages:

en fr uk zh_TW zh_CN de

Manual

SYSTEMCTL

NOM
SYNOPSIS
DESCRIPTION
COMMANDES
Commandes d’unité (introspection et modification)
Commandes du fichier d’unité
Commandes de la machine
Commandes de tâche
Commandes d’environnement
Commandes du gestionnaire d’état
Commandes du système
Syntaxe de paramètre
OPTIONS
CODE DE RETOUR
ENVIRONNEMENT
VOIR AUSSI
NOTES
TRADUCTION

NOM

systemctl – Contrôler le gestionnaire de services et de système systemd

SYNOPSIS

systemctl [OPTIONS...] COMMANDE [UNITÉ...]

DESCRIPTION

systemctl est utilisé pour introspecter et contrôler l’état du gestionnaire de services et de système « systemd ». Veuillez consulter systemd (1) pour une introduction aux fonctionnalités et concepts de base de cet outil gestionnaire.

COMMANDES

Les commandes suivantes sont acceptées :

Commandes d’unité (introspection et modification)

list-units [ MOTIF ...]

Lister les unités que systemd possède actuellement en mémoire. Cette liste inclut les unités qui sont référencées directement ou à travers une dépendance, les unités qui sont épinglées de façon programmée ou les unités qui ont été actives dans le passé et ont échoué. Par défaut ne sont montrées que les unités qui sont actives, qui ont des tâches en attente ou qui ont échoué ; ce comportement peut être changé avec l’option --all . Si un MOTIF ou plus sont spécifiés, seules les unités qui y correspondent seront affichées. Les unités affichées peuvent être en plus filtrées par --type= et --state= si ces options sont indiquées.

Notez que cette commande n’affiche pas les modèles d’unités, mais seulement les instances de modèles d’unités. Les modèles d’unités qui ne sont pas instanciés ne sont pas exécutables, et donc ne seront jamais montrés dans le retour de cette commande. Précisément, cela signifie que truc@.service ne sera jamais affiché dans la liste — à moins d’être instancié, par exemple, comme truc@machin.service. Utiliser list-unit-files (voir ci-dessous) pour lister les fichiers de modèles d’unités installés.

Cette commande produit une sortie similaire à

UNIT LOAD ACTIVE SUB DESCRIPTION
sys-module-fuse.device loaded active plugged /sys/module/fuse
-.mount loaded active mounted Root Mount
boot-efi.mount loaded active mounted /boot/efi
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
● user@1000.service loaded failed failed User Manager for UID 1000
...
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

123 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

L’en-tête et la dernière unité d’un type donné sont soulignés si le terminal le gère. Un point coloré est affiché à côté des services qui sont masqués, non trouvés ou sinon ayant échoué.

La colonne LOAD montre l’état de chargement, c’est-à-dire loaded , not-found , bad-setting , error ou masked . La colonne ACTIVE montre l’état général de l’unité, parmi les suivants :

Table 1. états d’ACTIVITÉ des unités

La colonne SUB montre l’état spécifique au type de l’unité de façon détaillée, les valeurs possibles varient selon le type d’unité. La liste des états possibles LOAD, ACTIVE et SUB n’est pas constante et les nouvelles versions de systemd peuvent à la fois ajouter et supprimer des valeurs.

systemctl --state=help

Cette commande peut être utilisée pour afficher l’ensemble actuel des valeurs possibles.

C’est la commande par défaut.

list-automounts [ MOTIF ...]

Lister les unités d’automontage actuellement en mémoire, par ordre des chemins de montage. Si un ou plusieurs MOTIF sont indiqués, seules les unités d’automontage correspondant à l’un d’entre eux sont affichées. Cette commande produit une sortie similaire à

WHAT WHERE MOUNTED IDLE TIMEOUT UNIT
/dev/sdb1 /mnt/test no 120s mnt-test.automount
binfmt_misc /proc/sys/fs/binfmt_misc yes 0 proc-sys-fs-binfmt_misc.automount

2 automounts listed.

Voir aussi --show-types , --all et --state= .

Ajouté dans la version 252.

list-paths [ MOTIF ...]

Lister les chemins d’unités actuellement en mémoire, par ordre des chemins&. Si un ou plusieurs MOTIF sont indiqués, seuls les chemins d’unité correspondant à l’un d’entre eux sont affichés. Cette commande produit une sortie similaire à

PATH CONDITION UNIT ACTIVATES
/run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-plymouth.path systemd-ask-password-plymouth.service
/run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-wall.path systemd-ask-password-wall.service
/var/cache/cups/org.cups.cupsd PathExists cups.path cups.service

3 paths listed.

Voir aussi --show-types , --all et --state= .

Ajouté dans la version 254.

list-sockets [ MOTIF ...]

Lister les unités de socket actuellement en mémoire, par ordre des adresses d’écoute. Si un ou plus de MOTIF sont indiqués, seules les unités de socket correspondant à l’un d’entre eux sont affichées. Cette commande produit une sortie similaire à

LISTEN UNIT ACTIVATES
kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
/dev/rfkill systemd-rfkill.socket systemd-rfkill.service
...

5 sockets listés.

Remarque : vu que ces adresses peuvent contenir des espaces, cette sortie n’est pas adéquate pour une utilisation en programmation.

Voir aussi --show-types , --all et --state= .

Ajouté dans la version 202.

list-timers [ MOTIF ...]

Lister les unités de temporisateur actuellement en mémoire, classées selon le moment où elles se terminent. Si un ou plusieurs MOTIF sont indiqués, seules les unités correspondant à l’un d’entre eux sont affichées. Cette commande produit une sortie similaire à

NEXT LEFT LAST PASSED UNIT ACTIVATES
- - Thu 2017-02-23 13:40:29 EST 3 days ago ureadahead-stop.timer ureadahead-stop.service
Sun 2017-02-26 18:55:42 EST 1min 14s left Thu 2017-02-23 13:54:44 EST 3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2017-02-26 20:37:16 EST 1h 42min left Sun 2017-02-26 11:56:36 EST 6h ago apt-daily.timer apt-daily.service
Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago snapd.refresh.timer snapd.refresh.service

NEXT affiche le prochain moment où le temporisateur se déclenchera.

LEFT affiche le délai jusqu’à la prochaine exécution du temporisateur.

LAST affiche le dernier moment de fonctionnement du temporisateur.

PASSED affiche combien de temps a passé depuis la dernière activité du temporisateur.

UNIT affiche le nom du temporisateur

ACTIVATES affiche le nom du service activé par le temporisateur lors de son fonctionnement.

Voir aussi --all et --state= .

Ajouté dans la version 206.

is-active MOTIF ...

Vérifier si une des unités indiquées est active (c’est-à-dire en fonctionnement). Renvoi du code retour 0 si au moins une est active ou différent de zéro dans le cas contraire. À moins que --quiet ne soit indiqué, l’état actuel de l’unité sera aussi affiché sur la sortie standard.

is-failed [ MOTIF ...]

Vérifier si l’une des unités indiquées est en état d’« échec ». Si aucune unité n’est indiquée, vérifier si des unités sont en échec, ce qui correspond à l’état « degraded » renvoyé par is-system-running . Cela renvoie le code de retour 0 si au moins l’une est en échec, différent de zéro dans le cas contraire. À moins que --quiet ne soit indiqué, l’état actuel de l’unité sera aussi affiché sur la sortie standard.

Ajouté dans la version 197.

status [ MOTIF ...| PID ...]]

Afficher les informations d’état de fonctionnement du système entier ou d’une ou plusieurs unités suivies des données de journalisation les plus récentes. Si aucun argument de position n’est indiqué et qu’aucun filtre d’unité n’est donné avec --type= , --state= ou --failed , l’état de tout le système est affiché. Si cette option est combinée avec --all , l’affichage est complété par l’état de toutes les unités. Si des arguments de positionnement sont indiqués, chaque argument de position est traité comme un nom d’unité à afficher, comme un motif généraliste pour afficher les unités dont le nom correspond à ce motif, ou comme un PID pour afficher l’unité contenant ce PID. Lorsque --type= , --state= ou --failed sont utilisées, les unités sont en plus filtrées selon l’état d’ACTIVE et de TYPE.

Cette fonction génère une sortie lisible pour un humain. Si vous cherchez une sortie analysable par un ordinateur, utilisez plutôt show . Par défaut, cette fonction n’affiche que dix lignes de sortie et tronque les lignes pour qu’elles tiennent dans la fenêtre du terminal. Ce comportement peut être changé avec --lines et --full , voir ci-dessus. De plus, journalctl --unit= NOM ou journalctl --user-unit= NOM utilise un filtre similaire pour les messages et peut s’avérer plus pratique.

À noter que cette opération n’affiche que l’état d’ exécution , c’est-à-dire les informations sur l’invocation actuelle de l’unité (si elle est en fonctionnement) ou l’invocation la plus récente (si elle n’est plus en fonctionnement et encore en mémoire). Les informations sur de précédentes invocations, des invocations de démarrages antérieurs du système ou des invocations précédentes qui ont déjà été supprimées de la mémoire peuvent être retrouvées avec journalctl --unit= .

systemd charge implicitement les unités si nécessaire, donc exécuter simplement le status essaiera de charger un fichier. La commande n’est donc pas nécessaire pour déterminer si quelque chose a déjà été chargé ou non. Les unités seront probablement déchargées rapidement dès que l’opération sera terminée s’il n’y a aucune raison de les garder en mémoire après.

Exemple 1. Exemple de sortie de systemctl status

$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
Docs: man:bluetoothd(8)
Main PID: 930 (bluetoothd)
Status: "Running"
Tasks: 1
Memory: 648.0K
CPU: 435ms
CGroup: /system.slice/bluetooth.service
└─930 /usr/lib/bluetooth/bluetoothd

Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service
Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered
Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)

Le point (« ● ») utilise la couleur sur les terminaux qui la gèrent pour résumer l’état de l’unité en un coup d’œil. Outre sa couleur, sa forme varie suivant l’état : « inactive » ou « maintenance » est un cercle blanc (« ○ »), « active » est un point vert (« ● »), « deactivating » est un point blanc, « failed » ou « error » est une croix rouge (« × »), et « reloading » ou « refreshing » est une flèche circulaire verte dans le sens des aiguilles d’une montre (« ↻ »).

La ligne « Loaded » dans la sortie affichera « loaded » si l’unité a été chargée en mémoire. D’autres valeurs possibles pour « Loaded » incluent : « error » s’il y a eu un problème à la charger, « not-found » si aucun fichier d’unité n’a été trouvé pour cette unité, « bad-setting » si une définition essentielle de fichier d’unité n’a pu être analysé et « masked » si le fichier de l’unité a été masqué. En même temps qu’afficher le chemin du fichier de l’unité, cette ligne affichera aussi l’état d’activation. Les unités activées sont incluses dans le réseau de dépendances entre les unités et sont donc démarrées au démarrage ou à travers d’autres formes d’activation. Consultez la table complète des états d’activation (incluant la définition de « masked ») dans la documentation de la commande is-enabled .

La ligne « Active » affiche l’état actif. La valeur est habituellement « active » ou « inactive ». Active peut signifier démarré, lié, branché, etc, selon le type d’unité. L’unité peut aussi être en cours de changement d’état, faisant rapport d’un état « activating » (activation en cours) ou « deactivating » (désactivation en cours). Un état spécial « failed » est annoncé lorsque le service est en échec d’une quelconque manière, telle qu’un plantage, une sortie avec un code d’erreur ou une temporisation dépassée. Si l’état d’échec est annoncé, la cause sera écrite dans un journal pour référence ultérieure.

show [ MOTIF ...| JOB ...]

Afficher les propriétés d’une ou plusieurs unités, jobs ou du gestionnaire lui-même. Si aucun argument n’est indiqué, les propriétés du gestionnaire seront affichées. Si un nom d’unité est indiqué, les propriétés de l’unité seront affichées et si un ID de job est indiqué, les propriétés du job seront affichées. Les propriétés vides sont enlevées par défaut. Utiliser --all pour les afficher aussi. Pour sélectionner des propriétés spécifiques à afficher, utiliser --property= . Cette commande est prévue pour être utilisée chaque fois qu’une sortie analysable par un ordinateur est demandée. Utiliser status pour avoir une sortie formatée pour être humainement lisible.

De nombreuses propriétés affichées par systemctl show correspondent directement aux paramètres de configuration du gestionnaire du système et de services et de ses fichiers d’unités. Notez que les propriétés affichées par la commande sont généralement plus des versions de bas niveau et normalisées de la configuration originelle et affichent l’état d’exécution en supplément de la configuration. Par exemple, les propriétés affichées pour les unités de service incluent l’identifiant du processus principal en cours connu comme « MainPID » (qui est l’état d’exécution), et les paramètres de temps sont toujours affichés en tant que propriétés se terminant avec le suffixe « ...USec » même si les options de la configuration correspondantes finissent en « ...Sec », car la microseconde est l’unité de temps réglementaire utilisée en interne par le gestionnaire du système et de services.

Pour des détails sur un grand nombre de ces propriétés, consulter la documentation de l’interface D-Bus prenant en charge ces propriétés, voir org.freedesktop.systemd1 (5).

cat MOTIF ...

Afficher les fichiers de sauvegarde d’une ou plusieurs unités. Afficher le « fragment » et les « drop-ins » (fichiers source) des unités. Chaque fichier est précédé d’un commentaire qui inclut le nom de fichier. Remarquez que cette commande montre le contenu de ces fichiers de sauvegarde sur le disque, qui peuvent ne pas correspondre à la compréhension de ces unités par le gestionnaire du système si des fichiers d’unité ont été mis à jour sur le disque et que la commande daemon-reload n’a pas été lancée depuis.

Ajouté dans la version 206.

help MOTIF ...| PID ...

Afficher les pages de manuel pour une ou plusieurs unités, si disponibles. Si un PID est donné, les pages de manuel de l’unité à laquelle le processus appartient sont affichées.

Ajouté dans la version 185.

list-dependencies [ UNITÉ ...]

Afficher les unités nécessaires et demandées par les unités indiquées. Cette commande liste récursivement les unités qui suivent les dépendances Requires= , Requisite= , ConsistsOf= , Wants= , BindsTo= et Upholds= . Si aucune unité n’est spécifiée, default.target (la cible par défaut) est sous-entendu.

Les unités qui sont affichées sont filtrées en plus par --type= et --state= si ces options sont spécifiées. Notez qu’il n’est pas possible d’utiliser une structure arborescente dans ce cas, aussi --plain est implicite.

Seules les cibles d’unité sont développées récursivement par défaut. Lorsque --all est passé, toutes les autres unités sont aussi développées récursivement.

Les options --reverse , --after et --before peuvent être utilisées pour changer les types de dépendance à afficher.

À noter que cette commande ne liste que les unités actuellement chargées en mémoire par le gestionnaire de services. En particulier, cette commande n’est pas adaptée pour avoir une liste exhaustive des dépendances inverses (reverse dependencies) d’une unité indiquée, car cela ne listera pas les dépendances déclarées par les unités non chargées actuellement.

Ajouté dans la version 198.

start MOTIF ...

Démarrer (activer) une ou plus unités indiquées sur la ligne de commande.

À noter que les motifs avec métacaractères (glob) d’unité développent les noms des unités actuellement en mémoire. Les unités qui ne sont pas actives et qui ne sont pas en échec ne sont généralement pas en mémoire, et ne seront pas mappées avec un quelconque motif. De plus, dans le cas d’unités instanciées, systemd est souvent ignorant du nom d’instance tant que l’instance n’a pas démarré. Par conséquent, utiliser des motifs génériques avec start a une utilité limitée. Également, les noms secondaires d’alias d’unité ne sont pas pris en considération.

L’option --all peut aussi être utilisée pour agir sur les unités inactives qui sont référencées par d’autres unités chargées. Notez que cela n’est pas la même chose que d’agir sur « toutes » les unités possibles, car comme décrit dans le paragraphe précédent, une telle liste est mal définie. Cependant, systemctl start --all GLOB peut être utile si toutes les unités qui doivent correspondre au motif sont utilisées par une cible quelconque connue pour être chargée.

stop MOTIF ...

Stopper (désactiver) une ou plusieurs unités indiquées sur la ligne de commande.

Cette commande échouera si l’unité n’existe pas ou si l’arrêt de l’unité est interdit (voir RefuseManualStop= dans systemd.unit (5)). Cette commande n’échouera pas si l’une des commandes configurées pour stopper l’unité ( ExecStop= , etc.) est en échec, car le gestionnaire continuera à forcer l’arrêt de l’unité.

Si une unité qui a été stoppée peut encore être déclenchée par d’autres unités, un avertissement contenant les noms des unités déclencheurs est affiché. --no-warn peut être utilisé pour supprimer cet avertissement.

reload MOTIF ...

Demander à toutes les unités listées sur la ligne de commande de recharger leur configuration. Veuillez noter que cette commande rechargera la configuration spécifique au service, pas le fichier de configuration d’unité de systemd. Si vous voulez que systemd recharge le fichier de configuration d’une unité, utilisez la commande daemon-reload . En d’autres termes, dans l’exemple d’Apache, cette commande rechargera httpd.conf d’Apache dans le serveur web et non le fichier d’unité de systemd apache.service.

Cette commande ne doit pas être confondue avec la commande daemon-reload .

restart MOTIF ...

Stopper puis démarrer une ou plusieurs unités indiquées sur la ligne de commande. Si les unités ne sont pas déjà en fonctionnement, elles seront démarrées.

Remarquez que le redémarrage d’une unité avec cette commande ne supprimera pas forcément toutes les ressources de l’unité avant qu’elle ne soit démarrée à nouveau. Par exemple, la fonction de stockage de descripteur de fichier par service (voir FileDescriptorStoreMax= dans systemd.service (5)) restera intacte aussi longtemps que l’unité aura une tâche en attente, et ne sera nettoyée que lorsque l’unité sera pleinement stoppée et qu’aucune tâche ne sera encore en attente. Si l’intention est de vider aussi le stockage du descripteur de fichier lors d’une opération de redémarrage, une commande explicite systemctl stop suivie de systemctl start doit être lancée.

try-restart MOTIF ...

Stopper puis démarrer une ou plusieurs unités indiquées sur la ligne de commande si les unités sont en fonctionnement. Cette commande n’a aucun effet si les unités ne sont pas en fonctionnement.

reload-or-restart MOTIF ...

Recharger une ou plusieurs unités si elles prennent en charge cette fonctionnalité. Sinon, les stopper et les démarrer. Si les unités ne sont pas déjà en fonctionnement, elles seront démarrées.

Catte fonctionnalité est légèrement différente quand elle est utilisée en combinaison avec --marked , voir ci-dessous.

try-reload-or-restart MOTIF ...

Recharger une ou plusieurs unités si elles prennent en charge cette fonctionnalité. Sinon, les stopper puis les démarrer. Cette commande n’a aucun effet si les unités ne sont pas en fonctionnement.

Ajouté dans la version 229.

isolate UNITÉ

Démarrer l’unité indiquée sur la ligne de commande et ses dépendances et stopper toutes les autres, à moins qu’elles aient IgnoreOnIsolate=yes (voir systemd.unit (5)). Si un nom d’unité sans extension est donné, une extension de forme « .target » sera présumée.

Cette commande est dangereuse, car elle arrêtera immédiatement les processus qui ne sont pas activés dans la nouvelle cible, incluant possiblement l’environnement graphique ou le terminal en cours d’utilisation.

À noter que cette opération n’est permise que sur les unités où AllowIsolate= est activé. Voir systemd.unit (5) pour les détails.

kill MOTIF ...

Envoyer un signal à un ou plusieurs processus de l’unité. Utiliser --kill-whom= pour sélectionner le processus à tuer. Utiliser --signal= pour sélectionner le signal à envoyer. À employer avec --kill-value= pour mettre en file d’attente un signal POSIX en temps réel (POSIX Realtime Signal) avec une valeur associée.

clean MOTIF ...

Enlever la configuration, l’état, le cache, les journaux ou les données d’exécution des unités indiquées. Utiliser --what= pour sélectionner quelle sorte de ressource à enlever. Pour les unités de service, cette commande peut être utilisée pour enlever les répertoires configurés avec ConfigurationDirectory= , StateDirectory= , CacheDirectory= , LogsDirectory= et RuntimeDirectory= , voir systemd.exec (5) pour les détails. Cette commande peut aussi être utilisée pour vider le magasin de descripteurs de fichier comme activé avec FileDescriptorStoreMax= , consulter systemd.service (5) pour des détails supplémentaires. Cette commande peut être utilisée pour les unités de temporisateur pour vider les données d’horodatage persistantes si Persistent= est utilisé et --what=state est sélectionné, voir systemd.timer (5). Cette commande s’applique uniquement sur les unités qui utilisent l’une de ces définitions. Si --what= n’est pas indiqué, les données de cache et d’exécution ainsi que le magasin de descripteurs de fichier sont enlevés (vu que ces trois types de données sont généralement redondants et reproductibles lors de la prochaine invocation de l’unité). Notez que les unités indiquées doivent être stoppées pour invoquer cette opération.

Table 2. Valeurs possibles pour --what=

Ajouté dans la version 243.

freeze MOTIF ...

Geler une ou plusieurs unités indiquées sur la ligne de commande en utilisant le freezer (figeage) de cgroup

Le gel de l’unité entraînera la suspension de tous les processus contenus dans le cgroup correspondant à cette unité. La suspension signifie que tous les processus de l’unité ne seront pas programmés pour fonctionner sur le CPU jusqu’au dégel. Notez que cette commande n’est prise en charge que sur les systèmes qui utilisent une hiérarchie cgroup unifiée. L’unité est automatiquement dégelée avant qu’une tâche ne soit exécutée par l’unité, par exemple avant que l’unité soit stoppée.

Ajouté dans la version 246.

thaw MOTIF ...

« Dégeler » une ou plusieurs unités indiquées sur la ligne de commande.

Il s’agit de l’opération inverse de la commande freeze et reprend l’exécution des processus dans le cgroup de l’unité.

Ajouté dans la version 246.

set-property UNITÉ PROPRIÉTÉ = VALEUR ...

Définir les propriétés de l’unité indiquée lors de l’exécution lorsque cela est pris en charge. Cette commande permet le changement des propriétés de paramètre de configuration telles que les définitions du contrôle de ressources lors de l’exécution. Toutes les propriétés ne peuvent être changées lors de l’exécution, mais de nombreuses définitions de contrôle de ressources (principalement celles dans systemd.resource-control (5)) le peuvent. Ces changements sont appliqués immédiatement et stockés sur le disque pour les futurs redémarrages, à moins que --runtime ne soit passé, auquel cas les définitions ne s’appliqueront que jusqu’au prochain redémarrage. La syntaxe d’affectation des propriétés suit de près la syntaxe des affectations dans les fichiers d’unité.

Exemple : systemctl set-property trucmachin.service CPUWeight=200

Si l’unité indiquée se révèle inactive, les changements seront seulement stockés sur le disque comme décrit précédemment et seront ainsi effectifs lorsque l’unité sera démarrée.

Remarquez que cette commande permet de changer plusieurs propriétés au même moment, ce qui est préférable à les définir séparément.

Exemple : systemctl set-property trucmachin.service CPUWeight=200 MemoryMax=2G IPAccounting=yes

Comme avec les définitions de configuration de fichier d’unité, assigner une définition vide réinitialise la propriété à sa valeur par défaut.

Exemple : systemctl set-property avahi-daemon.service IPAddressDeny=

Ajouté dans la version 206.

bind UNITÉ CHEMIN [ CHEMIN ]

Montage bind d’un fichier ou d’un répertoire à partir de l’hôte dans l’espace de noms montage de l’unité indiquée. Le premier argument de chemin est le fichier source ou le répertoire de l’hôte, le second argument noms montage de le fichier de destination ou le répertoire dans l’espace de noms montage de l’unité. Lorsque ce dernier est omis, le chemin de destination dans l’espace de noms montage de l’unité est le même que le chemin de source sur l’hôte. Lorsque combiné avec le commutateur --read-only , un montage bind en lecture seule est créé. Lorsque combiné avec le commutateur --mkdir , le chemin de destination est créé avant que le montage ne soit appliqué.

À noter que cette option n’est actuellement prise en charge que pour les unités qui fonctionnent à l’intérieur d’un espace de noms montage (par exemple avec RootImage= , PrivateMounts= , etc.). Cette commande prend en charge le montage bind de répertoires, de fichiers normaux, des nœuds de périphériques, des nœuds de socket AF_UNIX ainsi que des FIFO. Le montage bind est éphémère et est défait dès que le processus actuel de l’unité existe. Notez que l’espace de noms mentionné ici, où le montage bind sera ajouté, est celui où fonctionne le principal processus du service. Les autres processus (ceux exécutés par ExecReload= , ExecStartPre= , etc.) fonctionnent dans des espaces de noms distincts.

Si cela est pris en charge par le noyau, tout montage antérieur sur la cible sélectionnée sera remplacé par le nouveau montage. Si cela n’est pas pris en charge, tout montage antérieur sera surmonté, mais restera épinglé et inaccessible.

Ajouté dans la version 248.

mount-image UNITÉ IMAGE [ CHEMIN [ NOM_PARTITION : OPTIONS_MONTAGE ]]

Monter une image depuis l’hôte dans l’espace de noms montage de l’unité indiqué. Le premier argument chemin est l’image source de l’hôte, le second argument chemin est le répertoire de destination dans l’espace de noms montage de l’unité (c’est-à-dire dans RootImage= / RootDirectory= ). L’argument suivant, s’il y en a un, est interprété comme un tuple de noms de partition séparés par des deux-points et une liste d’options séparées par des virgules pour cette partition. Le format est le même que la définition du service MountImages= . Lorsque combiné avec le commutateur --read-only , un montage en lecture seule est créé. Lorsque combiné avec le commutateur --switch , le chemin de destination est d’abord créé avant que le montage ne soit appliqué.

Remarque : cette option n’est actuellement prise en charge que pour les unités qui fonctionnent dans un espace de noms montage (c’est-à-dire avec RootImage= , PrivateMounts= , etc.). Notez que l’espace de noms mentionné ici, là où l’image montée sera ajoutée, est celui où le processus principal du service fonctionne. Notez que l’espace de noms mentionné ici, où le montage bind sera ajouté, est celui où le processus du service principal fonctionne. Les autres processus (ceux exécutés par ExecReload= , ExecStartPre= , etc.) fonctionnent dans des espaces de noms distincts.

Exemple :

systemctl mount-image truc.service /tmp/img.raw /var/lib/image root:ro,nosuid

systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img

Ajouté dans la version 248.

service-log-level SERVICE [ NIVEAU ]

Si l’argument NIVEAU n’est pas indiqué, afficher le niveau de journalisation actuel tel qu’indiqué par le service SERVICE .

Si l’argument optionnel NIVEAU est fourni, cette commande change le niveau de journalisation actuel du service à NIVEAU . Le niveau de journalisation doit être un niveau typique de journalisation syslog, c’est-à-dire une valeur entre 0 et 7 ou l’une des chaînes emerg , alert , crit , err , warning , notice , info ou debug ; voir syslog (3) pour les détails.

Le service doit avoir la propriété NomBus=destination appropriée et implémenter aussi l’interface générique org.freedesktop.LogControl1 (5). ( systemctl utilisera le protocole D-Bus générique pour accéder à l’interface org.freedesktop.LogControl1.LogLevel pour le nom D-Bus destination .)

Ajouté dans la version 247.

service-log-target SERVICE [ CIBLE ]

Si l’argument CIBLE n’est pas présent, afficher la cible de journal actuelle comme indiqué par le service SERVICE .

Si l’argument optionnel CIBLE est fourni, changer la cible de journal actuelle du service à CIBLE . La cible de journal doit être une des chaînes console (pour une sortie de la journalisation sur le flux d’erreur standard du service), kmsg (pour une journalisation dirigée sur le tampon de journal du noyau), journal (pour une sortie de journalisation vers systemd-journal-service (8) en utilisant le protocole natif de journal), syslog (pour une sortie vers l’habituel socket syslog /dev/log), null (pour aucune sortie de journalisation quoi qu’il se passe) ou auto (pour un choix déterminé automatiquement, en général équivalent à console si le service est appelé interactivement, et journal ou syslog dans le cas contraire).

Pour la plupart des services, seul un sous-ensemble de cibles de journal a du sens. En particulier, la plupart des services « normaux » devraient seulement implémenter console , journal et null . Tout le reste n’est approprié que pour les services bas niveau qui sont actifs au tout début de l’amorçage avant que la journalisation appropriée ne soit établie.

Ajouté dans la version 247.

reset-failed [ MOTIF ...]

Réinitialiser l’état « failed » des unités indiquées, ou si aucun nom n’est indiqué, réinitialiser l’état de toutes les unités. Lorsqu’une unité échoue de quelque manière (c’est-à-dire le processus finit avec un code d’erreur différent de zéro, terminant anormalement ou dépassant le délai), elle entrera dans un état « failed » et son code de retour et son état seront enregistrés pour introspection par l’administrateur jusqu’à ce que le service soit stoppé et redémarré ou réinitialisé avec cette commande.

En supplément de la réinitialisation de l’état « failed » d’une unité, il réinitialise diverses propriétés par unité : le compteur de départ de limite de taux de tous les types d’unité est réinitialisé à zéro, comme l’est le compteur de redémarrage des unités de service. Donc, si une limite de démarrage d’une unité (comme configuré avec StartLimitIntervalSec= / StartLimitBurst= ) est atteinte et que l’unité refuse de démarrer à nouveau, utiliser cette commande pour la rendre prête à démarrer à nouveau.

whoami [ PID ...]

Renvoie les unités auxquelles appartiennent les processus référencés par leurs PID (une par ligne). Si aucun PID n’est spécifié, renvoie l’unité dans laquelle est invoquée la commande systemctl .

Ajouté dans la version 254.

Commandes du fichier d’unité

list-unit-files [ MOTIF... ]

Lister les fichiers d’unité installés sur le système, en combinaison avec leur état d’activation (comme indiqué par is-enabled ). Si un ou plusieurs MOTIF sont spécifiés, seuls les fichiers d’unité dont les noms correspondent sont affichés (les motifs correspondant aux chemins d’unité du système de fichiers ne sont pas pris en charge).

Contrairement à list-units , cette commande permet de lister les unités modèles en plus des unités explicitement instanciées.

Ajouté dans la version 233.

enable UNITÉ ... , enable CHEMIN ...

Activer une ou plusieurs unités ou instances d’unité. Cette commande crée un ensemble de liens symboliques, comme encodés dans les sections [Install] des fichiers d’unité indiqués. Après la création des liens symboliques, la configuration du gestionnaire système est rechargée (d’une façon équivalente à daemon-reload ), de manière à s’assurer que les changements soient pris en compte immédiatement. Remarquez que cette commande n’a pas pour effet de démarrer aussi les unités qui ont été activées. Si c’est le but recherché, combiner cette commande avec --now ou invoquer start avec les arguments appropriés plus tard. Remarquez que dans le cas d’activation d’instance d’unité (c’est-à-dire activation d’unités sous forme truc@machin.service), les liens symboliques de même nom que les instances sont créés dans le répertoire de configuration de l’unité ; cependant ils pointent sur le seul fichier d’unité modèle à partir duquel ils sont instanciés.

Cette commande attend soit des noms d’unité valables (auquel cas divers répertoires de fichiers d’unité sont automatiquement cherchés pour les fichiers d’unité avec le nom approprié), soit des chemins absolus de fichiers d’unité (auquel cas ils sont lus directement). Si un fichier d’unité est situé en dehors des répertoires habituels de fichier d’unité, un lien symbolique est créé, le reliant au chemin de configuration de l’unité, pour s’assurer qu’il soit trouvé lorsque demandé par une commande telle que start . Le système de fichiers où les fichiers d’unité liés sont situés doit être accessible lors du démarrage de systemd (par exemple, tout ce qui est en dessous de /home ou /var n’est pas autorisé, à moins que ces répertoires soient situés dans le système de fichiers racine).

Cette commande affiche les opérations du système de fichiers exécutées. Cette sortie peut être supprimée en passant --quiet .

Remarque : cette opération ne crée que les liens symboliques suggérés dans la section [Install] des fichiers d’unité. Bien que cette commande soit la manière recommandée pour manipuler le répertoire de configuration d’unité, l’administrateur est libre de faire des changements supplémentaires en plaçant ou supprimant des liens symboliques sous ce répertoire. Cela est particulièrement utile pour créer des configurations qui diffèrent de l’installation suggérée par défaut. Dans ce cas, l’administrateur doit s’assurer d’invoquer daemon-reload manuellement si nécessaire, pour s’assurer que les changements soient pris en compte.

Lorsqu’on utilise cette opération sur des unités qui n’ont pas d’informations d’installation, un avertissement est affiché. --no-warn peut être utilisé pour supprimer cet avertissement.

L’activation d’unité ne doit pas être confondue avec le démarrage d’unité (mise en service) déclenché par la commande start . L’activation et le démarrage d’unité sont indépendants : les unités peuvent être activées sans être démarrées et démarrées sans être activées. L’activation permet simplement d’accrocher l’unité à divers emplacements suggérés (par exemple, que l’unité soit automatiquement démarrée à l’amorçage ou lorsqu’un type particulier de matériel est branché). Le démarrage entraîne réellement l’apparition du processus démon (pour les unités de service) ou lie le socket (pour les unités de socket), etc.

Selon que --system , --user , --runtime ou --global est indiqué, cette commande active l’unité pour le système, seulement pour utilisateur appelant, seulement pour cet amorçage du système ou pour toutes les connexions futures de tous les utilisateurs. Notez que dans ce dernier cas, aucune configuration du démon systemd n’est rechargée.

L’utilisation de enable sur des unités masquées n’est pas prise en charge et provoque une erreur.

disable UNITÉ ...

Désactivation d’une ou plusieurs unités. Cette commande supprime tous les liens symboliques vers les fichiers d’unité soutenant les unités spécifiées dans le répertoire de configuration d’unité, et annule donc toute modification apportée par enable ou link . Notez que cela supprime tous les liens symboliques vers des fichiers d’unité correspondants, incluant les liens symboliques créés manuellement et pas seulement ceux créés réellement par enable ou link . Remarquez que même si disable annule les effets de enable , les deux commandes ne sont pas symétriques pour autant, car disable peut supprimer davantage de liens symboliques qu’une invocation précédente de enable n’en a créé sur la même unité.

Cette commande attend seulement des noms d’unité valables, elle n’accepte pas de chemins de fichier d’unité.

En supplément des unités indiquées en arguments, sont aussi désactivées toutes les unités qui sont listées dans le réglage Also= contenu dans la section [Install] des fichiers d’unité sur lesquels on opère.

Cette commande recharge implicitement la configuration du gestionnaire système après avoir achevé l’opération. Notez que cette commande ne stoppe pas implicitement les unités qui ont été désactivées. Si c’est ce que l’on souhaite, combiner cette commande avec le commutateur --now ou invoquer la commande stop avec les arguments appropriés plus tard.

Cette commande affiche des informations sur les opérations sur le système de fichiers (suppression des liens symboliques) exécutées. Cette sortie peut être supprimée en passant --quiet .

Si une unité est désactivée mais que ses unités déclencheurs sont toujours actives, un avertissement contenant les noms des unités déclencheur est affiché. --no-warn peut être utilisé pour supprimer cet avertissement.

Lorsque cette commande est utilisée avec --user , les unités en cours d’exploitation peuvent encore être activées pour une portée globale, et se lancent donc automatiquement même après une désactivation réussie dans le champ d’application de l’utilisateur. Un avertissement à ce propos est alors affiché, qui peut être supprimé en utilisant --no-warn .

Cette commande tient compte de --system , --user , --runtime , --global et --no-warn d’une manière similaire à enable .

Ajouté dans la version 238.

reenable UNITÉ ...

Réactiver une ou plusieurs unités, comme indiqué sur la ligne de commande. C’est une combinaison de disable et enable et permet de réinitialiser les liens symboliques d’une unité activée aux paramètres par défaut configurés dans sa section [Install]. Cette commande attend un nom d’unité uniquement, elle n’accepte pas les chemins de fichier d’unité.

Ajouté dans la version 238.

preset UNITÉ ...

Réinitialiser l’état activé/désactivé d’un ou plusieurs fichiers d’unité spécifiés sur la ligne de commande aux valeurs par défaut configurées dans les fichiers de politique prédéfinis. Cette commande a le même effet que disable ou enable , suivant la manière dont l’unité est listée dans les fichiers prédéfinis.

Utiliser --preset-mode= pour contrôler si les unités doivent être activées puis désactivées, ou seulement activées, ou seulement désactivées.

Si l’unité n’intègre pas d’informations d’installation, elle sera ignorée silencieusement par cette commande. UNITÉ doit être le vrai nom de l’unité, tout nom d’alias sera ignoré silencieusement.

Pour davantage d’informations sur le format de politique prédéfini, consulter systemd.preset (5).

Ajouté dans la version 238.

preset-all

Réinitialiser tous les fichiers d’unité installés aux valeurs par défaut configurées dans le fichier de politique prédéfini (voir ci-dessus).

Utiliser --preset-mode= pour contrôler si les unités doivent être activées puis désactivées, ou seulement activées, ou seulement désactivées.

Ajouté dans la version 215.

is-enabled UNITÉ ...

Vérifier si l’un des fichiers indiqués est activé (comme avec enable ). Un code de retour de 0 est renvoyé si au moins un fichier est activé, ou différent de zéro dans le cas contraire. Afficher l’état actuel d’activation (voir table). Pour supprimer cette sortie utiliser --quiet . Pour montrer les cibles d’installation utiliser --full .

Table 3. Sortie is-enabled

Ajouté dans la version 238.

mask UNITÉ ...

Masquer une ou plusieurs unités spécifiées sur la ligne de commande. Cette commande lie les fichiers d’unité à /dev/null, les rendant impossibles à démarrer. C’est une version plus forte de disable , puisqu’elle prohibe toute sorte de mise en service de l’unité, y compris l’activation et le démarrage manuel. À utiliser avec prudence. Cela permet à l’option --runtime de masquer temporairement jusqu’au prochain redémarrage du système. L’option --now peut être utilisée pour s’assurer que les unités soient aussi stoppées. Cette commande attend uniquement des noms valables d’unité et n’accepte pas de chemins de fichier d’unité.

Notez que cette commande créera un lien symbolique sous le nom de l’unité dans /etc/systemd/system/ (au cas où --runtime n’est pas indiqué) ou /run/systemd/system/ (dans le cas où --runtime est spécifié). Si un fichier d’unité correspondant existe déjà sous ces répertoires, l’opération échouera. Cela signifie que l’opération est d’abord utile pour masquer les unités livrées par le fournisseur (comme celles fournies dans /usr/lib/systemd/system/ et non dans les deux répertoires susmentionnés), mais typiquement, cela ne fonctionne pas pour les unités créées localement (et celles qui sont précisément placées dans les deux répertoires susmentionnés). Des restrictions similaires s’appliquent dans le mode --user , auquel cas les répertoires sont de toute manière sous le répertoire personnel (home) de l’utilisateur.

Si une unité a été masquée mais que ses unités déclencheur sont toujours actives, un avertissement contenant les noms des unités déclencheur est affiché. --no-warn peut être utilisé pour supprimer cet avertissement.

Ajouté dans la version 238.

unmask UNITÉ ...

Démasquer un ou plusieurs fichiers d’unité spécifiés sur la ligne de commande. Cette commande annule l’effet de mask . Cette commande attend uniquement des noms d’unité valables et n’acceptera pas des chemins de fichier d’unité.

Ajouté dans la version 238.

link CHEMIN ...

Lier un fichier d’unité qui n’est pas dans le chemin de recherche de fichier d’unité au chemin de recherche de fichiers d’unité. Cette commande attend un chemin absolu vers un fichier d’unité. L’effet de cette commande peut être annulé avec disable . Cette commande a pour effet de rendre disponible le fichier d’unité pour des commandes telles que start , même s’il n’est pas installé directement dans le chemin de recherche d’unité. Le système de fichiers où sont situés les fichiers d’unité liés doit être accessible au démarrage de systemd (par exemple, tout ce qui est sous /home ou /var n’est pas autorisé, à moins que ces répertoires soient situés sur le système de fichiers racine).

Ajouté dans la version 233.

revert UNITÉ ...

Rétablir un ou plusieurs fichiers d’unité à leur version d’usine. Cette commande supprime les fichiers de configuration de substitution qui modifient les unités indiquées, ainsi que tout fichier d’unité configuré par l’utilisateur qui écrase le fichier d’unité correspondant du fournisseur. Spécifiquement, pour une unité « machin.service » les répertoires « machin.service.d/ » correspondants sont supprimés avec tous les fichiers qu’ils contiennent, à la fois sous les répertoires de configuration d’exécution et persistante (c’est-à-dire sous /etc/systemd/system et /run/systemd/system) ; si le fichier d’unité a une version du fournisseur (c’est-à-dire un fichier d’unité situé sous /usr/) tous les fichiers d’unité d’exécution ou persistants qui correspondent et qui l’écrasent sont aussi supprimés. Notez que si un fichier d’unité n’a pas de version du fournisseur (c’est-à-dire est seulement défini sous /etc/systemd/system ou /run/systemd/system, mais pas dans un fichier d’unité stocké sous /usr/), il n’est pas supprimé. Aussi, si une unité est masquée, elle est démasquée.

Effectivement, cette commande peut être utilisée pour annuler tous les changements effectués avec systemctl edit , systemctl set-property et systemctl mask et remet en place le fichier d’unité d’origine avec ses réglages.

Ajouté dans la version 198.

add-wants CIBLE UNITÉ ... , add-requires CIBLE UNITÉ ...

Ajouter respectivement les dépendances « Wants= » ou « Requires= » à la CIBLE indiquée pour une ou plusieurs unités.

Cette commande prend en compte --system , --user , --runtime et --global de manière similaire à enable .

Ajouté dans la version 217.

edit UNITÉ ...

Éditer ou remplacer un fragment de drop-in ou le fichier principal de l’unité pour étendre ou outrepasser la définition de l’unité indiquée.

Selon que --system (par défaut), --user ou --global est indiqué, cette commande opèrera sur les fichiers unité système, les fichiers d’unité de l’utilisateur appellant ou les fichiers d’unité partagés par tous les utilisateurs.

L’éditeur (voir la section « Environnement » ci-dessous) est invoqué dans de fichiers temporaires qui seront écrit à l’emplacement réel si l’éditeur quitte avec succès. Après avoir été éditée, la configuration est rechargée, c’est l’équivalent de systemctl daemon-reload --system ou systemctl daemon-reload --user . Pour edit --global , le rechargement n’est pas effectué et les écrits prendront effet qu’aux connexions suivantes (ou après un rechargement, si demandé d’une autre manière).

Si --full est indiqué, un remplaçant pour le fichier principal d’unité sera créé ou édité. Sinon, un fichier de substitution sera créé ou édité.

Si --drop-in= est indiqué, le nom du fichier de substitution donné sera utilisé à la place de celui par défaut : override.conf.

L’unité doit quitter, c’est à dire que son fichier principal d’unité doit être présent. Si --force est indiqué, cela est ignoré et une nouvelle unité sera créée (avec --full ), ou un drop-in sera créé pour une unité inexistante.

Si --runtime est indiqué, les changements seront effectués de manière temporaire dans /run/ et seront perdus lors du prochain redémarrage.

Si --stdin est indiqué, les nouveaux contenus seront lus depuis l’entrée standard. Dans ce mode, les anciens contenus des fichiers sont déchargés.

Si le fichier temporaire est vide à la sortie, les modifications de l’unité concernée sont annulées.

Remarquez que cette commande ne peut pas être utilisée pour éditer des unités à distance et que vous ne pouvez pas éditer temporairement les unités qui sont dans /etc/, car elles ont priorité sur /run/.

Ajouté dans la version 218.

get-default

Renvoyer la cible par défaut dans laquelle démarrer. Cette commande renvoie le nom d’unité cible à laquelle default.target est liée (lien symbolique).

Ajouté dans la version 205.

set-default CIBLE

Définir la cible par défaut dans laquelle démarrer. Cette commande définit (lie symboliquement) l’alias default.target à l’unité cible donnée.

Ajouté dans la version 205.

Commandes de la machine

list-machines [ MOTIF ...]

Lister l’hôte et tous les conteneurs locaux en cours d’exécution avec leur état. Si un ou plusieurs MOTIF sont indiqués, seuls les conteneurs correspondants à l’un d’entre eux sont affichés.

Ajouté dans la version 212.

Commandes de tâche

list-jobs [ MOTIF... ]

Lister les tâches en cours. Si un ou plusieurs MOTIF sont indiqués, seules les tâches pour des unités correspondant à l’un d’entre eux sont affichées.

Lorsque combinée avec --after ou --before , la liste est complétée par des informations à propos des tâches attendues par chaque tâche et des tâches qui l’attendent, voir ci-dessus.

Ajouté dans la version 233.

cancel [ TÂCHE ...]

Effacer une ou plusieurs tâches indiquées sur la ligne de commande par leur identifiant numérique de tâche. Si aucun identifiant n’est spécifié, cette commande efface toutes les tâches en attente.

Ajouté dans la version 233.

Commandes d’environnement

systemd prend en charge un bloc d’environnement qui est passé aux processus que le gestionnaire crée. Les noms des variables peuvent contenir des lettres ASCII, des chiffres et le caractère de soulignement. Les noms de variable ne peuvent pas être vides ou commencer par un chiffre. La plupart des caractères sont autorisés dans les valeurs de variable, mais la séquence entière doit être en UTF-8 valable (à noter que les caractères de contrôle tels que nouvelle ligne ( NL ), tabulation ( TAB ) ou le caractère d’échappement ( ESC ) sont du ASCII valable et donc UTF-8 valable). La longueur totale du bloc d’environnement est limitée par la valeur _SC_ARG_MAX définie par sysconf (3).

show-environment

Extraire le contenu du bloc d’environnement du gestionnaire systemd. C’est le bloc d’environnement qui est passé à tous les processus que le gestionnaire crée. Le bloc d’environnement sera extrait sous une forme simple et adaptée à la syntaxe de la plupart des interpréteurs de commande. Si aucun caractère spécial ou espace n’est présent dans les valeurs de la variable, aucun échappement n’est effectué et les assignations sont de la forme « VARIABLE=valeur ». Si une espace ou des caractères ayant une signification spéciale pour l’interpréteur sont présents, l’échappement dollar-guillemet-simple est utilisé et les assignations sont de la forme « VARIABLE=$'valeur' ». Cette syntaxe est prise en charge par bash (1), zsh (1), ksh (1) et ash (1) de busybox (1), mais pas par dash (1), ni par fish (1).

Notez que cela montre le bloc effectif , c’est-à-dire la combinaison des variables d’environnement configurées avec les fichiers de configuration, les générateurs d’environnement et avec IPC (c’est-à-dire avec set-environment comme décrit plus bas). Au moment où un processus d’unité est fourché, ce bloc d’environnement combiné sera encore combiné avec desvariables d’environnement par unité, qui ne sont pas visibles dans cette commande.

set-environment VARIABLE=VALEUR ...

Définir une ou plusieurs variables d’environnement du gestionnaire de service, comme indiqué sur la ligne de commande. Cette commande échouera si les noms de variable et leurs valeurs ne sont pas conformes aux règles énumérées ci-dessus.

Ajouté dans la version 233.

unset-environment VARIABLE ...

Annuler la définition d’une ou plusieurs variables d’environnement du gestionnaire de systemd. Si seulement un nom de variable est indiqué, il sera supprimé sans s’occuper de sa valeur. Si une variable et une valeur sont indiquées, la variable n’est supprimée que si elle a la valeur indiquée.

Notez que cela agit sur un bloc d’environnement séparé du bloc d’environnement configuré par le service gestionnaire de configuration et les générateurs d’environnement. Chaque fois qu’un processus est appelé, les deux blocs sont combinés (incorporant aussi toutes les variables d’environnement par service) et transmis au processus. show-environment affichera la combinaison des blocs, voir ci-dessus. Notez que cela signifie que cette commande ne peut pas être utilisée pour enlever des variables d’environnement définies dans les fichiers de configuration du gestionnaire de services ou avec les générateurs.

Ajouté dans la version 233.

import-environment VARIABLE...

Importer une, plusieurs ou toutes les variables d’environnement définies sur le client dans le bloc d’environnement du gestionnaire de systemd. Si une liste de noms de variable est passée, les valeurs côté client sont alors importées dans le bloc d’environnement du gestionnaire. Si des noms ne sont pas des noms de variable d’environnement valables ou ont des valeurs non valables conformément vis-à-vis des règles énoncées ci-dessus, une erreur apparaît. Si aucun argument n’est passé, le bloc d’environnement en entier hérité par le processus systemctl est importé. Dans ce mode toute variable d’environnement non valable héritée est silencieusement ignorée.

L’importation de tout le bloc d’environnement hérité (en appelant cette commande sans aucun argument) est obsolète. Un interpréteur de commande définira des douzaines de variables qui n’auront de sens que localement et ne seront destinées qu’aux processus enfants de l’interpréteur. De telles variables dans le bloc d’environnement global sont sources de confusion pour les autres processus.

Ajouté dans la version 206.

Commandes du gestionnaire d’état

daemon-reload

Recharger la configuration du gestionnaire systemd. Cette commande réexécutera tous les générateurs (voir systemd.generator (7)), rechargera tous les fichiers d’unité et recréera l’arbre de dépendances en entier. Lors du rechargement du démon, tous les sockets que systemd écoute relativement à la configuration de l’utilisateur resteront accessibles.

Cette commande ne doit pas être confondue avec la commande reload .

daemon-reexec

Relancer le gestionnaire systemd. Cette commande va sérialiser l’état du gestionnaire, réexécuter le processus et désérialiser l’état à nouveau. Cette commande n’a que peu d’utilité si ce n’est pour le débogage ou les mises à niveau de paquets. Parfois, elle peut être très utile pour un daemon-reload très lourd. Pendant que le démon est réexécuté, tous les sockets que systemd écoute relativement à la configuration de l’utilisateur resteront accessibles.

log-level [ NIVEAU ]

Si aucun argument n’est donné, afficher le niveau de journalisation actuel du gestionnaire. Si un argument NIVEAU est fourni en option, alors la commande change le niveau de journalisation actuel du gestionnaire à NIVEAU (en acceptant les même valeurs que --log-level= décrit dans systemd (1)).

Ajouté dans la version 244.

log-target [ CIBLE ]

Si aucun argument n’est donné, afficher la cible de journal actuelle du gestionnaire. Si un argument facultatif CIBLE est fourni, la commande change la cible de journal actuelle du gestionnaire à CIBLE (en acceptant les même valeurs que --log-target= décrit dans systemd (1)).

Ajouté dans la version 244.

service-watchdogs [yes|no]

Si aucun argument n’est donné, afficher l’état actuel des chiens de garde (watchdog) d’exécution de service du gestionnaire. Si un argument booléen facultatif est fourni, cette commande active ou désactive ces chiens de (garde WatchdogSec= ) et les actions d’urgence (par exemple, OnFailure= ou StartLimitAction= ) ; consulter systemd.service (5). Le chien de garde matériel n’est pas affecté par ce réglage.

Ajouté dans la version 244.

Commandes du système

is-system-running

Vérifier si le système est opérationnel. Cette commande renvoie succès (code de retour 0 ) lorsque le système est pleinement opérationnel et en fonctionnement, et plus particulièrement pas en mode démarrage, fermeture ou maintenance, et sans services en échec. Un échec est renvoyé dans le cas contraire (code de retour différent de zéro). De plus, l’état actuel est affiché dans une courte chaîne dans la sortie standard, voir la table ci-dessous. Utiliser --quiet pour supprimer cette sortie.

Utiliser --wait pour attendre que le processus d’amorçage (boot) soit terminé avant d’afficher l’état actuel et renvoyer l’état d’erreur approprié. Si --wait est utilisé, les états initializing ou starting ne seront pas rapportés, et la commande bloquera jusqu’à ce qu’un état postérieur (tel que running ou degraded ) soit atteint.

Table 4. Sortie is-system-running

Ajouté dans la version 215.

default

Entrer dans le mode par défaut. Cette commande est équivalente à systemctl isolate default.target . Cette opération est bloquante par défaut, utilisez --no-block pour demander un comportement asynchrone.

rescue

Entrer dans le mode de secours. Cette commande est équivalente à systemctl isolate rescue.target . Cette opération est bloquante par défaut, utilisez --no-block pour demander un comportement asynchrone.

emergency

Entrer dans le mode d’urgence. Cette commande est équivalente à systemctl isolate emergency.target . Cette opération est bloquante par défaut, utilisez --no-block pour demander un comportement asynchrone.

halt

Éteindre et arrêter le système. Cette commande est quasiment équivalente à systemctl start halt.target --job-mode=replace-irreversibly --no-block , mais affiche aussi un message à tous les utilisateurs. Cette commande est asynchrone et rendra la main après que l’opération d’arrêt aura été mise dans la file d’attente sans attendre qu’elle soit terminée. À noter que cette opération arrêtera juste le noyau du système d’exploitation après l’extinction, laissant le matériel sous tension. Utilisez systemctl poweroff pour mettre hors tension le système (voir ci-dessous).

Si combinée avec --force , l’extinction de tous les services est ignorée, cependant tous les processus sont tués et tous les systèmes de fichiers sont démontés ou montés en lecture seule, l’arrêt du système intervenant immédiatement après. Si --force est indiqué deux fois, l’opération est exécutée immédiatement sans terminer aucun processus ni démonter un quelconque système de fichiers. Il est alors à craindre une perte de données. Remarquez que lorsque --force est indiqué deux fois, l’opération d’arrêt est exécutée par systemctl lui-même, et le gestionnaire du système n’est pas contacté. Cela signifie que la commande devrait réussir même lorsque le gestionnaire du système a planté.

Si combinée avec --when= , l’extinction sera prévue après l’horodatage donné, et --when=cancel annulera l’extinction.

poweroff

Éteindre et mettre hors tension le système. Cette commande est pratiquement l’équivalent de systemctl start poweroff.target --job-mode=replace-irreversibly --no-block , mais affiche aussi un message à tous les utilisateurs. Cette commande est asynchrone et rendra la main après que l’opération d’extinction aura été mise dans la file d’attente sans attendre qu’elle soit terminée.

Cette commande prend en compte --force et --when= d’une manière similaire à halt .

reboot

Éteindre et redémarrer le système.

Cette commande est quasiment l’équivalent de systemctl start reboot.target --job-mode=replace-irreversibly --no-block , mais affiche aussi un message à tous les utilisateurs. Cette commande est asynchrone et rendra la main après que l’opération de redémarrage a été mise en file d’attente, sans attendre qu’elle soit terminée.

Si le commutateur --reboot-argument= est donné, il sera passé comme argument en option de l’appel système reboot (2).

Les options --boot-loader-entry= , --boot-loader-menu= et --firmware-setup peuvent être utilisées pour choisir quoi faire après le redémarrage. Consulter les descriptions de ces options pour les détails.

Cette commande prend en compte --force et --when= d’une manière similaire à halt .

Si un nouveau noyau a été chargé avec kexec --load , un kexec sera exécuté à la place d’un réamorçage, sauf si « SYSTEMCTL_SKIP_AUTO_KEXEC=1 » a été défini. Si un nouveau système de fichiers racine été configuré sur « /run/nextroot/ », un soft-reboot sera exécuté au lieu d’un réamorçage, sauf si « SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1 » a été posé.

Ajouté dans la version 246.

kexec

Éteindre et réamorcer le système avec kexec . Cette commande va charger un noyau kexec s’il n’y en avait pas déjà un de chargé ou si une tentative d’en charger un a échoué. Un noyau peut être chargé très tôt dans une étape séparée, cela est particulièrement utile si une initrd personnalisée ou des options supplémentaires du noyau sont désirées. --force peut être utilisée pour continuer sans noyau kexec, c’est-à-dire, pour effectuer un réamorçage normal. L’étape finale du réamorçage est équivalente à systemctl start kexec.target --job-mode=replace-irreversibly --no-block .

Pour charger un noyau, une énumération est effectuée en suivant la Boot Loader Specification [1] , et l’entrée par défaut de l’amorçage est chargée. Pour que cette étape réussisse, le système doit utiliser l’UEFI et les entrées du chargeur d’amorçage doivent être configurées en fonction. Il est possible d’utiliser bootctl list pour énumérer les entrées de l’amorçage, consulter bootctl (1).

Cette commande est asynchrone ; elle rendra la main après que l’opération de réamorçage aura été mise en file d’attente, sans attendre qu’elle soit terminée.

Cette commande prend en compte --force et --when= de manière similaire à halt .

Si un nouveau noyau a été chargé avec kexec --load , un kexec sera exécuté lorsque reboot est appelé sauf si « SYSTEMCTL_SKIP_AUTO_KEXEC=1 » a été configuré.

soft-reboot

Éteindre et redémarrer l’espace utilisateur. C’est l’équivalent de systemctl start soft-reboot.target --job-mode=replace-irreversibly --no-block . Cette commande est asynchrone ; elle rendra la main après que l’opération de réamorçage aura été mise en file d’attente, sans attendre qu’elle soit terminée.

Cette commande prend en compte --force et --when= d’une manière similaire à halt .

Cette opération ne réamorce que l’espace utilisateur, laissant le noyau fonctionner. Voir systemd-soft-reboot.service (8) pour les détails.

Si un nouveau système de fichiers racine a été mis en place sur « /run/nextroot/ », un soft-reboot sera exécuté lorsque reboot est appelé sauf si « SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1 » a été défini.

Ajouté dans la version 254.

exit [ CODE_RETOUR ]

Demander au gestionnaire de services de quitter. Cela n’est pris en charge que pour les gestionnaires de services d’utilisateur (c’est-à-dire en conjonction avec l’option --user ) ou dans des conteneurs et sinon c’est équivalent à poweroff . Cette commande est asynchrone ; elle rendra la main après que l’opération de quitter aura été mise en file d’attente, sans attendre qu’elle soit terminée.

Le gestionnaire de services quittera avec le code retour indiqué, si CODE_RETOUR est passé.

Ajouté dans la version 227.

switch-root [ ROOT [ INIT ]]

Basculer vers un répertoire racine différent et y exécuter un nouveau processus gestionnaire de système. Cette commande est prévue pour être utilisé dans l’initrd, et fera la transition du processus gestionnaire système de initrd (c’est-à-dire le processus « init », PID 1) au processus gestionnaire système principal qui est chargé depuis le système de fichiers racine hôte actuel. Cette commande prend deux arguments : le répertoire qui devient le nouveau répertoire racine et le chemin vers le nouveau binaire du gestionnaire système sous celui-ci à exécuter en tant que PID 1. Si les deux sont omis ou que le premier est une chaine vide, c’est par défaut /sysroot/. Si le dernier est omis ou est une chaîne vide, un binaire systemd sera automatiquement recherché pour être utilisé comme gestionnaire système. Si le chemin du gestionnaire système est omis, égal à une chaîne vide ou identique au chemin du binaire systemd, l’état du processus du gestionnaire système d’initrd est passé au gestionnaire système principal, ce qui permet une introspection plus tard de l’état des services en cause dans la phase d’amorçage d’initrd.

Ajouté dans la version 206.

sleep

Mettre le système en sommeil avec suspend , hibernate , hybrid-sleep , ou suspend-then-hibernate . L’opération sommeil à utiliser est automatiquement choisie par systemd-logind.service (8). Par défaut, suspend-then-hibernate est utilisé et revient à suspend et donc hibernate n’est pas pris en charge. Se référer au réglage SleepOperation= dans logind.conf (8) pour davantage de détails. Cette commande est assynchrone, et renverra après que l’opération sommeil soit dans la file d’attente. Elle n’attendra pas le cycle sommeil/résumé pour aboutir.

Ajouté dans la version 256.

suspend

Suspendre le système. Cette commande va déclencher l’activation de l’unité cible spéciale suspend.target. Cette commande est asynchrone et rendra la main après que l’opération suspend aura été mise avec succès en file d’attente. Cette commande n’attend pas que le cycle suspend/resume soit terminé.

Si --force est spécifié et que systemd-logind renvoie une erreur pour l’opération, l’erreur sera ignorée et l’opération sera encore essayée directement avec le démarrage de l’unité cible.

hibernate

Hibernation du système. Cette commande déclenchera l’activation de l’unité cible spéciale hibernate.target. Cette commande est asynchrone et rendra la main après que l’opération d’hibernation aura été mise en file d’attente avec succès. Cette commande n’attendra pas que le cycle hibernation/dégel soit terminé.

Cette commande honore --force d’une manière similaire à suspend .

hybrid-sleep

Mettre en hibernation et suspendre le système. Cette commande déclenchera l’activation de l’unité cible spéciale hybrid-sleep.target. Cette commande est asynchrone et rendra la main après que l’opération « hybrid sleep » aura été mise en file d’attente avec succès, sans attendre que le cycle sommeil/réveil soit achevé.

Cette commande honore --force d’une manière similaire à suspend .

Ajouté dans la version 196.

suspend-then-hibernate

Suspendre le système et le mettre en hibernation lorsque la batterie est basse, ou après le délai indiqué dans systemd-sleep.conf. Cette commande activera l’unité cible spéciale suspend-then-hibernate.target. Cette commande est asynchrone et rendra la main après que l’opération « hybrid sleep » aura été mise en file d’attente avec succès, sans attendre que le cycle sommeil/réveil soit terminé.

Cette commande honore --force d’une manière similaire à suspend .

Ajouté dans la version 240.

Syntaxe de paramètre

Les commandes d’unité listées ci-dessous prennent en paramètre soit un nom unique d’unité (désigné comme UNITÉ ), soit des spécifications multiples d’unité (désignées comme MOTIF ...). Dans le premier cas, le nom de l’unité avec ou sans suffixe doit être donné. Si le suffixe n’est pas spécifié (le nom de l’unité est « abrégé »), systemctl ajoutera un suffixe adapté, « .service » par défaut, et un suffixe spécifique au type dans le cas de commandes n’agissant que sur des types spécifiques d’unité. Par exemple,

# systemctl start sshd

# systemctl start sshd.service

sont équivalents, comme le sont

# systemctl isolate default

# systemctl isolate default.target

Veuillez noter que les chemins (absolus) vers des nœuds de périphérique sont automatiquement convertis en nom d’unité de périphérique et autres chemins (absolus) pour monter les noms d’unité.

# systemctl status /dev/sda
# systemctl status /home

sont équivalents à :

# systemctl status dev-sda.device
# systemctl status home.mount

Dans le deuxième cas, les expressions génériques de type interpréteur de commande seront comparées au nom principal de toutes les unités alors en mémoire ; les noms littéraux d’unité, avec ou sans suffixe, seront traités en premier. Cela signifie qu’un nom d’unité littéral fera toujours référence à exactement une unité, mais les expressions génériques peuvent ne correspondre à aucune unité et cela n’est pas considéré comme une erreur.

Les modèles d’expressions génériques utilisent fmatch (3), donc les règles de modèles de genre interpéteur de commande s’appliquent, et « * », « ? » ou « [] » peuvent être utilisés. Consulter glob (7) pour plus de détails. Les modèles sont comparés aux noms principaux des unités alors en mémoire, et les modèles qui ne correspondent à rien sont silencieusement ignorés. Par exemple :

# systemctl stop "sshd@*.service"

stoppera toutes les instances sshd@.service. Notez que les noms d’alias d’unité et les unités qui ne sont pas en mémoire ne sont pas examinés pour l’expansion des modèles.

Pour les commandes de fichier d’unité, l’ UNITÉ indiquée doit être le nom du fichier d’unité (pouvant être abrégé, voir ci-dessus), ou le chemin absolu vers le fichier d’unité :

# systemctl enable truc.service

# systemctl link /chemin/vers/truc.service

OPTIONS

Les options suivantes sont comprises :

-t , --type=

L’argument est une liste de types d’unités, séparés par des virgules, tels que service et socket . Lorsque les unités sont listées avec list-units , list-dependencies , show ou status , seules les unités des types indiqués sont affichées. Par défaut, les unités de tous types sont affichées.

La présence de l’argument help est un cas particulier : une liste des valeurs permises sera alors affichée et le programme s’arrêtera.

--state=

L’argument est une liste, séparée par des virgules, des états LOAD, SUB ou ACTIVE d’unité. Lorsque les unités sont listées avec list-units , list-dependencies , show ou status , seules celles dans les états spécifiés sont affichées. Utilisez --state=failed ou --failed pour n’afficher que les unités en échec.

La présence de l’argument help est un cas particulier : une liste des valeurs permises sera alors affichée et le programme s’arrêtera.

Ajouté dans la version 206.

-p , --property=

Lors de l’affichage des propriétés de l’unité, de la tâche, du gestionnaire, avec la commande show , limiter l’affichage aux propriétés indiquées dans l’argument. L’argument doit être une liste de noms de propriété, séparés par des virgules, tels que « PID principal ». Sans indications, toutes les propriétés sont affichées. Si indiqué plus d’une fois, toutes les propriétés avec les noms spécifiés sont affichées. Le complètement de l’interpréteur est mis en œuvre pour les noms de propriété.

Pour le gestionnaire lui-même, systemctl show affichera toutes les propriétés disponibles, dont la plupart sont dérivées ou correspondent beaucoup aux options décrites dans systemd-system.conf (5).

Les propriétés pour les unités varient en fonction du type d’unité, alors afficher toutes les unités (même les non existantes) est une façon de lister les propriétés se rapportant à ce type. De même, afficher toutes les tâches listera toutes les propriétés se rapportant à toutes les tâches. Les propriétés pour les unités sont documentées dans systemd.unit (5) et dans les pages sur les types individuels d’unités systemd.service (5), systemd.socket (5), etc.

-P

Équivalent à --value --property= , c’est-à-dire afficher la valeur de la propriété sans le nom de la propriété ou « = ». Remarquez qu’utiliser -P une fois affectera aussi toutes les propriétés listées avec -p / --property= .

Ajouté dans la version 246.

-a , --all

Lorsqu’on liste les unités avec list-units , afficher aussi les unités inactives et celles qui suivent d’autres unités. Lors de l’affichage des propriétés de l’unité, de la tâche, du gestionnaire, afficher toutes les propriétés qu’elles soient définies ou pas.

Pour lister toutes les unités installées dans le système de fichiers, utilisez plutôt la commande list-unit-files .

Lorsqu’on liste les unités avec list-dependencies , cette option affiche récursivement les dépendances de toutes les unités dépendantes (par défaut, seules les dépendances des unités cibles sont affichées).

Lorsque utilisé avec status , afficher les messages du journal en entier, même si ceux-ci incluent des caractères non imprimables ou sont très longs. Par défaut, les champs avec des caractères non imprimables sont abrégés en « données binaires d’objet ». (Notez que le visionneur en mode terminal peut toujours protéger les caractères non imprimables.)

-r , --recursive

Lorsque les unités sont listées, afficher aussi les unités des conteneurs locaux. Les unités des conteneurs locaux seront préfixées avec le nom du conteneur, séparé par un simple caractère deux-points (« : »).

Ajouté dans la version 212.

--reverse

Afficher les dépendances inverses entre les unités avec list-dependencies , c’est-à-dire les dépendances suivantes de type WantedBy= , RequiredBy= , UpheldBy= , PartOf= , BoundBy= , au lieu de Wants= et similaires.

Ajouté dans la version 203.

--after

Avec list-dependencies , afficher les unités qui sont indiquées avant les unités indiquées. En d’autres termes, lister récursivement les unités qui suivent la dépendance After= .

Notez que toute dépendance After= est automatiquement répliquée pour créer une dépendance Before= . Les dépendances temporelles peuvent être indiquées explicitement, mais sont créées implicitement pour des unités qui sont les cibles de WantedBy= (voir systemd.target (5)) et comme résultat d’autres directives (par exemple RequiresMountsFor= ). À la fois les dépendances introduites explicitement et implicitement sont montrées avec list-dependencies .

Lorsque passé à la commande list-jobs , chaque tâche affichée indique quelles autres tâches l’attendent. Cette option peut être combinée avec --before pour afficher à la fois les tâches en attente pour chaque tâche ainsi que les tâches attendues par chaque tâche.

Ajouté dans la version 203.

--before

Avec list-dependencies , afficher les unités qui sont indiquées après l’unité indiquée. En d’autre termes, lister récursivement les unités qui suivent la dépendance Before= .

Lorsque passée à la commande list-jobs , afficher pour chaque tâche affichée quelles autres tâches elle attend. Peut être combinée avec --after pour afficher à la fois les tâches en attente pour chaque tâches et toutes les tâches attendues par chaque tâche.

Ajouté dans la version 212.

--with-dependencies

Lorsque utilisée avec status , cat , list-units et list-unit-files , ces commandes affichent toutes les unités indiquées et les dépendances de ces unités.

Les options --reverse , --after et --before peuvent être utilisées pour changer les types de dépendance à afficher.

Ajouté dans la version 245.

-l , --full

Ne pas réduire les noms d’unité, les entrées d’arbre de processus, la sortie du journal, ou tronquer les descriptions d’unité dans les sorties de status , list-units , list-jobs et list-timers .

Afficher aussi les cibles d’installation dans la sortie de is-enabled .

--value

Lors de l’affichage des propriétés avec show , n’afficher que la valeur et ignorer le nom de propriété et « = ». Voir aussi l’option -P ci-dessus.

Ajouté dans la version 198.

--show-types

Lors de l’affichage de sockets, afficher le type de socket.

Ajouté dans la version 202.

--job-mode=

Lors de la mise en file d’attente d’une nouvelle tâche, cette option contrôle comment composer avec les autres tâches déjà en attente. Elle prend une des valeurs « fail », « replace », « replace-irreversibly », « isolate », « ignore-dependencies », « ignore-requirements », « flush », « triggering » ou « restart-dependencies ». La valeur par défaut est « replace », excepté lors de l’utilisation de la commande isolate qui implique le mode de tâche « isolate ».

Si « fail » est indiqué et qu’une opération demandée est en conflit avec une tâche en attente (plus exactement qu’une tâche de démarrage déjà en attente doit s’inverser en tâche d’arrêt ou vice-versa), cela fait échouer l’opération.

Si « replace » (valeur par défaut) est indiqué, toutes les tâches en attente en conflit seront remplacées, si nécessaire.

Si « replace-irreversibly » est indiqué, agir comme « replace », mais marquer aussi les nouvelles tâches comme irréversibles. Cela anticipe de futures transactions conflictuelles de remplacement de ces tâches (ou même d’être mis en file d’attente alors que des tâches irréversibles sont encore en attente). Les tâches irréversibles peuvent toujours être annulées avec la commande cancel . Ce mode de tâche doit être utilisé sur toutes les transactions qui apparaissent dans shutdown.target.

« isolate » n’est valable que pour les opérations de démarrage et cause l’arrêt des autres unités quand l’unité indiquée est démarrée. Ce mode est toujours utilisé lorsque la commande isolate est utilisée.

« flush » causera l’annulation de toutes les tâches en file d’attente lorsque la nouvelle tâche sera mise en file d’attente.

Si « ignore-dependencies » est indiqué, toutes les dépendances d’unité sont ignorées pour cette nouvelle tâche et l’opération est exécutée immédiatement. Si passée, aucune unité requise de l’unité passée ne sera appellée et aucune dépendance d’ordre de déroulement ne sera honorée. Cela est surtout un outil de l’administrateur pour le débogage et le sauvetage et ne devrait pas être utilisé par les applications.

« ignore-requirements » est similaire à « ignore-dependencies », mais fait seulement que les dépendances requises soient ignorées, alors que les dépendances d’ordre de déroulement seront quand même honorées.

« triggering » ne devrait être utilisé qu’avec systemctl stop . Dans ce mode, l’unité indiquée et toute unité active qui la déclenche sont stoppées. Voir la discussion sur Triggers= dans systemd.unit (5) pour plus d’informations sur les unités de déclenchement.

« restart-dependencies » ne peut être utilisé qu’avec systemctl start . Dans ce mode, les dépendances de l’unité indiquée recevront une propagation de demande de redémarrage comme si une tâche de redémarrage avait été mise en liste d’attente pour l’unité.

Ajouté dans la version 206.

-T , --show-transaction

Lors de la mise en file d’attente d’une tâche d’unité (par exemple comme effet de l’invocation de systemctl start ou similaire), afficher une brève information sur toutes les tâches en file d’attente, couvrant à la fois la tâche demandée et celles ajoutées à cause des dépendances d’unité. Remarquez que la sortie n’inclura que les tâches qui font immédiatement partie de la transaction demandée. Il se peut que le code du programme du service de démarrage exécuté comme effet des tâches en file d’attente puisse demander d’activer d’autres tâches. Cela signifie que le complètement des tâches listées peut ultérieurement impliquer plus de tâches que celles listées.

Ajouté dans la version 242.

--fail

Raccourci pour --job-mode= fail.

Lorsque utilisé avec la commande kill , si aucune unité n’est tuée, l’opération provoque une erreur.

Ajouté dans la version 227.

--check-inhibitors=

Lorsque le système demande un état shutdown ou sleep, cette option contrôle la vérification des verrous inhibiteurs, les valeurs possibles sont « auto », « yes » ou « no ». Par défaut c’est « auto », ce qui signifie que logind effectuera la vérification et respectera les verrous inhibiteurs actifs, mais que systemctl n’effectuera une vérification côté client que pour les invocations interactives (c’est-à-dire depuis une console TTY), de manière qu’une erreur plus informative et compréhensible soit renvoyée à l’utilisateur. « no » désactive à la fois les vérifications de systemctl et de logind.

Les applications peuvent établir des verrous inhibiteurs pour éviter l’interruption de certaines opérations importantes (comme la gravure d’un CD) par un arrêt ou une hibernation du système. Tous les utilisateurs peuvent poser ces verrous et les utilisateurs privilégiés peuvent outrepasser ces verrous. Si des verrous sont posés, les demandes d’arrêt et sommeil devraient normalement échouer (à moins d’être outrepassés explicitement avec « no »).

L’option --force fournit un autre moyen de passer outre les inhibiteurs.

Ajouté dans la version 248.

-i

Raccourci pour --check-inhibitors=no .

Ajouté dans la version 198.

--dry-run

Seulement afficher ce qui doit être fait. Actuellement pris en charge par les termes halt , poweroff , reboot , kexec , suspend , hibernate , hybrid-sleep , suspend-then-hibernate , default , rescue , emergency et exit .

Ajouté dans la version 236.

-q , --quiet

Supprimer l’affichage des résultats des diverses commandes et aussi les notes à propos des lignes de journal tronquées. Cette option ne supprime pas la sortie des commandes pour lesquelles la sortie affichée est le seul résultat (comme show ). Les erreurs sont toujours affichées.

--no-warn

Ne pas générer les avertissements affichés par défaut dans les cas suivants :

• lorsque systemctl est invoqué sans procfs monté sur /proc/ ;

• lors de l’utilisation de enable ou disable sur des unités sans informations d’installation (c’est-à-dire ayant ou n’ayant pas une section [Install] vide),

• lors de l’utilisation de disable combinée avec --user sur des unités activées pour une portée globale,

• lorsqu’une unité affectée par les commandes stop , disable ou mask a encore des unités de déclenchement actives.

• lorsqu’un fichier d’unité est changé et nécessite daemon-reload .

Ajouté dans la version 253.

--no-block

Ne pas attendre de manière synchrone que l’opération demandée finisse. Si cette option n’est pas indiquée, la tâche sera vérifiée, mise en file d’attente et systemctl attendra que le démarrage de l’unité soit terminé. En passant cet argument, elle est seulement vérifiée et mise en file d’attente. Cette option ne doit pas être combinée avec wait .

--wait

Lorsqu’utilisé avec start ou restart , attendre de manière synchrone que les unités démarrées se terminent de nouveau. Cette option ne doit pas être combinée avec --no-block . Remarquez que l’attente peut s’éterniser si une unité donnée ne termine jamais (d’elle-même ou en étant stoppée explicitement) ; particulièrement les services qui utilisent « RemainAfterExit=yes ».

Lorsque utilisée avec is-system-running , attendre que le processus d’amorçage soit terminé avant de rendre la main.

Lorsqu’utilisé avec kill , attendre que l’unité signalée termine. Notez que cela attendra indéfiniment si aucune unité donnée ne termine jamais.

Ajouté dans la version 232.

--user

Échanger avec le manager de service de l’utilisateur appelant plutôt qu’au manager de service du système.

--system

Échanger avec le manager de service du système. C’est la valeur implicite par défaut.

--failed

Lister les unités en état d’échec. Cette option est équivalente à --state=failed .

Ajouté dans la version 233.

--no-wall

Ne pas envoyer de message wall avant l’arrêt, l’extinction et le redémarrage.

--global

Lorsque utilisée avec enable et disable , opérer sur le répertoire de la configuration globale de l’utilisateur, activant ou désactivant ainsi globalement un fichier d’unité pour les connexions futures de tous les utilisateurs.

--no-reload

Lorsque utilisée avec enable , disable , preset , mask ou unmask , ne pas recharger implicitement la configuration du démon après avoir exécuté les modifications.

--kill-whom=

Lorsque utilisée avec kill , choisir à quels processus envoyer un signal de processus UNIX. Les valeurs possibles sont main , control ou all pour sélectionner s’il faut tuer seulement le processus principal, le processus de contrôle ou tous les processus de l’unité. Le processus principal de l’unité est celui qui en définit la durée de vie. Le processus de contrôle d’une unité est celui qui est appelé par le gestionnaire pour y induire un changement d’état. Par exemple, tous les processus démarrés en raison des réglages d’unités de service ExecStartPre= , ExecStop= ou ExecReload= sont des processus de contrôle. Notez qu’il n’y a qu’un processus de contrôle par unité à la fois, de même qu’un seul changement d’état est exécuté à la fois. Pour les services du type Type=forking , le processus initial démarré par le gestionnaire pour ExecStart= est un processus de contrôle, tandis que le processus ultérieurement fourché par celui-ci est alors considéré comme processus principal de l’unité (s’il peut être déterminé). Cela est différent pour les unités de service d’autres types, où le processus fourché par le gestionnaire pour ExecStart= est toujours le processus principal lui-même. Une unité de service consiste en aucun ou un processus principal, aucun ou un processus de contrôle plus un certain nombre de processus supplémentaires. Tous les types d’unité ne gèrent cependant pas les processus de ces types. Par exemple, pour les unités de montage les processus de contrôle sont définis (ce sont les appels à /usr/bin/mount et /usr/bin/umount), mais aucun processus principal n’est défini. S’il est omis, c’est par défaut all .

Ajouté dans la version 252.

--kill-value= INT

Si utilisé avec la commande kill , mettre un signal en file d’attente ainsi que la valeur entière indiquée comme paramètre pour le(s) processus spécifié(s). Cette opération n’est possible que pour les signaux POSIX en temps réel (c’est-à-dire --signal=SIGRTMIN+... ou --signal=SIGRTMAX-... ), et assure que les signaux sont générés par l’appel système sigqueue (3) plutôt que par kill (3). La valeur indiquée doit être un entier signé 32 bits et doit être indiquée en décimal, en hexadécimal (si préfixée avec « 0x »), en octal (si préfixée avec « 0o »), ou en binaire (si préfixée avec « 0b »).

Si cette option est utilisée, le signal ne sera mis en file d’attente que pour le processus principal ou de contrôle de l’unité, jamais pour d’autres processus de l’unité, c’est-à-dire --kill-whom=all n’affectera que les processus de contrôle et principal et pas les autres processus.

Ajouté dans la version 254.

-s , --signal=

Lorsque utilisée avec kill , choisir quel signal sera envoyé aux processus sélectionnés. Il doit s’agir d’un des indicateurs de signal bien connus tel que SIGTERM , SIGINT ou SIGSTOP . Si omis, le signal est SIGTERM par défaut.

La valeur spéciale « help » va lister les valeurs connues et le programme s’arrêtera immédiatement ; la valeur spéciale « list » listera les valeurs connues avec leur numéro de signal et le programme quittera immédiatement.

--what=

Sélectionner quel type de ressource par unité à supprimer lorsque la commande clean est passée, voir ci-dessus. Les valeurs possibles sont configuration , state , cache , logs , runtime ou fdstore pour choisir le type de ressources. Cette option peut être indiquée plus d’une fois, auquel cas tous les types de ressource indiqués sont supprimés. Est aussi acceptée la valeur spéciale -all comme raccourci pour indiquer les six types de ressources. Si cette option n’est pas indiquée, ce sera, par défaut, une combinaison de -cache , -runtime et fdstore , c’est-à-dire les trois sortes de ressources qui sont généralement considérées comme redondantes et qui peuvent être reconstruites lors de prochains appels. Notez que la suppression explicite du type de ressource fdstore n’est utile que si l’option FileDescriptorStorePreserve= est activée, puisque le magasin de descripteur de fichier est autrement nettoyé automatiquement quand l’unité est stoppée.

Ajouté dans la version 243.

-f , --force

Lorsque utilisée avec enable , écraser tout lien symbolique conflictuel existant.

Quand utilisée avec edit , créer toutes les unités indiquées qui n’existent pas déjà.

Lorsqu’utilisé avec suspend , hibernate , hybrid-sleep ou suspend-then-hibernate , l’erreur renvoyée par systemd-logind sera ignorée, et l’opération sera effectuée directement lors du démarrage des unités correspondantes.

Lorsque utilisée avec halt , poweroff , reboot ou kexec , exécuter l’opération indiquée sans éteindre toutes les unités. Néanmoins, tous les processus seront tués de force et tous les systèmes de fichiers seront démontés ou remontés en lecture seule. Il s’agit par conséquent d’une option assez radicale, mais relativement sûre pour demander un réamorçage immédiat. Si --force est indiquée deux fois pour ces opérations (avec une exception pour kexec ), elles seront exécutées immédiatement sans terminer aucun processus ni démonter de système de fichiers.

Warning
Indiquer deux fois --force pour l’une de ces opérations peut résulter en une perte de données. Remarquez que quand --force est indiquée deux fois, l’opération sélectionnée est exécutée par systemctl lui-même et le gestionnaire de système n’est pas contacté. Cela signifie que la commande devrait réussir même lorsque le gestionnaire du système a planté.

--message=

Lorsque utilisée avec halt , poweroff ou reboot , présenter un court message expliquant la raison de l’opération. Le message sera journalisé avec le message d’extinction par défaut.

Ajouté dans la version 225.

--now

Lorsque utilisée avec enable , disable , mask ou reenable , effectue aussi un démarrage/arrêt/essai de redémarrage des unités (start/stop/try-restart) après l’exécution des opérations du fichier de l’unité indiquée.

Ajouté dans la version 220.

--root=

Lorsque utilisée avec enable / disable / is-enabled (ou commandes assimilées), utiliser le chemin racine indiqué pour chercher des fichiers d’unité. Si cette option est présente, systemctl agira directement sur le système de fichiers au lieu de communiquer avec le démon systemd pour effectuer les changements.

--image= image

Cette option prend pour valeur un chemin vers un fichier d’image disque ou un nœud de périphérique bloc. Si elle est définie, toutes les opérations sont appliquées au système de fichiers dans l’image disque indiquée. Cette option est similaire à root= , mais opère sur les systèmes de fichiers stockés dans des images disque ou des périphériques blocs. L’image disque peut contenir seulement un système de fichiers ou un ensemble de systèmes de fichiers dans une table de partition GPT, en accord avec la Discoverable Partitions Specification [2] . Pour plus d’informations sur les images disque prises en charge, voir le commutateur (switch) de systemd-nspawn (1) du même nom.

Ajouté dans la version 252.

--image-policy= politique

Cette option prend pour argument une image de chaine de politique, comme pour systemd.image-policy (7). La politique est imposée lors d’une opération sur l’image disque indiquée par --image= , voir ci-dessus. C’est par défaut la politique « * » si rien n’est indiqué, c’est-à-dire tous les systèmes de fichiers reconnus de l’image sont utilisés.

--runtime

Lorsque utilisée avec enable , disable , edit (et les commandes en relation), n’appliquer les changements que de manière temporaire, de manière qu’ils soient perdus lors de l’amorçage suivant. Cela a pour effet que les changements ne sont pas fait dans les sous-répertoires de /etc mais dans /run, avec des effets immédiats identiques ; cependant, comme /run est perdu lors du réamorçage, les changements sont perdus aussi.

De façon similaire, lorsque utilisée avec set-property , appliquer les changements seulement temporairement, de façon qu’ils soient perdus au réamorçage suivant.

--preset-mode=

Cette option prend pour valeur un des modes « full » (par défaut), « enable-only » ou « disable-only ». Lorsque utilisée avec les commandes preset ou preset-all , contrôler quelles unités devraient être désactivées et activées en accord avec les règles prédéfinies, ou seulement activées ou désactivées.

Ajouté dans la version 215.

-n , --lines=

Lorsque utilisée avec status , contrôler le nombre de lignes du journal à afficher, en comptant depuis les plus récentes. Cette option prend pour valeur un entier positif ou 0 pour désactiver la sortie du journal ; La valeur par défaut est 10 .

-o , --output=

Lorsque utilisée avec status , contrôler le formatage des entrées du journal qui sont affichées. Pour les choix disponibles, voir journalctl (1). Le choix par défaut est « short ».

--firmware-setup

Lorsque utilisée avec la commande reboot , poweroff ou halt , indiquer au micrologiciel du système de redémarrer dans l’interface de configuration du micrologiciel au prochain démarrage. Notez que cette fonction n’est pas disponible sur tous les systèmes.

Ajouté dans la version 220.

--boot-loader-menu= délai

Lorsque utilisée avec la commande reboot , poweroff ou halt indiquer au chargeur d’amorçage du système d’afficher le menu du chargeur d’amorçage lors des démarrages suivants. Prendre une valeur de temps comme paramètre — indiquant la temporisation du menu. Passer zéro pour désactiver la temporisation du menu. Notez que les chargeurs d’amorçage ne gèrent pas tous cette fonctionnalité.

Ajouté dans la version 242.

--boot-loader-entry= ID

Lorsque utilisée avec la commande reboot , poweroff ou halt indiquer au chargeur de démarrage du système d’amorcer dans une entrée de chargeur de démarrage indiqué lors du prochain amorçage. Cette option prend pour valeur un identifiant d’entrée de chargeur d’amorçage comme argument, ou « help » pour lister les entrées disponibles. Notez que les chargeurs d’amorçage ne gèrent pas tous cette fonctionnalité.

Ajouté dans la version 242.

--reboot-argument=

Cette commande est utilisée avec reboot . La valeur est spécifique au micrologiciel et à l’architecture. Par exemple, « recovery » pourrait être utilisée pour déclencher la récupération du système, et « fota » (« firmware over the air ») pourrait être utilisée pour déclencher les mises à jour à distance.

Ajouté dans la version 246.

--plain

Lorsque utilisée avec list-dependencies , list-units ou list-machines , la sortie est affichée sous forme de liste plutôt que d’arbre et les puces rondes sont omises.

Ajouté dans la version 203.

--timestamp=

Changer le format des horodatages affichés. Les valeurs suivantes peuvent être utilisées :

pretty (valeur par défaut)

"Jour YYYY-MM-DD HH:MM:SS TZ"

Ajouté dans la version 248.

unix

"@secondes-depuis-époque-UNIX"

Ajouté dans la version 251.

us , μs

"Jour YYYY-MM-DD HH:MM:SS.UUUUUU TZ"

Ajouté dans la version 248.

utc

"Jour YYYY-MM-DD HH:MM:SS UTC"

Ajouté dans la version 248.

us+utc , μs+utc

"Jour YYYY-MM-DD HH:MM:SS.UUUUUU UTC"

Ajouté dans la version 248.

Ajouté dans la version 247.

--mkdir

Lorsque utilisée avec bind , créer le répertoire ou le fichier de destination avant d’appliquer le montage bind. Remarquez que même si le nom de cette option suggère qu’elle n’est appropriée que pour les répertoires, cette option créée aussi le nœud de fichier de destination sur lequel faire le montage si l’objet à monter n’est pas un répertoire, mais un fichier classique, un nœud de périphérique, un socket ou une file FIFO.

Ajouté dans la version 248.

--marked

Seulement permise avec reload-or-restart . Mettre en file d’attente les tâches de redémarrage pour toutes les uités qui sont marquées « needs-restart » et recharger les tâches pour les unités qui sont marquées « needs-reload ». Lorsqu’une unité marquée pour le rechargement ne gère pas le rechargement, le redémarrage sera mis en file d’attente. Ces propriétés peuvent être définies en utilisant set-property Markers=... .

À moins que --no-block ne soit utilisé, systemctl attendra que les tâches dans la file soient terminées.

Ajouté dans la version 248.

--read-only

Lorsque utilisée avec bind , créer un montage bind en lecture seule.

Ajouté dans la version 248.

--drop-in= NOM

Lorsque utilisée avec edit , utiliser NOM comme nom de fichier de remplacement au lieu de override.conf.

Ajouté dans la version 253.

--when=

Lorsque utilisée avec halt , poweroff , reboot ou kexec , programmer l’action pour être effectuée à l’horodatage donné, qui doit être de la même syntaxe que celle documentée dans la section « PARSING TIMESTAMPS » de systemd.time (7). Particulièrement si « show » est donné, l’action programmée actuellement sera montrée, ce qui peut être annulé en passant une chaîne vide ou « cancel ». « auto » programmera l’action en fonction de la fenêtre de maintenance ou après un délai d’une minute.

Ajouté dans la version 254.

--stdin

Lorqu’utilisé avec edit , le contenu du fichier sera lu depuis l’entrée standard et l’éditeur ne sera pas lancé. Dans ce mode, l’ancien contenu du fichier est complètement remplacé. Cela est utile pour « éditer » des fichiers d’unité dans des scripts :

$ systemctl edit --drop-in=limits.conf --stdin some-service.service <<EOF
[Unit]
AllowedCPUs=7,11
EOF

Différents drop-ins peuvent être « édités » dans ce mode ; le même contenu sera écrit dans chacun d’entre eux.

Ajouté dans la version 256.

-H , --host=

Effectuer l’opération à distance. Indiquer 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 d’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 spécifié. SSH sera utilisé pour dialoguer avec l’instance du gestionnaire de la machine distante. Les noms de conteneur peuvent être énumérés avec machinectl -H HÔTE . Mettre les adresses IPv6 entre crochets.

-M , --machine=

Effectuer l’opération dans un conteneur local. Préciser le nom d’un conteneur auquel se connecter, optionnellement préfixé par le nom d’utilisateur 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 au bus utilisateur d’un utilisateur particulier : « --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.

-C , --capsule=

Exécuter l’opération en capsule. Indiquer un nom de capsule auquel se connecter_&. Voir capsule@.service (5) pour les détails sur les capsules.

Ajouté dans la version 256.

--no-ask-password

Ne pas demander à l’utilisateur de s’authentifier pour les opérations requérant des privilèges.

--no-pager

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

--legend= BOOL

Activer ou désactiver l’affichage de la légende, c’est-à-dire les en-têtes de colonne et les bas de page avec les notes. La légende est affichée par défaut, à moins qu’elle ne soit désactivée avec --quiet ou similaire.

-h , --help

Afficher un aide-mémoire succinct et quitter.

--version

Afficher une information de version courte et quitter.

CODE DE RETOUR

En cas de succès, 0 est renvoyé, autrement, un code d’échec différent de zéro est renvoyé.

systemctl utilise les codes de retour définis par LSB, comme définis dans LSB 3.0.0 [3] .

Table 5. codes de retour LSB

Le mappage des états de services LSB aux états d’unités systemd est imparfait, donc il vaut mieux ne pas tenir compte des valeurs renvoyées, mais plutôt regarder les états et sous-états d’unité particulière.

ENVIRONNEMENT

$SYSTEMD_EDITOR

Éditeur à utiliser pour éditer des unités ; écrase $EDITOR et $VISUAL . Si ni $SYSTEMD_EDITOR , ni $EDITOR , ni $VISUAL ne sont présents ou si cette variable est définie par une chaîne vide ou si leur exécution a échoué, systemctl essaiera d’exécuter les éditeurs bien connus dans cet ordre : editor (1), nano (1), vim (1), vi (1).

Ajouté dans la version 218.

$SYSTEMD_LOG_LEVEL

Le niveau maximal de journalisation de messages émis (messages avec un niveau de journalisation supérieur, c’est-à-dire les moins importants seront supprimés). Cette variable prend une liste de valeurs séparées par des virgules. Une valeur peut être (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 davantage d’informations. Chaque valeur peut être optionnellement préfixée avec console , syslog , kmsg ou journal suivi d’un deux-points ( : ) pour définir le niveau de journalisation maximal pour la cible spécifique de journal (par exemple SYSTEMD_LOG_LEVEL=debug,console:info indique de journaliser au niveau debug excepté 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 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_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_PAGER , $PAGER

Afficheur à utiliser lorsque --no-pager n’est pas précisé. $SYSTEMD_PAGER est utilisé s’il est défini ; autrement, $PAGER est utilisé. 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 ces variables 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 et $PAGER ne peuvent être utilisés que pour désactiver l’afficheur (avec « cat » ou « "" ») et autrement seront ignorés.

$SYSTEMD_LESS

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

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

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.

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.

Notez que le réglage 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 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).

Notez que le réglage 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-à-dire le défilement de la sortie, prennent en charge l’ouverture et l’écriture d’autres fichiers et l’exécution de commandes d’interpréteur arbitraires. Quand les commandes sont invoquées avec des privilèges élevés, par exemple sous sudo (8) ou pkexec (1), l’afficheur devient une limite de sécurité. Il convient de veiller à ce que seuls des programmes avec des fonctionnalités strictement limitées soient utilisés comme afficheurs et que les fonctionnalités comme l’ouverture ou la création de nouveaux fichiers ou le démarrage de sous-processus ne soient pas autorisées. Un « mode sécurisé » pour l’afficher peut être activé comme décrit ci-dessous, si l’afficheur le prend en charge≤ (la plupart des afficheurs ne sont pas écrits de façon à prendre cela en considération). Il est recommandé soit d’activer explicitement le « mode sécurisé » soit de désactiver complètement l’afficheur en utilisant --no-pager ou PAGER=cat lorsque des utilisateurs non fiables sont autorisés à exécuter des commandes avec des privilèges élevés.

Cette option prend un argument booléen. Lorsqu’elle est définie à vrai, le « mode sécurisé » de l’afficheur est activé. En « mode sécurisé », LESSSECURE=1 est défini lors de l’invocation de l’afficheur, ce qui lui indique de désactiver les commandes qui ouvrent ou créent des fichiers, ou qui démarrent un nouveau sous-processus. Actuellement, seul less (5) est connu pour comprendre cette variable et implémenter le « mode sécurisé ».

Quand l’option est définie à faux, aucune limitation n’est imposée à l’afficheur. Définir SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de l’environnement hérité peut permettre à l’utilisateur d’invoquer des commandes arbitraires.

Quand $SYSTEMD_PAGERSECURE n’est pas défini, les outils de systemd tentent de déterminer automatiquement si le « mode sécurisé » doit être activé et si l’afficheur le prend en charge. Le « mode sécurisé » est activé si l’UID effectif est différent de celui du propriétaire de la session de connexion (voir geteuid (2)) et sd_pid_get_owner_uid (3)) ou lors de l’exécution sous sudo (8) ou des outils similaires ( $SUDO_UID est défini à [8] ). Dans ces cas, SYSTEMD_PAGERSECURE=1 sera défini et les afficheurs qui ne sont pas connus pour implémenter le « mode sécurisé » ne seront pas du tout utilisés. Notez que cette détection automatique ne couvre que les mécanismes les plus courants d’élévation des privilèges et qu’elle est conçue pour faciliter la tâche. Il est recommandé de définir explicitement $SYSTEMD_PAGERSECURE ou de désactiver l’afficheur.

Notez que si les variables $SYSTEMD_PAGER ou $PAGER doivent être respectées, sauf pour désactiver l’afficheur, $SYSTEMD_PAGERSECURE doit aussi être défini.

$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.

VOIR AUSSI

systemd (1), journalctl (1), loginctl (1), machinectl (1), systemd.unit (5), systemd.resource-control (5), systemd.special (7), wall (1), systemd.preset (5), systemd.generator (7), glob (7)

NOTES

Caractéristiques du chargeur de démarrage

https://uapi-group.org/specifications/specs/boot_loader_specification

Spécification des partitions détectables

https://uapi-group.org/specifications/specs/discoverable_partitions_specification

LSB 3.0.0

http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html

Il est recommandé pour les autres outils de définir et vérifier $SUDO_UID comme il convient, en le considérant comme une interface courante.

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