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

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
┌──────────────┬───────────────────────────────────────┐
│ État │ Description │
├──────────────┼───────────────────────────────────────┤
│ active │ Démarrée, liée, branchée,..., suivant │
│ │ le type d'unité. │
├──────────────┼───────────────────────────────────────┤
│ inactive │ Stoppée, non liée, débranchée,..., │
│ │ suivant le type d'unité. │
├──────────────┼───────────────────────────────────────┤
│ failed │ Similaire à inactive, mais l'unité a │
│ │ échoué quelque part (processus │
│ │ renvoyant un code d'erreur, plantage, │
│ │ opération expirée ou après trop de │
│ │ redémarrages). │
├──────────────┼───────────────────────────────────────┤
│ activating │ Modification d'inactive en active. │
├──────────────┼───────────────────────────────────────┤
│ deactivating │ Modification d'active en inactive. │
├──────────────┼───────────────────────────────────────┤
│ maintenance │ L'unité est inactive et une opération │
│ │ d'entretien est en cours. │
├──────────────┼───────────────────────────────────────┤
│ reloading │ L'unité est active et est en cours de │
│ │ recharge de configuration. │
├──────────────┼───────────────────────────────────────┤
│ refreshing │ L'unité est active et un nouveau │
│ │ montage a été activé dans son espace │
│ │ de noms.. │
└──────────────┴───────────────────────────────────────┘

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 --allGLOB 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=
┌──────────────────┬───────────────────────────────────────┐
│ Valeur │ Réglage d'unité │
├──────────────────┼───────────────────────────────────────┤
│ "fonctionnement" │ RuntimeDirectory= │
├──────────────────┼───────────────────────────────────────┤
│ "état" │ StateDirectory= │
├──────────────────┼───────────────────────────────────────┤
│ "cache" │ CacheDirectory= │
├──────────────────┼───────────────────────────────────────┤
│ "logs" │ LogsDirectory= │
├──────────────────┼───────────────────────────────────────┤
│ "configuration" │ ConfigurationDirectory= │
├──────────────────┼───────────────────────────────────────┤
│ "fdstore" │ FileDescriptorStorePreserve= │
├──────────────────┼───────────────────────────────────────┤
│ "all" │ Tout ce qui est ci-dessus │
├──────────────────┼───────────────────────────────────────┤
│ "help" │ Afficher les valeurs prises en charge │
│ │ et quitter │
└──────────────────┴───────────────────────────────────────┘

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
┌───────────────────┬──────────────────────────────┬────────────────┐
│ Nom │ Description │ Code de retour │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "enabled" │ Activé à l'aide de .wants/, │ │
├───────────────────┤ .requires/ ou de liens │ │
│ "enabled-runtime" │ symboliques Alias= (en │ │
│ │ permanence dans │ 0 │
│ │ /etc/systemd/system/ ou │ │
│ │ transitoirement dans │ │
│ │ /run/systemd/system/). │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "linked" │ Rendu disponible à l'aide │ │
├───────────────────┤ d'un ou plusieurs liens │ │
│ "linked-runtime" │ symboliques vers le fichier │ │
│ │ d'unité (en permanence dans │ │
│ │ /etc/systemd/system ou │ │
│ │ transitoirement dans │ > 0 │
│ │ /run/systemd/system/), même │ │
│ │ si le fichier d'unité se │ │
│ │ situe en dehors du chemin de │ │
│ │ recherche du fichier │ │
│ │ d'unité. │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "alias" │ Le nom est un alias (lien │ 0 │
│ │ symbolique vers un autre │ │
│ │ fichier d'unité). │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "masked" │ Complètement désactivé, de │ │
├───────────────────┤ façon à ce que toute │ │
│ "masked-runtime" │ tentative de le démarrer │ │
│ │ échoue (de manière │ > 0 │
│ │ permanente dans │ │
│ │ /etc/systemd/system/ ou │ │
│ │ transitoire dans │ │
│ │ /run/systemd/systemd/). │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "static" │ Le fichier d'unité n'est pas │ 0 │
│ │ activé et n'a pas de │ │
│ │ modalité pour être activé │ │
│ │ dans la section [Install] du │ │
│ │ fichier d'unité. │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "indirect" │ Le fichier d'unité lui-même │ 0 │
│ │ n'est pas activé, mais il a │ │
│ │ une définition Also= non │ │
│ │ vide dans la section │ │
│ │ [Install] du fichier d'unité │ │
│ │ listant d'autres fichiers │ │
│ │ d'unité qui peuvent être │ │
│ │ activés, ou possède un alias │ │
│ │ sous un nom différent à │ │
│ │ travers un lien symbolique │ │
│ │ qui n'est pas indiqué dans │ │
│ │ Also=. Pour les fichiers │ │
│ │ d'unité modèle, une instance │ │
│ │ différente de celle indiquée │ │
│ │ dans DefaultInstance= est │ │
│ │ activée. │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "disabled" │ Le fichier d'unité n'est pas │ > 0 │
│ │ activé, mais contient une │ │
│ │ section [Install] avec des │ │
│ │ instructions d'installation. │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "generated" │ Le fichier de l'unité a été │ 0 │
│ │ généré dynamiquement par un │ │
│ │ outil générateur. Consulter │ │
│ │ systemd.generator(7). Les │ │
│ │ fichiers d'unité générés │ │
│ │ peuvent ne pas être activés, │ │
│ │ ils sont activés │ │
│ │ implicitement par leur │ │
│ │ générateur. │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "transient" │ Le fichier d'unité a été │ 0 │
│ │ créé dynamiquement par l’API │ │
│ │ d'exécution. Les fichiers │ │
│ │ transitoires peuvent ne pas │ │
│ │ être activés. │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "bad" │ Le fichier d'unité n'est pas │ > 0 │
│ │ valable ou une autre erreur │ │
│ │ est survenue. Notez que │ │
│ │ is-enabled ne renverra pas │ │
│ │ réellement cet état, mais │ │
│ │ affichera un message │ │
│ │ d'erreur à la place. │ │
│ │ Cependant, le listing de │ │
│ │ fichiers d'unité affiché par │ │
│ │ list-unit-files devrait le │ │
│ │ montrer. │ │
├───────────────────┼──────────────────────────────┼────────────────┤
│ "not-found" │ Le fichier d'unité n'existe │ 4 │
│ │ pas. │ │
└───────────────────┴──────────────────────────────┴────────────────┘

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
┌──────────────┬──────────────────────────────┬────────────────┐
│ Nom │ Description │ Code de retour │
├──────────────┼──────────────────────────────┼────────────────┤
│ initializing │ Début de l'amorçage, avant │ > 0 │
│ │ que basic.target ne soit │ │
│ │ atteint ou ne soit entré en │ │
│ │ état de maintenance. │ │
├──────────────┼──────────────────────────────┼────────────────┤
│ starting │ Fin du démarrage, avant que │ > 0 │
│ │ la file d'attente des tâches │ │
│ │ ne devienne inoccupée pour │ │
│ │ la première fois, ou que │ │
│ │ l'une des cibles de secours │ │
│ │ ne soit atteinte. │ │
├──────────────┼──────────────────────────────┼────────────────┤
│ running │ Le système est pleinement │ 0 │
│ │ opérationnel. │ │
├──────────────┼──────────────────────────────┼────────────────┤
│ degraded │ Le système est opérationnel │ > 0 │
│ │ mais une ou plusieurs unités │ │
│ │ sont en échec. │ │
├──────────────┼──────────────────────────────┼────────────────┤
│ maintenance │ La cible de secours ou │ > 0 │
│ │ d'urgence est active. │ │
├──────────────┼──────────────────────────────┼────────────────┤
│ stopping │ Le gestionnaire s'éteint. │ > 0 │
├──────────────┼──────────────────────────────┼────────────────┤
│ offline │ Le gestionnaire ne │ > 0 │
│ │ fonctionne pas. Plus │ │
│ │ exactement, c'est l'état │ │
│ │ opérationnel si un programme │ │
│ │ incompatible fonctionne en │ │
│ │ tant que gestionnaire │ │
│ │ système (PID 1). │ │
├──────────────┼──────────────────────────────┼────────────────┤
│ unknown │ L'état opérationnel ne peut │ > 0 │
│ │ pas être déterminé, suite à │ │
│ │ un manque de ressources ou │ │
│ │ d'une autre cause d’erreur. │ │
└──────────────┴──────────────────────────────┴────────────────┘

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
       ┌────────┬──────────────────────────────┬────────────────────────────┐
       │ Valeur │ Description dans LSB         │ Usage dans systemd         │
       ├────────┼──────────────────────────────┼────────────────────────────┤
       │ 0      │ "le programme est en         │ l'unité est active         │
       │        │ fonctionnement ou le service │                            │
       │        │ est OK"                      │                            │
       ├────────┼──────────────────────────────┼────────────────────────────┤
       │ 1      │ "le programme est mort et un │ l'unité n'est pas en échec │
       │        │ fichier pid var/run existe"  │ (utilisée par is-failed)   │
       ├────────┼──────────────────────────────┼────────────────────────────┤
       │ 2      │ "le programme est mort et un │ non utilisé                │
       │        │ fichier verrou /var/lock     │                            │
       │        │ existe"                      │                            │
       ├────────┼──────────────────────────────┼────────────────────────────┤
       │ 3      │ "le programme n'est pas en   │ l'unité n'est pas active   │
       │        │ fonctionnement"              │                            │
       ├────────┼──────────────────────────────┼────────────────────────────┤
       │ 4      │ "le programme ou l'état du   │ pas d'unité de ce genre    │
       │        │ service est inconnu"         │                            │
       └────────┴──────────────────────────────┴────────────────────────────┘

       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, $PAGERest 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 :

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

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

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

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

        1. Caractéristiques du chargeur de démarrage
           https://uapi-group.org/specifications/specs/boot_loader_specification

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

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

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

systemd 257.6                                                                                       SYSTEMCTL(1)