Man » Manuel systemctl en ligne - documentation en ligne détaillée pour la page de manuel systemctl

🌍 ☰

SYNTAXE
DESCRIPTION
COMMANDES
OPTIONS
CODE DE RETOUR
ENVIRONNEMENT
VOIR AUSSI
NOTES

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

SYNTAXE

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

DESCRIPTION

systemctl peut être utilisé pour examiner et contrôler l’état du gestionnaire de système et de services « systemd ». Veuillez consulter [systemd]({filename}../../systemd)(1) pour une introduction aux concepts de base et aux fonctionnalités que cet outil gère.

COMMANDES

Les commandes suivantes sont prises en charge :

Commandes d’unité (introspection et modification)

list-units [MOTIF...]

Affiche les unités que systemd a actuellement en mémoire. Cela inclut les unités qui sont soit directement référencées, soit via une dépendance, les unités qui sont épinglées par des applications de manière programmatique, ou les unités qui étaient actives dans le passé et qui ont échoué. Par défaut, seules les unités qui sont actives, qui ont des tâches en attente ou qui ont échoué sont affichées ; cela peut être modifié avec l’option --all. Si un ou plusieurs MOTIFS sont spécifiés, seules les unités correspondant à l’un d’eux sont affichées. Les unités qui sont affichées sont également filtrées par --type= et --state= si ces options sont spécifiées.

Notez que cette commande n’affiche pas les modèles d’unité, mais uniquement les instances de modèles d’unité. Les modèles d’unité qui ne sont pas instanciés ne sont pas exécutables, et ne seront donc jamais affichés dans la sortie de cette commande. Cela signifie notamment que [email protected] ne sera jamais affiché dans cette liste, sauf s’il est instancié, par exemple sous la forme de _. Utilisez list-unit-files (voir ci-dessous) pour lister les fichiers de modèle d’unité installés.

Produit une sortie similaire à :

UNITÉ                         CHARGEMENT  ACTIF  SOUS-ÉTAT DESCRIPTION
sys-module-fuse.device       chargé     actif    connecté  /sys/module/fuse
-.mount                      chargé     actif    monté     Point de montage racine
boot-efi.mount               chargé     actif    monté     /boot/efi
systemd-journald.service     chargé     actif    en cours  Service de journalisation
systemd-logind.service       chargé     actif    en cours  Service de connexion
● \_            chargé     échec      échec     Gestionnaire d’utilisateur pour l’UID 1000
...
systemd-tmpfiles-clean.timer chargé     actif    en attente Nettoyage quotidien des répertoires temporaires

CHARGEMENT = Indique si la définition de l’unité a été correctement chargée.
ACTIF = L’état d’activation de l’unité au niveau supérieur, c’est-à-dire une généralisation de SOUS-ÉTAT.
SOUS-ÉTAT = L’état d’activation de l’unité au niveau inférieur ; les valeurs dépendent du type d’unité.

123 unités répertoriées. Utilisez --all pour voir également les unités chargées mais inactives.

Pour afficher tous les fichiers d’unité installés, utilisez « systemctl list-unit-files ».

L’en-tête et la dernière unité d’un type donné sont soulignés si le terminal le prend en charge. Un point coloré est affiché à côté des services qui ont été masqués, qui n’ont pas été trouvés ou qui ont échoué d’une autre manière.

La colonne LOAD indique l’état de chargement, qui peut être loaded, not-found, bad-setting, error ou masked. La colonne ACTIVE indique l’état général de l’unité, qui peut être l’un des suivants :

Tableau 1. États actifs de l’unité

┌──────────────┬─────────────────────────────────────┐
│ État         │ Description                         │
├──────────────┼─────────────────────────────────────┤
│ active       │ Démarré, lié, branché, ...,         │
│              │ selon le type d’unité.             │
├──────────────┼─────────────────────────────────────┤
│ inactive     │ Arrêté, non lié, débranché, ...,    │
│              │ selon le type d’unité.             │
├──────────────┼─────────────────────────────────────┤
│ failed       │ Similaire à inactive, mais l’unité  │
│              │ a échoué d’une manière ou d’une   │
│              │ autre (le processus a renvoyé un  │
│              │ code d’erreur à la fermeture, a   │
│              │ planté, une opération a expiré ou  │
│              │ après trop de redémarrages).        │
├──────────────┼─────────────────────────────────────┤
│ activating   │ Passage de l’état inactif à l’état │
│              │ actif.                              │
├──────────────┼─────────────────────────────────────┤
│ deactivating │ Passage de l’état actif à l’état   │
│              │ inactif.                            │
├──────────────┼─────────────────────────────────────┤
│ maintenance  │ L’unité est inactive et une        │
│              │ opération de maintenance est en     │
│              │ cours.                              │
├──────────────┼─────────────────────────────────────┤
│ reloading    │ L’unité est active et elle          │
│              │ recharge sa configuration.          │
├──────────────┼─────────────────────────────────────┤
│ refreshing   │ L’unité est active et un nouveau    │
│              │ montage est activé dans son espace  │
│              │ de noms.                            │
└──────────────┴─────────────────────────────────────┘

La colonne SUB affiche l’état détaillé de l’unité, spécifique au type d’unité. Les valeurs possibles varient en fonction du 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

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

C’est la commande par défaut.

list-automounts [MOTIF...]

Affiche la liste des unités d’automontage actuellement présentes en mémoire, triées par chemin de montage. Si un ou plusieurs MOTIFS sont spécifiés, seules les unités d’automontage correspondant à l’un d’eux sont affichées. Produit une sortie similaire à :

QUOI        OÙ                    MONTÉ DÉLAI UNITÉ
/dev/sdb1   /mnt/test             non   120s    mnt-test.automount
binfmt_misc /proc/sys/fs/binfmt_misc oui   0      proc-sys-fs-binfmt_misc.automount

2 unités d’automontage affichées.

Consultez également --show-types, --all et --state=.

Ajouté dans la version 252.

list-paths [MOTIF...]

Affiche la liste des unités de chemin actuellement présentes en mémoire, triées par chemin. Si un ou plusieurs MOTIFS sont spécifiés, seules les unités correspondant à l’un d’eux sont affichées. Produit une sortie similaire à :

CHEMIN                        CONDITION       UNITÉ                               ACTIVATE
/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 unités de chemin affichées.

Consultez également --show-types, --all et --state=.

Ajouté dans la version 254.

list-sockets [MOTIF...]

Affiche la liste des unités de socket actuellement présentes en mémoire, triées par adresse d’écoute. Si un ou plusieurs MOTIFS sont spécifiés, seules les unités correspondant à l’un d’eux sont affichées. Produit une sortie similaire à :

ÉCOUTE          UNITÉ                        ACTIVATE
kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
/dev/rfkill      systemd-rfkill.socket       systemd-rfkill.service
...

5 sockets affichés.

Remarque : étant donné que les adresses peuvent contenir des espaces, cette sortie n’est pas adaptée à une consommation programmatique.

Consultez également --show-types, --all et --state=.

Ajouté dans la version 202.

list-timers [MOTIF...]

Affiche la liste des unités de minuteur actuellement présentes en mémoire, triées par l’heure à laquelle elles se déclencheront ensuite. Si un ou plusieurs MOTIFS sont spécifiés, seules les unités correspondant à l’un d’eux sont affichées. Produit une sortie similaire à :

PROCHAIN                     RESTANT        DERNIÈRE                     DÉPASSÉ     UNITÉ                        ACTIVATE
-                            -             jeu. 23 févr. 2017 13:40:29 EST  il y a 3 jours ureadahead-stop.timer        ureadahead-stop.service
dim. 26 févr. 2017 18:55:42 EST  1 min 14 s restant jeu. 23 févr. 2017 13:54:44 EST  il y a 3 jours systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
dim. 26 févr. 2017 20:37:16 EST  1 h 42 min restant dim. 26 févr. 2017 11:56:36 EST  6 h avant     apt-daily.timer              apt-daily.service
dim. 26 févr. 2017 20:57:49 EST  2 h 3 min restant dim. 26 févr. 2017 11:56:36 EST  6 h avant     snapd.refresh.timer          snapd.refresh.service

NEXT indique la prochaine fois que le minuteur sera exécuté.

LEFT indique le temps restant avant la prochaine exécution du minuteur.

LAST indique la dernière fois que le minuteur a été exécuté.

PASSED indique le temps écoulé depuis la dernière exécution du minuteur.

UNIT indique le nom du minuteur.

ACTIVATES indique le nom du service que le minuteur active lors de son exécution.

Voir également --all et --state=.

Ajouté dans la version 209.

is-active PATTERN...
Vérifie si l’une des unités spécifiées est active (c’est-à-dire en cours d’exécution). Renvoie un code de sortie 0 si au moins une unité est active, sinon un code différent de zéro. Sauf si --quiet est spécifié, cela affichera également l’état actuel de l’unité sur la sortie standard.

is-failed [PATTERN...]
Vérifie si l’une des unités spécifiées est dans l’état « failed ». Si aucune unité n’est spécifiée, vérifie s’il existe des unités en échec ou des cycles de dépendances, ce qui correspond à l’état « degraded » renvoyé par is-system-running. Renvoie un code de sortie 0 si au moins une unité est en échec, sinon un code différent de zéro. Sauf si --quiet est spécifié, cela affichera également l’état actuel de l’unité ou du système sur la sortie standard.

Ajouté dans la version 197.

status [PATTERN...|PID...]
Affiche des informations sur l’état d’exécution de l’ensemble du système ou d’une ou plusieurs unités, suivies des données de journal les plus récentes. Si aucun argument positionnel n’est spécifié et qu’aucun filtre d’unité n’est donné avec --type=, --state= ou --failed, affiche l’état de l’ensemble du système. Si combiné avec --all, affiche l’état de toutes les unités. Si des arguments positionnels sont spécifiés, chaque argument positionnel est traité comme un nom d’unité à afficher, un modèle glob pour afficher les unités dont les noms correspondent à ce modèle, ou un PID pour afficher l’unité contenant ce PID. Lorsque --type=, --state= ou --failed sont utilisés, les unités sont également filtrées par le TYPE et l’ÉTAT ACTIF.

Cette fonction est conçue pour générer une sortie lisible par un humain. Si vous recherchez une sortie analysable par un ordinateur, utilisez show. Par défaut, cette fonction n’affiche que 10 lignes de sortie et tronque les lignes pour les adapter à la fenêtre du terminal. Cela peut être modifié avec --lines et --full, voir ci-dessus. De plus, journalctl --unit=NAME ou journalctl --user-unit=NAME utilisent un filtre similaire pour les messages et peuvent être plus pratiques.

Notez 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 cours d’exécution) ou la dernière invocation (si elle n’est plus en cours d’exécution et qu’elle n’a pas été libérée de la mémoire). Les informations sur les invocations antérieures, les invocations des démarrages de système précédents ou les invocations antérieures qui ont déjà été libérées de la mémoire peuvent être récupérées via journalctl --unit=.

systemd charge implicitement les unités si nécessaire, de sorte que l’exécution de la commande status tentera de charger un fichier. La commande n’est donc pas utile pour déterminer si quelque chose était déjà chargé ou non. Les unités peuvent également être rapidement déchargées après la fin de l’opération s’il n’y a aucune raison de les conserver en mémoire.

Exemple 1. Exemple de sortie de la commande systemctl status

$ systemctl status bluetooth
● bluetooth.service - Service Bluetooth
Chargé : chargé (/usr/lib/systemd/system/bluetooth.service ; activé ; prédéfini : activé)
Actif : actif (en cours d’exécution) depuis le mercredi 4 janvier 2017, 13 h 54 :04, EST ; il y a 1 semaine, 0 jour
Documentation : man : bluetoothd(8)
PID principal : 930 (bluetoothd)
État : « En cours d’exécution »
Tâches : 1
Mémoire : 648,0 Ko
CPU : 435 ms
CGroup : /system.slice/bluetooth.service
└─930 /usr/lib/bluetooth/bluetoothd

4 janv. 10:46:45 example.com bluetoothd[8900] : pas assez de gestionnaires libres pour enregistrer le service 4 janv. 10:46:45 example.com bluetoothd[8900] : le service Time actuel n’a pas pu être enregistré 4 janv. 10:46:45 example.com bluetoothd[8900] : gatt-time-server : erreur d’entrée/sortie (5)

Le point (« ● ») utilise des couleurs sur les terminaux pris en charge pour résumer l’état de l’unité en un coup d’œil. En plus de sa couleur, sa forme varie en fonction de son état : « inactif » ou « en maintenance » est un cercle blanc (« ○ »), « actif » est un point vert (« ● »), « en cours de désactivation » est un point blanc, « échec » ou « erreur » est une croix rouge (« × »), et « en cours de rechargement » ou « de rafraîchissement » est une flèche circulaire verte dans le sens des aiguilles d’une montre (« ↻ »).

La ligne « Chargé : » dans la sortie affichera « chargé » si l’unité a été chargée en mémoire. Les autres valeurs possibles pour « Chargé : » incluent : « erreur » s’il y a eu un problème lors du chargement, « introuvable » si aucun fichier d’unité n’a été trouvé pour cette unité, « paramètre incorrect » si un paramètre essentiel du fichier d’unité n’a pas pu être analysé et « masqué » si le fichier d’unité a été masqué. En plus d’afficher le chemin d’accès au fichier d’unité, cette ligne affichera également l’état d’activation. Les unités activées sont incluses dans le réseau de dépendances entre les unités, et sont ainsi démarrées au démarrage ou par un autre moyen d’activation. Consultez la table complète des états d’activation possibles, y compris la définition de « masqué », dans la documentation de la commande is-enabled.

La ligne « Actif : » affiche l’état actif. La valeur est généralement « actif » ou « inactif ». Actif peut signifier démarré, lié, branché, etc., selon le type d’unité. L’unité peut également être en train de modifier son état, en affichant un état d’« activation » ou de « désactivation ». Un état « échec » spécial est entré lorsque le service a échoué d’une manière ou d’une autre, par exemple en cas de plantage, de sortie avec un code d’erreur ou de dépassement du délai d’attente. Si l’état d’échec est entré, la cause sera consignée pour une référence ultérieure.

show [PATTERN...|JOB...]

Affiche les propriétés d’une ou plusieurs unités, tâches ou du gestionnaire lui-même. Si aucun argument n’est spécifié, les propriétés du gestionnaire seront affichées. Si un nom d’unité est spécifié, les propriétés de l’unité sont affichées, et si un ID de tâche est spécifié, les propriétés de la tâche sont affichées. Par défaut, les propriétés vides sont supprimées. Utilisez --all pour les afficher également. Pour sélectionner des propriétés spécifiques à afficher, utilisez --property=. Cette commande est destinée à être utilisée chaque fois qu’une sortie analysable par ordinateur est requise. Utilisez status si vous recherchez une sortie formatée et lisible par l’homme.

De nombreuses propriétés affichées par systemctl correspondent directement aux paramètres de configuration du gestionnaire de système et de ses fichiers d'unité. Notez que les propriétés affichées par la commande sont généralement des versions normalisées et de bas niveau des paramètres de configuration d'origine et exposent l'état d'exécution en plus de la configuration. Par exemple, les propriétés affichées pour les unités de service incluent l'identifiant de processus principal actuel du service sous le nom de « MainPID » (qui est un état d'exécution), et les paramètres de temps sont toujours exposés sous forme de propriétés se terminant par le suffixe « ...USec », même si les options de configuration correspondantes se terminent par « ...Sec », car le microseconde est l'unité de temps normalisée utilisée en interne par le gestionnaire de système et de service.

Pour plus de détails sur ces propriétés, consultez la documentation de l'interface D-Bus qui les prend en charge, à savoir org.freedesktop.systemd1(5).

cat PATTERN...

Affiche les fichiers sources d'une ou plusieurs unités. Affiche les fichiers « fragment » et « drop-ins » des unités. Chaque fichier est précédé d'un commentaire qui inclut le nom du fichier. Notez que cela affiche le contenu des fichiers sources sur le disque, qui peut ne pas correspondre à la compréhension du gestionnaire de système de ces unités si des fichiers d'unité ont été mis à jour sur le disque et que la commande daemon-reload n'a pas été exécutée depuis.

Ajouté dans la version 209.

help PATTERN...|PID...

Affiche 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 appartient le processus sont affichées.

Ajouté dans la version 185.

list-dependencies [UNIT...]

Affiche les unités requises et souhaitées par les unités spécifiées. Cela liste récursivement les unités qui suivent les dépendances Requires=, Requisite=, Wants=, ConsistsOf=, BindsTo= et Upholds=. Si aucune unité n'est spécifiée, default.target est implicite.

Les unités qui sont affichées sont également filtrées par --type= et --state= si ces options sont spécifiées. Notez que nous ne pourrons pas utiliser une structure arborescente dans ce cas, donc --plain est implicite.

Par défaut, seules les unités cible sont développées récursivement. Lorsque --all est passé, toutes les autres unités sont également développées récursivement.

Les options --reverse, --after et --before peuvent être utilisées pour modifier les types de dépendances affichées.

Notez que cette commande ne liste que les unités actuellement chargées en mémoire par le gestionnaire de service. En particulier, cette commande ne convient pas pour obtenir une liste complète de toutes les dépendances inverses d'une unité spécifique, car elle ne listera pas les dépendances déclarées par les unités actuellement non chargées.

Ajouté dans la version 198.

start PATTERN...

Démarre (active) une ou plusieurs unités spécifiées sur la ligne de commande.

Notez que les motifs glob des unités se développent en noms d'unités actuellement en mémoire. Les unités qui ne sont pas actives et qui ne sont pas dans un état d'échec ne sont généralement pas en mémoire, et ne seront pas prises en compte par un motif. De plus, dans le cas des unités instanciées, systemd n'est souvent pas au courant du nom de l'instance tant que l'instance n'a pas été démarrée. Par conséquent, l'utilisation de motifs glob avec start a une utilité limitée. De plus, les noms d'alias secondaires des unités ne sont pas pris en compte.

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

stop PATTERN...

Arrête (désactive) une ou plusieurs unités spécifié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)). Elle n’échouera pas si l’une des commandes configurées pour arrêter l’unité (ExecStop=, etc.) échoue, car le gestionnaire terminera quand même l’unité de force.

Si une unité qui est arrêtée peut encore être déclenchée par d’autres unités, un avertissement contenant les noms des unités déclencheuses sera affiché. L’option --no-warn peut être utilisée pour supprimer l’avertissement.

reload PATTERN...

Demande à toutes les unités répertoriées sur la ligne de commande de recharger leur configuration. Notez que cela rechargera la configuration spécifique au service, et non le fichier de configuration de l’unité systemd. Si vous souhaitez que systemd recharge le fichier de configuration d’une unité, utilisez la commande daemon-reload. En d’autres termes : dans le cas de l’exemple d’Apache, cela rechargera le fichier httpd.conf d’Apache dans le serveur Web, et non le fichier d’unité apache.service systemd.

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

restart PATTERN...

Arrête puis démarre une ou plusieurs unités spécifiées sur la ligne de commande. Si les unités ne sont pas encore en cours d’exécution, elles seront démarrées.

Notez que le redémarrage d’une unité avec cette commande ne supprime pas nécessairement toutes les ressources de l’unité avant qu’elle ne soit redémarrée. Par exemple, l’installation de stockage de descripteurs de fichiers spécifique au service (voir FileDescriptorStoreMax= dans systemd.service(5)) restera intacte tant que l’unité aura une tâche en attente, et ne sera effacée que lorsque l’unité sera complètement arrêtée et qu’aucune tâche ne sera plus en attente. S’il est prévu que le stockage de descripteurs de fichiers soit également vidé pendant une opération de redémarrage, une commande systemctl stop explicite suivie d’une commande systemctl start doit être exécutée.

try-restart PATTERN...

Arrête puis démarre une ou plusieurs unités spécifiées sur la ligne de commande si les unités sont en cours d’exécution. Cela ne fait rien si les unités ne sont pas en cours d’exécution.

reload-or-restart PATTERN...

Recharge une ou plusieurs unités si elles le prennent en charge. Sinon, arrête puis démarre-les. Si les unités ne sont pas encore en cours d’exécution, elles seront démarrées.

Cette commande a une fonctionnalité légèrement différente lorsqu’elle est utilisée en combinaison avec --marked, voir ci-dessous.

try-reload-or-restart PATTERN...

Recharge une ou plusieurs unités si elles le prennent en charge. Sinon, arrête puis démarre-les. Cela ne fait rien si les unités ne sont pas en cours d’exécution.

Ajouté dans la version 229.

isolate UNIT

Démarre l’unité spécifiée dans la ligne de commande ainsi que ses dépendances et arrête toutes les autres, sauf si elles ont IgnoreOnIsolate=yes (voir systemd.unit(5)). Si un nom d’unité sans extension est donné, une extension de « .target » sera supposée.

Cette commande est dangereuse, car elle arrêtera immédiatement les processus qui ne sont pas activés dans la nouvelle cible, y compris potentiellement l’environnement graphique ou le terminal que vous utilisez actuellement.

Notez que cette opération n’est autorisée que sur les unités pour lesquelles AllowIsolate= est activé. Voir systemd.unit(5) pour plus de détails.

kill PATTERN...

Envoie un signal de processus UNIX à un ou plusieurs processus de l’unité. Utilisez --kill-whom= pour sélectionner le processus auquel envoyer le signal. Utilisez --signal= pour sélectionner le signal à envoyer. Combinez avec --kill-value= pour mettre en file d’attente un signal en temps réel POSIX avec une valeur associée.

clean PATTERN...

Supprime la configuration, l’état, la mémoire cache, les journaux, les données d’exécution ou les données du magasin de descripteurs de fichiers des unités spécifiées. Utilisez --what= pour sélectionner le type de ressource à supprimer. Pour les unités de service, cela peut être utilisé pour supprimer les répertoires configurés avec ConfigurationDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= et RuntimeDirectory=, voir systemd.exec(5) pour plus de détails. Cela peut également être utilisé pour effacer le magasin de descripteurs de fichiers comme activé via FileDescriptorStoreMax=, voir systemd.service(5) pour plus de détails. Pour les unités de minuteur, cela peut être utilisé pour effacer les données d’horodatage persistantes si Persistent= est utilisé et que --what=state est sélectionné, voir systemd.timer(5) pour plus de détails. Cette commande ne s’applique qu’aux unités qui utilisent l’un ou l’autre de ces paramètres. Si --what= n’est pas spécifié, les données de cache et d’exécution ainsi que le magasin de descripteurs de fichiers sont supprimés (car ces trois types de ressources sont généralement redondants et reproductibles lors de l’invocation suivante de l’unité). Plusieurs valeurs peuvent être séparées par des virgules. Notez que les unités spécifiées doivent être arrêtées pour exécuter cette opération.

Tableau 2. Valeurs possibles pour --what=

┌─────────────────┬────────────────────────────────────┐
│ Valeur          │ Paramètre de l’unité                │
├─────────────────┼────────────────────────────────────┤
│ « runtime »     │ RuntimeDirectory=                  │
├─────────────────┼────────────────────────────────────┤
│ « state »       │ StateDirectory=                    │
├─────────────────┼────────────────────────────────────┤
│ « cache »       │ CacheDirectory=                    │
├─────────────────┼────────────────────────────────────┤
│ « logs »        │ LogsDirectory=                     │
├─────────────────┼────────────────────────────────────┤
│ « configuration »│ ConfigurationDirectory=            │
├─────────────────┼────────────────────────────────────┤
│ « fdstore »     │ FileDescriptorStorePreserve=       │
├─────────────────┼────────────────────────────────────┤
│ « all »         │ Tous les éléments ci-dessus          │
├─────────────────┼────────────────────────────────────┤
│ « help »        │ Affiche les valeurs prises en charge et quitte │
└─────────────────┴────────────────────────────────────┘

Ajouté dans la version 243.

freeze PATTERN...
Gèle une ou plusieurs unités spécifiées sur la ligne de commande en utilisant le congélateur cgroup.

La congélation d’une unité entraînera la suspension de tous les processus contenus dans le cgroup correspondant à
l’unité. Être suspendu signifie que les processus de cette unité ne seront pas planifiés pour s’exécuter sur le CPU jusqu’à ce qu’ils soient dégelés. 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 juste avant que nous n’exécutions une tâche sur l’unité,
par exemple, avant que l’unité ne soit arrêtée.

Ajouté dans la version 246.

thaw PATTERN...
Dégèle (décongèle) une ou plusieurs unités spécifiées sur la ligne de commande.

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

Ajouté dans la version 246.

set-property UNIT PROPERTY=VALUE...
Définit les propriétés d’une unité spécifiée au moment de l’exécution, lorsque cela est pris en charge. Cela permet de modifier
des paramètres de configuration tels que les paramètres de contrôle des ressources au moment de l’exécution. Toutes les propriétés ne peuvent pas être modifiées au moment de l’exécution, mais de nombreux paramètres de contrôle des ressources (principalement ceux de systemd.resource-control(5)) le peuvent. Les modifications sont appliquées immédiatement et stockées sur le disque pour les prochains démarrages, sauf si l’option --runtime est utilisée, auquel cas les paramètres ne s’appliquent qu’avant le prochain redémarrage. La syntaxe de l’affectation de propriété suit de près la syntaxe des affectations dans les fichiers d’unité.

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

Si l’unité spécifiée semble inactive, les modifications ne seront stockées sur le disque que comme décrit précédemment, et seront donc effectives lorsque l’unité sera démarrée.

Notez que cette commande permet de modifier plusieurs propriétés en même temps, ce qui est préférable à la définition de celles-ci individuellement.

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

Comme pour les paramètres de configuration des fichiers d’unité, l’attribution d’une valeur vide à un paramètre réinitialise généralement ce dernier à sa valeur par défaut.

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

Ajouté dans la version 206.

bind UNIT PATH [PATH]

Monte un fichier ou un répertoire de l’hôte dans l’espace de montage spécifié de l’unité. Le premier argument de chemin est le fichier ou le répertoire source sur l’hôte, le deuxième argument de chemin est le fichier ou le répertoire de destination dans l’espace de montage de l’unité. Lorsque ce dernier est omis, le chemin de destination dans l’espace de montage de l’unité est le même que le chemin source sur l’hôte. Lorsqu’il est combiné avec l’option --read-only, un montage en lecture seule est créé. Lorsqu’il est combiné avec l’option --mkdir, le chemin de destination est d’abord créé avant que le montage ne soit appliqué.

Notez que cette option n’est actuellement prise en charge que pour les unités qui s’exécutent dans un espace de montage (par exemple : avec RootImage=, PrivateMounts=, etc.). Cette commande prend en charge le montage de répertoires, de fichiers ordinaires, de nœuds de périphérique, de nœuds de socket AF_UNIX, ainsi que de FIFO. Le montage est éphémère et est annulé dès que le processus de l’unité actuelle se termine. Notez que l’espace de noms mentionné ici, où le montage sera ajouté, est celui dans lequel le processus de service principal s’exécute. Les autres processus (ceux exécutés par ExecReload=, ExecStartPre=, etc.) s’exécutent dans des espaces de noms distincts.

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

Ajouté dans la version 248.

mount-image UNIT IMAGE [PATH [PARTITION_NAME:MOUNT_OPTIONS]]

Monte une image de l’hôte dans l’espace de montage spécifié de l’unité. Le premier argument de chemin est l’image source sur l’hôte, le deuxième argument de chemin est le répertoire de destination dans l’espace de montage de l’unité (c’est-à-dire à l’intérieur de RootImage=/RootDirectory=). L’argument suivant, le cas échéant, est interprété comme un tuple séparé par des deux-points du nom de la partition et de la liste des options de montage, séparées par des virgules, pour cette partition. Le format est le même que le paramètre MountImages= du service. Lorsqu’il est combiné avec l’option --read-only, un montage en lecture seule est créé. Lorsqu’il est combiné avec l’option --mkdir, le chemin de destination est d’abord créé avant que le montage ne soit appliqué.

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

Si le noyau le prend en charge, tout montage précédent sur la cible sélectionnée sera remplacé par le nouveau montage. Dans le cas contraire, tout montage précédent sera superposé, mais restera actif et inaccessible.

Exemple :

systemctl mount-image foo.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 fourni, affiche le niveau de journalisation actuel du service SERVICE.

Si l’argument optionnel NIVEAU est fourni, modifie le niveau de journalisation actuel du service pour qu’il corresponde à NIVEAU. Le niveau de journalisation doit être un niveau de journalisation syslog typique, c’est-à-dire une valeur dans la plage de 0 à 7 ou l’une des chaînes emerg, alert, crit, err, warning, notice, info, debug ; voir syslog(3) pour plus de détails.

Le service doit avoir la propriété BusName=destination appropriée et implémenter 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 de destination.)

Ajouté dans la version 247.

service-log-target SERVICE [CIBLE]

Si l’argument CIBLE n’est pas fourni, affiche la cible de journalisation actuelle du service SERVICE.

Si l’argument optionnel CIBLE est fourni, modifie la cible de journalisation actuelle du service pour qu’elle corresponde à CIBLE. La cible de journalisation doit être l’une des chaînes suivantes : console (pour la sortie de journalisation vers le flux d’erreur standard du service), kmsg (pour la sortie de journalisation vers le tampon de journalisation du noyau), journal (pour la sortie de journalisation vers systemd-journald.service(8) en utilisant le protocole de journalisation natif), syslog (pour la sortie de journalisation vers la prise syslog classique /dev/log), null (pour aucune sortie de journalisation) ou auto (pour un choix déterminé automatiquement, généralement équivalent à console si le service est appelé de manière interactive, et journal ou syslog dans le cas contraire).

Pour la plupart des services, seul un petit sous-ensemble de cibles de journalisation a du sens. En particulier, la plupart des « services normaux » ne doivent implémenter que console, journal et null. Tout le reste n’est approprié que pour les services de bas niveau qui sont actifs très tôt au démarrage, avant que la journalisation appropriée ne soit établie.

Ajouté dans la version 247.

reset-failed [MOTIF...]

Réinitialise l’état « échec » des unités spécifiées, ou, si aucun nom d’unité n’est transmis, réinitialise l’état de toutes les unités. Lorsqu’une unité échoue d’une manière ou d’une autre (c’est-à-dire, le processus se termine avec un code d’erreur non nul, se termine de manière anormale ou dépasse le délai d’attente), elle entre automatiquement dans l’état « échec » et son code de sortie et son état sont enregistrés pour l’introspection par l’administrateur jusqu’à ce que le service soit arrêté/redémarré ou réinitialisé avec cette commande.

En plus de réinitialiser l’état « échec » d’une unité, cela réinitialise également diverses autres propriétés par unité : le compteur de limitation du taux de démarrage de tous les types d’unités est réinitialisé à zéro, ainsi que le compteur de redémarrage des unités de service. Ainsi, si la limite de démarrage d’une unité (telle que configurée avec StartLimitIntervalSec=/StartLimitBurst=) est atteinte et que l’unité refuse de redémarrer, utilisez cette commande pour la rendre à nouveau démarrable.

whoami [PID...]

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

Ajouté dans la version 254.

Commandes de fichiers d'unité

list-unit-files [MOTIF...]

Affiche les fichiers d'unité installés sur le système, ainsi que leur état d'activation (tel que rapporté par is-enabled). Si un ou plusieurs MOTIFS sont spécifiés, seuls les fichiers d'unité dont le nom correspond à l'un d'eux sont affichés (les motifs correspondant aux chemins d'accès aux fichiers d'unité du système de fichiers ne sont pas pris en charge).

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

Ajouté dans la version 233.

enable UNIT..., enable PATH...

Active une ou plusieurs unités ou instances d'unités. Cela créera un ensemble de liens symboliques, comme indiqué dans les sections [Install] des fichiers d'unité indiqués. Après la création des liens symboliques, la configuration du gestionnaire de système est rechargée (d'une manière équivalente à daemon-reload), afin de garantir que les modifications soient prises en compte immédiatement. Notez que cela n'a pas pour effet de démarrer également l'une des unités en cours d'activation. Si cela est souhaité, combinez cette commande avec l'option --now, ou invoquez start avec les arguments appropriés plus tard. Notez que dans le cas de l'activation d'une instance d'unité (c'est-à-dire l'activation d'unités de la forme _), des liens symboliques portant le même nom que les instances sont créés dans le répertoire de configuration des unités, mais ils pointent vers le fichier d'unité de modèle unique à partir duquel ils sont instanciés.

Cette commande s'attend à ce que vous spécifiiez soit des noms d'unités valides (dans ce cas, divers répertoires de fichiers d'unité sont automatiquement recherchés pour les fichiers d'unité portant des noms appropriés), soit des chemins d'accès absolus aux fichiers d'unité (dans ce cas, ces fichiers sont lus directement). Si un fichier d'unité spécifié est situé en dehors des répertoires de fichiers d'unité habituels, un lien symbolique supplémentaire est créé, le liant au chemin de configuration de l'unité, afin de garantir qu'il soit trouvé lorsqu'il est demandé par des commandes telles que start. Le système de fichiers où sont situés les fichiers d'unité liés doit être accessible lorsque systemd est démarré (par exemple, tout ce qui se trouve sous /home/ ou /var/ n'est pas autorisé, à moins que ces répertoires ne soient situés sur le système de fichiers racine).

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

Notez que cette opération crée uniquement les liens symboliques suggérés dans la section [Install] des fichiers d'unité. Bien que cette commande soit le moyen recommandé de manipuler le répertoire de configuration des unités, l'administrateur est libre d'effectuer des modifications supplémentaires manuellement en plaçant ou en supprimant des liens symboliques sous ce répertoire. Ceci est particulièrement utile pour créer des configurations qui s'écartent de la configuration d'installation par défaut suggérée. Dans ce cas, l'administrateur doit s'assurer d'invoquer daemon-reload manuellement si nécessaire, afin de garantir que les modifications soient prises en compte.

Lorsqu’on utilise cette opération sur des unités qui ne contiennent pas d’informations d’installation, un avertissement à ce sujet est affiché. L’option --no-warn peut être utilisée pour supprimer l’avertissement.

L’activation des unités ne doit pas être confondue avec le démarrage (l’activation) des unités, comme le fait la commande start. L’activation et le démarrage des unités sont orthogonaux : 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’intégrer l’unité dans divers endroits suggérés (par exemple, afin que l’unité soit automatiquement démarrée au démarrage ou lorsqu’un type particulier de matériel est branché). Le démarrage lance réellement le processus de démon (dans le cas des unités de service), ou lie la socket (dans le cas des unités de socket), etc.

Selon que les options --system, --user, --runtime ou --global sont spécifiées, cela active l’unité pour le système, pour l’utilisateur appelant uniquement, pour cette session de démarrage uniquement ou pour toutes les connexions futures de tous les utilisateurs. Notez que dans le 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 entraîne une erreur.

disable UNIT...

Désactive une ou plusieurs unités. Cela supprime tous les liens symboliques vers les fichiers d’unité correspondant aux unités spécifiées du répertoire de configuration des unités, et annule ainsi toutes les modifications apportées par enable ou link. Notez que cela supprime tous les liens symboliques vers les fichiers d’unité correspondants, y compris les liens symboliques créés manuellement, et pas seulement ceux réellement créés par enable ou link. Notez que bien que disable annule l’effet de enable, les deux commandes ne sont pas symétriques, car disable peut supprimer plus de liens symboliques qu’une invocation précédente de enable de la même unité n’en a créés.

Cette commande attend uniquement des noms d’unité valides, elle n’accepte pas les chemins d’accès aux fichiers d’unité.

En plus des unités spécifiées en argument, toutes les unités répertoriées dans le paramètre Also= contenu dans la section [Install] de l’un des fichiers d’unité sur lesquels l’opération est effectuée sont désactivées.

Cette commande recharge implicitement la configuration du gestionnaire système après avoir terminé l’opération. Notez que cette commande n’arrête pas implicitement les unités qui sont en cours de désactivation. Si cela est souhaité, combinez cette commande avec l’option --now ou invoquez la commande stop avec les arguments appropriés plus tard.

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

Si une unité est désactivée mais que ses unités de déclenchement sont toujours actives, un avertissement contenant les noms des unités de déclenchement est affiché. L’option --no-warn peut être utilisée pour supprimer l’avertissement.

Lorsque cette commande est utilisée avec --user, les unités sur lesquelles l’opération est effectuée peuvent encore être activées dans la portée globale et, par conséquent, être démarrées automatiquement même après une désactivation réussie dans la portée utilisateur. Dans ce cas, un avertissement à ce sujet est affiché, qui peut être supprimé en utilisant l’option --no-warn.

Cette commande prend en charge les options --system, --user, --runtime, --global et --no-warn de la même manière que la commande enable.

Ajouté dans la version 238.

reenable UNIT...

Réactive une ou plusieurs unités, comme spécifié dans la ligne de commande. Il s’agit d’une combinaison des commandes disable et enable, et elle est utile pour réinitialiser les liens symboliques associés à un fichier d’unité activé, afin de les ramener aux valeurs par défaut configurées dans sa section [Install]. Cette commande attend uniquement le nom d’une unité et n’accepte pas les chemins vers les fichiers d’unité.

Cette commande recharge implicitement la configuration du gestionnaire système après avoir terminé l’opération. Notez que cette commande ne redémarre pas implicitement les unités qui sont en cours de désactivation. Si cela est souhaité, combinez cette commande avec l’option --now, ou invoquez la commande try-restart avec les arguments appropriés ultérieurement.

Ajouté dans la version 238.

preset UNIT...

Réinitialise l’état d’activation/désactivation d’un ou plusieurs fichiers d’unité, comme spécifié dans la ligne de commande, aux valeurs par défaut configurées dans les fichiers de stratégie prédéfinie. Cela a le même effet que disable ou enable, en fonction de la manière dont l’unité est répertoriée dans les fichiers prédéfinis.

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

Si l’unité ne contient pas d’informations d’installation, elle sera ignorée silencieusement par cette commande. UNIT doit être le nom réel de l’unité ; les noms d’alias sont ignorés silencieusement.

Pour plus d’informations sur le format de la stratégie prédéfinie, consultez systemd.preset(5).

Ajouté dans la version 238.

preset-all

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

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

Ajouté dans la version 215.

is-enabled UNIT...

Vérifie si l’un des fichiers d’unité spécifiés est activé (comme avec enable). Retourne un code de sortie de 0 si au moins un est activé, un code différent de zéro sinon. Affiche l’état d’activation actuel (voir tableau). Pour supprimer cette sortie, utilisez --quiet. Pour afficher les cibles d’installation, utilisez --full.

Tableau 3. Sortie de is-enabled

┌───────────────────┬────────────────────────────┬───────────┐
│ Nom              │ Description                │ Code de sortie │
├───────────────────┼────────────────────────────┼───────────┤
│ "enabled"         │ Activé via .wants/,       │           │
├───────────────────┤ .requires/ ou Alias=       │           │
│ "enabled-runtime" │ liens symboliques (de manière permanente dans /etc/systemd/system/, ou de manière transitoire dans /run/systemd/system/). │ 0         │
├───────────────────┼────────────────────────────┼───────────┤
│ "linked"          │ Rendu disponible via un ou plusieurs liens symboliques vers le fichier d’unité (de manière permanente dans /etc/systemd/system/ ou de manière transitoire dans /run/systemd/system/), même si le fichier d’unité réside en dehors du chemin de recherche des fichiers d’unité. │           │
│ "linked-runtime"  │                                                                                    │ \> 0       │
├───────────────────┼────────────────────────────┼───────────┤
│ "alias"           │ Le nom est un alias (lien symbolique vers un autre fichier d’unité).                    │ 0         │
├───────────────────┼────────────────────────────┼───────────┤
│ "masked"          │ Complètement désactivé, de sorte que toute opération de démarrage sur celui-ci échoue (de manière permanente dans /etc/systemd/system/ ou de manière transitoire dans /run/systemd/systemd/). │           │
│ "masked-runtime"  │                                                                                    │ \> 0       │
├───────────────────┼────────────────────────────┼───────────┤
│ "static"          │ Le fichier d’unité n’est pas activé et ne contient pas de dispositions pour l’activation dans la section [Install] du fichier d’unité. │ 0         │
├───────────────────┼────────────────────────────┼───────────┤
│ "indirect"        │ Le fichier d’unité lui-même n’est pas activé, mais il contient un paramètre Also= non vide dans la section [Install] du fichier d’unité, répertoriant d’autres fichiers d’unité qui peuvent être activés, ou il a un alias sous un nom différent via un lien symbolique qui n’est pas spécifié dans Also=. Pour les fichiers d’unité de modèle, une instance différente de celle spécifiée dans DefaultInstance= est activée. │ 0         │
├───────────────────┼────────────────────────────┼───────────┤
│ "disabled"        │ Le fichier d’unité n’est pas activé, mais contient une section [Install] avec des instructions d’installation. │ \> 0       │
├───────────────────┼────────────────────────────┼───────────┤
│ "generated"       │ Le fichier d’unité a été généré dynamiquement via un outil de génération. Voir 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. │ 0         │
├───────────────────┼────────────────────────────┼───────────┤
│ "transient"       │ Le fichier d’unité a été créé dynamiquement avec l’API d’exécution. Les unités transitoires peuvent ne pas être activées. │ 0         │
├───────────────────┼────────────────────────────┼───────────┤
│ "bad"             │ Le fichier d’unité est invalide ou une autre erreur s’est produite. Notez que is-enabled ne renverra pas réellement cet état, mais affichera un message d’erreur. Cependant, la liste des fichiers d’unité affichée par list-unit-files peut l’indiquer. │ \> 0       │
├───────────────────┼────────────────────────────┼───────────┤
│ "not-found"       │ Le fichier d’unité n’existe pas. │ 4         │
└───────────────────┴────────────────────────────┴───────────┘

Ajouté dans la version 238.

mask UNIT...

Masque une ou plusieurs unités, comme spécifié dans la ligne de commande. Cela créera un lien symbolique vers ces fichiers d'unité vers /dev/null, ce qui rendra impossible leur démarrage. Il s'agit d'une version plus stricte de disable, car elle interdit tous les types d'activation de l'unité, y compris l'activation et l'activation manuelle. Utilisez cette option avec prudence. Cette option prend en charge l'option --runtime pour masquer temporairement jusqu'au prochain redémarrage du système. L'option --now peut être utilisée pour garantir que les unités sont également arrêtées. Cette commande attend uniquement des noms d'unités valides, elle n'accepte pas les chemins de fichiers d'unité.

Notez que cela créera un lien symbolique sous le nom de l'unité dans /etc/systemd/system/ (si --runtime n'est pas spécifié) ou /run/systemd/system/ (si --runtime est spécifié). Si un fichier d'unité correspondant existe déjà dans ces répertoires, cette opération échouera. Cela signifie que cette opération est principalement utile pour masquer les unités fournies par le fournisseur (car celles-ci sont fournies dans /usr/lib/systemd/system/ et non dans les deux répertoires mentionnés ci-dessus), mais ne fonctionne généralement pas pour les unités créées localement (car celles-ci sont généralement placées précisément dans les deux répertoires mentionnés ci-dessus). Des restrictions similaires s'appliquent au mode --user, auquel cas les répertoires se trouvent sous le répertoire personnel de l'utilisateur.

Si une unité est masquée, mais que ses unités de déclenchement sont toujours actives, un avertissement contenant les noms des unités de déclenchement est affiché. L'option --no-warn peut être utilisée pour supprimer l'avertissement.

Ajouté dans la version 238.

unmask UNIT...

Annule le masquage d'un ou plusieurs fichiers d'unité, comme spécifié dans la ligne de commande. Cela annulera l'effet de mask. Cette commande attend uniquement des noms d'unités valides, elle n'accepte pas les chemins de fichiers d'unité.

Ajouté dans la version 238.

link PATH...

Crée un lien symbolique vers un fichier d'unité qui ne se trouve pas dans le chemin de recherche des fichiers d'unité, afin qu'il soit inclus dans ce chemin. Cette commande attend un chemin absolu vers un fichier d'unité. L'effet de cette commande peut être annulé avec disable. L'effet de cette commande est qu'un fichier d'unité est mis à disposition pour les commandes telles que start, même s'il n'est pas installé directement dans le chemin de recherche. Le système de fichiers où se trouvent les fichiers d'unité liés doit être accessible lorsque systemd est démarré (par exemple, tout ce qui se trouve sous /home/ ou /var/ n'est pas autorisé, à moins que ces répertoires ne soient situés sur le système de fichiers racine).

Ajouté dans la version 233.

revert UNIT...

Rétablit un ou plusieurs fichiers d’unité à leurs versions fournies par le vendeur. Cette commande supprime les fichiers de configuration qui modifient les unités spécifiées, ainsi que tout fichier d’unité configuré par l’utilisateur qui remplace un fichier d’unité fourni par le vendeur. Plus précisément, pour une unité « foo.service », les répertoires correspondants « foo.service.d/ » avec tous les fichiers qu’ils contiennent sont supprimés, à la fois sous les répertoires de configuration persistante et temporaire (c’est-à-dire sous /etc/systemd/system et /run/systemd/system) ; si le fichier d’unité possède une version fournie par le vendeur (c’est-à-dire un fichier d’unité situé sous /usr/), tout fichier d’unité persistant ou temporaire correspondant qui le remplace est également supprimé. Notez que si un fichier d’unité ne possède pas de version fournie par le vendeur (c’est-à-dire qu’il est défini uniquement sous /etc/systemd/system ou /run/systemd/system, mais pas dans un fichier d’unité stocké sous /usr/), il n’est pas supprimé. De plus, si une unité est masquée, elle est démasquée.

Cette commande peut être utilisée pour annuler toutes les modifications apportées à l’aide de systemctl edit, systemctl set-property et systemctl mask, et rétablit le fichier d’unité d’origine avec ses paramètres.

Ajouté dans la version 230.

add-wants TARGET UNIT..., add-requires TARGET UNIT...

Ajoute des dépendances « Wants= » ou « Requires= » à la cible spécifiée pour une ou plusieurs unités.

Cette commande prend en compte les options --system, --user, --runtime et --global de la même manière que enable.

Ajouté dans la version 217.

edit UNIT...

Modifie ou remplace un fragment de configuration ou le fichier d’unité principal, afin d’étendre ou de remplacer la définition de l’unité spécifiée.

Selon que --system (par défaut), --user ou --global est spécifié, cette commande opère sur les fichiers d’unité système, les fichiers d’unité pour l’utilisateur qui appelle la commande ou les fichiers d’unité partagés entre tous les utilisateurs.

L’éditeur (voir la section « Environnement » ci-dessous) est appelé sur des fichiers temporaires qui seront écrits à l’emplacement réel si l’éditeur se termine avec succès. Une fois la modification terminée, la configuration est rechargée, ce qui équivaut à systemctl daemon-reload --system ou systemctl daemon-reload --user. Pour edit --global, le rechargement n’est pas effectué et les modifications ne prendront effet qu’après une connexion ultérieure (ou après qu’un rechargement aura été demandé d’une autre manière).

Si --full est spécifié, un remplacement du fichier d’unité principal sera créé ou modifié. Dans le cas contraire, un fichier de configuration sera créé ou modifié.

Si --drop-in= est spécifié, le nom de fichier de configuration donné sera utilisé à la place du fichier override.conf par défaut.

L’unité doit exister, c’est-à-dire que son fichier d’unité principal doit être présent. Si --force est spécifié, cette exigence est ignorée et une nouvelle unité peut être créée (avec --full), ou un fichier de configuration pour une unité inexistante peut être créé.

Si l’option --runtime est spécifiée, les modifications seront apportées temporairement dans /run/ et seront perdues au prochain redémarrage.

Si l’option --stdin est spécifiée, le nouveau contenu sera lu à partir de l’entrée standard. Dans ce mode, l’ancien contenu du fichier est supprimé.

Si le fichier temporaire est vide à la fin, la modification de l’unité correspondante est annulée.

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

Ajouté dans la version 218.

get-default

Retourne la cible par défaut à démarrer. Cela renvoie le nom de l’unité cible, default.target étant un alias (lien symbolique).

Ajouté dans la version 205.

set-default TARGET

Définit la cible par défaut à démarrer. Cela définit (crée un lien symbolique) l’alias default.target vers l’unité cible donnée.

Ajouté dans la version 205.

Commandes Machine

list-machines [MOTIF...]

Affiche l’hôte et tous les conteneurs locaux en cours d’exécution avec leur état. Si un ou plusieurs MOTIFS sont spécifiés, seuls les conteneurs correspondant à l’un d’eux sont affichés.

Ajouté dans la version 212.

Commandes Job

list-jobs [MOTIF...]

Affiche les tâches en cours. Si un ou plusieurs MOTIFS sont spécifiés, seules les tâches correspondant à l’un d’eux sont affichées.

En combinaison avec --after ou --before, la liste est augmentée d’informations sur les autres tâches dont chaque tâche dépend et sur les autres tâches qui dépendent d’elle, voir ci-dessus.

Ajouté dans la version 233.

cancel [JOB...]

Annule une ou plusieurs tâches spécifiées dans la ligne de commande par leurs ID de tâche numériques. Si aucun ID de tâche n’est spécifié, annule toutes les tâches en attente.

Ajouté dans la version 233.

Commandes Environnement

systemd prend en charge un bloc d’environnement qui est transmis aux processus que le gestionnaire lance. 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. Dans les valeurs des variables, la plupart des caractères sont autorisés, mais toute la séquence doit être un UTF-8 valide. (Notez que les caractères de contrôle tels que la nouvelle ligne (NL), la tabulation (TAB) ou le caractère d’échappement (ESC) sont des ASCII valides et donc des UTF-8 valides). La longueur totale du bloc d’environnement est limitée à la valeur _SC_ARG_MAX définie par sysconf(3).

show-environment

Affiche le bloc d’environnement du gestionnaire systemd. Il s’agit du bloc d’environnement qui est transmis à tous les processus que le gestionnaire lance. Le bloc d’environnement sera affiché sous une forme simple, adaptée à l’importation dans la plupart des shells. Si aucun caractère spécial ou espace blanc n’est présent dans les valeurs des variables, aucun échappement n’est effectué et les affectations ont la forme « VARIABLE=valeur ». Si des espaces blancs ou des caractères ayant une signification spéciale pour le shell sont présents, un échappement dollar-apostrophe unique est utilisé et les affectations ont la forme « VARIABLE=$’valeur' ». Cette syntaxe est prise en charge par bash(1), zsh(1), ksh(1) et busybox(1)’s ash(1), mais pas par dash(1) ou fish(1).

Notez que cela affiche le bloc d’environnement effectif, c’est-à-dire la combinaison des variables d’environnement configurées via les fichiers de configuration, les générateurs d’environnement et via IPC (c’est-à-dire via la commande set-environment décrite ci-dessous). Au moment où un processus d’unité est créé, ce bloc d’environnement combiné sera davantage combiné avec les variables d’environnement par unité, qui ne sont pas visibles dans cette commande.

set-environment VARIABLE=VALUE...

Définit une ou plusieurs variables d’environnement du gestionnaire de service, comme spécifié dans la ligne de commande. Cette commande échouera si les noms et les valeurs des variables ne respectent pas les règles énumérées ci-dessus.

Ajouté dans la version 233.

unset-environment VARIABLE...

Supprime une ou plusieurs variables d’environnement du gestionnaire systemd. Si seul le nom d’une variable est spécifié, elle sera supprimée quelle que soit sa valeur. Si une variable et une valeur sont spécifiées, la variable est supprimée uniquement si elle a la valeur spécifiée.

Notez que cela opère sur un bloc d’environnement séparé du bloc d’environnement configuré à partir de la configuration du gestionnaire de service et des générateurs d’environnement. Chaque fois qu’un processus est invoqué, les deux blocs sont combinés (intégrant également les variables d’environnement par service), puis transmis à ce processus. La commande show-environment affichera la combinaison des blocs, comme indiqué ci-dessus. Notez que cela signifie que cette commande ne peut pas être utilisée pour supprimer les variables d’environnement définies dans les fichiers de configuration du gestionnaire de service ou via les générateurs.

Ajouté dans la version 233.

import-environment VARIABLE...

Importe toutes les variables d’environnement définies sur le client dans le bloc d’environnement du gestionnaire systemd. Si une liste de noms de variables d’environnement est transmise, les valeurs côté client sont ensuite importées dans le bloc d’environnement du gestionnaire. Si des noms ne sont pas des noms de variables d’environnement valides ou ont des valeurs non valides selon les règles décrites ci-dessus, une erreur est générée. Si aucun argument n’est transmis, l’ensemble du bloc d’environnement hérité par le processus systemctl est importé. Dans ce mode, toutes les variables d’environnement héritées non valides sont ignorées silencieusement.

L’importation de l’ensemble du bloc d’environnement hérité (en appelant cette commande sans aucun argument) est déconseillée. Un shell définira des dizaines de variables qui n’ont de sens que localement et qui sont destinées uniquement aux processus qui sont des descendants du shell. Ces variables dans le bloc d’environnement global sont déroutantes pour les autres processus.

Ajouté dans la version 209.

Commandes d’état du gestionnaire

daemon-reload

Recharge la configuration du gestionnaire systemd. Cela relancera tous les générateurs (voir systemd.generator(7)), rechargera tous les fichiers d’unité et recréera l’ensemble de l’arborescence des dépendances. Pendant le rechargement du démon, toutes les sockets sur lesquelles systemd écoute pour la configuration de l’utilisateur resteront accessibles.

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

daemon-reexec

Réexécute le gestionnaire systemd. Cela sérialisera l'état du gestionnaire, réexécutera le processus et désérialisera l'état. Cette commande est de peu d'utilité, sauf pour le débogage et les mises à niveau des paquets. Parfois, elle peut être utile en tant que commande daemon-reload plus lourde. Pendant que le démon est réexécuté, tous les sockets sur lesquels systemd écoute pour la configuration de l'utilisateur resteront accessibles.

log-level [NIVEAU]

Si aucun argument n'est fourni, affiche le niveau de journalisation actuel du gestionnaire. Si un argument optionnel NIVEAU est fourni, la commande modifie le niveau de journalisation actuel du gestionnaire à NIVEAU (accepte les mêmes valeurs que --log-level=, décrit dans systemd(1)).

Ajouté dans la version 244.

log-target [CIBLE]

Si aucun argument n'est fourni, affiche la cible de journalisation actuelle du gestionnaire. Si un argument optionnel CIBLE est fourni, la commande modifie la cible de journalisation actuelle du gestionnaire à CIBLE (accepte les mêmes valeurs que --log-target=, décrit dans systemd(1)).

Ajouté dans la version 244.

service-watchdogs [oui|non]

Si aucun argument n'est fourni, affiche l'état actuel des chiens de garde d'exécution des services du gestionnaire. Si un argument booléen optionnel est fourni, cela active ou désactive globalement les chiens de garde d'exécution des services (WatchdogSec=) et les actions d'urgence (par exemple, OnFailure= ou StartLimitAction=) ; voir systemd.service(5). Le chien de garde matériel n'est pas affecté par ce paramètre.

Ajouté dans la version 244.

Commandes système

is-system-running

Vérifie si le système est opérationnel. Cela renvoie un succès (code de sortie 0) lorsque le système est entièrement opérationnel, en particulier lorsqu'il n'est pas en mode de démarrage, d'arrêt ou de maintenance, et qu'aucun service n'a échoué. L'échec est renvoyé dans le cas contraire (code de sortie différent de zéro). De plus, l'état actuel est imprimé dans une courte chaîne sur la sortie standard, voir le tableau ci-dessous. Utilisez --quiet pour supprimer cette sortie.

Utilisez --wait pour attendre que le processus de démarrage soit terminé avant d'imprimer l'état actuel et de renvoyer le code d'erreur approprié. Si --wait est utilisé, les états initializing ou starting ne seront pas signalés, au lieu de cela, la commande bloquera jusqu'à ce qu'un état ultérieur (tel que running ou degraded) soit atteint.

Tableau 4. Sortie de is-system-running

┌──────────────┬────────────────────────────┬───────────┐
│ Nom          │ Description                │ Code de   │
│              │                              │ sortie    │
├──────────────┼────────────────────────────┼───────────┤
│ initializing │ Démarrage initial, avant     │ > 0       │
│              │ que basic.target soit atteint │           │
│              │ ou que le mode de maintenance │           │
│              │ soit activé.                │           │
├──────────────┼────────────────────────────┼───────────┤
│ starting     │ Démarrage tardif, avant que  │ > 0       │
│              │ la file d'attente des tâches  │           │
│              │ ne devienne inactive pour la  │           │
│              │ première fois, ou que l'une   │           │
│              │ des cibles de secours soit    │           │
│              │ atteinte.                    │           │
├──────────────┼────────────────────────────┼───────────┤
│ running      │ Le système est entièrement    │ 0         │
│              │ opérationnel.               │           │
├──────────────┼────────────────────────────┼───────────┤
│ degraded     │ Le système est opérationnel  │ > 0       │
│              │ mais une ou plusieurs unités   │           │
│              │ ont échoué.                  │           │
├──────────────┼────────────────────────────┼───────────┤
│ maintenance  │ La cible de secours ou        │ > 0       │
│              │ d'urgence est active.        │           │
├──────────────┼────────────────────────────┼───────────┤
│ stopping     │ Le gestionnaire est en train  │ > 0       │
│              │ de s'arrêter.               │           │
├──────────────┼────────────────────────────┼───────────┤
│ offline      │ Le gestionnaire n'est pas     │ > 0       │
│              │ en cours d'exécution.         │           │
│              │ Plus précisément, il s'agit  │           │
│              │ de l'état opérationnel si un  │           │
│              │ programme incompatible est    │           │
│              │ en cours d'exécution en tant  │           │
│              │ que gestionnaire système (PID 1). │           │
├──────────────┼────────────────────────────┼───────────┤
│ unknown      │ L'état opérationnel n'a pas  │ > 0       │
│              │ pu être déterminé, en raison  │           │
│              │ d'un manque de ressources ou   │           │
│              │ d'une autre cause d'erreur.   │           │
└──────────────┴────────────────────────────┴───────────┘

Ajouté dans la version 215.

default
Entrer en mode par défaut. Ceci équivaut à systemctl isolate default.target. Cette opération est bloquante par défaut ; utilisez --no-block pour demander un comportement asynchrone.

rescue
Entrer en mode de secours. Ceci équivaut à systemctl isolate rescue.target. Cette opération est bloquante par défaut ; utilisez --no-block pour demander un comportement asynchrone.

emergency
Entrer en mode d’urgence. Ceci équivaut à systemctl isolate emergency.target. Cette opération est bloquante par défaut ; utilisez --no-block pour demander un comportement asynchrone.

halt
Arrêter le système et le mettre hors tension. Ceci est en grande partie équivalent à systemctl start halt.target --job-mode=replace-irreversibly --no-block, mais affiche également un message à tous les utilisateurs. Cette commande est asynchrone ; elle renvoie après que l’opération d’arrêt a été mise en file d’attente, sans attendre qu’elle soit terminée. Notez que cette opération arrête simplement le noyau du système d’exploitation après l’arrêt, laissant le matériel sous tension. Utilisez systemctl poweroff pour éteindre complètement le système (voir ci-dessous).

Si combiné avec --force, l’arrêt de tous les services en cours d’exécution est ignoré, mais tous les processus sont arrêtés et tous les systèmes de fichiers sont démontés ou montés en lecture seule, immédiatement suivis par l’arrêt du système. Si --force est spécifié deux fois, l’opération est exécutée immédiatement sans arrêter aucun processus ni démonter aucun système de fichiers. Cela peut entraîner une perte de données. Notez que lorsque --force est spécifié deux fois, l’opération d’arrêt est exécutée par systemctl lui-même, et le gestionnaire de système n’est pas contacté. Cela signifie que la commande doit réussir même lorsque le gestionnaire de système est en panne.

Si combiné avec --when=, l’arrêt sera programmé après l’heure spécifiée. Et --when=cancel annulera l’arrêt.

poweroff
Arrêter complètement le système. Ceci est en grande partie équivalent à systemctl start poweroff.target --job-mode=replace-irreversibly --no-block, mais affiche également un message à tous les utilisateurs. Cette commande est asynchrone ; elle renvoie après que l’opération d’arrêt a été mise en file d’attente, sans attendre qu’elle soit terminée.

Cette commande prend en charge --force et --when= de la même manière que halt.

reboot
Arrêter et redémarrer le système.

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

Si l’option --reboot-argument= est donnée, elle sera transmise comme argument facultatif à l’appel système [reboot]({filename}../../reboot)(2).

Les options --boot-loader-entry=, --boot-loader-menu= et --firmware-setup peuvent être utilisées pour sélectionner l’action à effectuer après le redémarrage. Voir les descriptions de ces options pour plus de détails.

Cette commande prend en charge --force et --when= de la même manière que halt.

Si un nouveau noyau a été chargé via kexec --load, un kexec sera effectué à la place d’un redémarrage, à moins que SYSTEMCTL_SKIP_AUTO_KEXEC=1 soit défini. Si un nouveau système de fichiers racine a été configuré sur /run/nextroot/, un redémarrage en douceur sera effectué à la place d’un redémarrage, à moins que SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1 soit défini.

Ajouté dans la version 246.

kexec

Arrête et redémarre le système via kexec. Cette commande chargera un noyau kexec si aucun n’a été chargé ou échouera. Un noyau peut être chargé plus tôt par une étape distincte, ce qui est particulièrement utile si un initrd personnalisé ou des options de ligne de commande de noyau supplémentaires sont souhaitées. L’option --force peut être utilisée pour continuer sans noyau kexec, c’est-à-dire pour effectuer un redémarrage normal. L’étape de redémarrage finale 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 spécification UAPI.1 du chargeur de démarrage [1], et l’entrée de démarrage par défaut est chargée. Pour que cette étape réussisse, le système doit utiliser UEFI et les entrées du chargeur de démarrage doivent être configurées de manière appropriée. bootctl list peut être utilisé pour lister les entrées de démarrage, voir bootctl(1).

Cette commande est asynchrone ; elle renverra une valeur après que l’opération de redémarrage aura été mise en file d’attente, sans attendre qu’elle se termine.

Cette commande prend en charge les options --force et --when= de la même manière que halt.

Si un nouveau noyau a été chargé via kexec --load, un kexec sera effectué lorsque le redémarrage sera invoqué, à moins que SYSTEMCTL_SKIP_AUTO_KEXEC=1 soit défini.

soft-reboot

Arrête et redémarre l’espace utilisateur. Ceci est équivalent à systemctl start soft-reboot.target --job-mode=replace-irreversibly --no-block. Cette commande est asynchrone ; elle renverra une valeur après que l’opération de redémarrage aura été mise en file d’attente, sans attendre qu’elle se termine.

Cette commande prend en charge les options --force et --when= de la même manière que halt.

Cette opération ne redémarre que l’espace utilisateur, laissant le noyau en cours d’exécution. Voir systemd-softreboot.service(8) pour plus de détails.

Si un nouveau système de fichiers racine a été configuré sur /run/nextroot/, un soft-reboot sera effectué lorsque le redémarrage sera invoqué, à moins que SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1 soit défini.

Ajouté dans la version 254.

exit [EXIT_CODE]

Demande au gestionnaire de services de se fermer. Ceci n’est pris en charge que pour les gestionnaires de services utilisateur (c’est-à-dire en conjonction avec l’option --user) ou dans les conteneurs, et est équivalent à poweroff dans le cas contraire. Cette commande est asynchrone ; elle renverra une valeur après que l’opération de fermeture aura été mise en file d’attente, sans attendre qu’elle se termine.

Le gestionnaire de services se fermera avec le code de sortie spécifié, si EXIT_CODE est transmis.

Ajouté dans la version 227.

switch-root [ROOT [INIT]]

Passe à un répertoire racine différent et exécute un nouveau processus de gestionnaire de système en dessous. Ceci est destiné à être utilisé dans l’initrd, et effectuera une transition du processus du gestionnaire de système de l’initrd (également appelé processus « init », PID 1) vers le processus principal du gestionnaire de système qui est chargé à partir du système de fichiers racine hôte réel. Cet appel prend deux arguments : le répertoire qui doit devenir le nouveau répertoire racine, et le chemin d’accès au nouveau fichier binaire du gestionnaire de système à exécuter en tant que PID 1. Si les deux sont omis ou si le premier est une chaîne vide, la valeur par défaut est /sysroot/. Si ce dernier est omis ou est une chaîne vide, un fichier binaire systemd sera automatiquement recherché et utilisé comme gestionnaire de services. Si le chemin d’accès du gestionnaire de système est omis, est égal à une chaîne vide ou est identique au chemin d’accès du fichier binaire systemd, l’état du processus du gestionnaire de système de l’initrd est transmis au gestionnaire de système principal, ce qui permet une introspection ultérieure de l’état des services impliqués dans la phase de démarrage de l’initrd.

Ajouté dans la version 209.

sleep

Met le système en veille, par le biais de la suspension, de la mise en hibernation, de la veille hybride ou de la suspension suivie de la mise en hibernation. L’opération de veille à utiliser est sélectionnée automatiquement par systemd-logind.service(8). Par défaut, la suspension suivie de la mise en hibernation est utilisée, puis la suspension et enfin la mise en hibernation si cela n’est pas pris en charge. Consultez le paramètre SleepOperation= dans logind.conf(5) pour plus de détails. Cette commande est asynchrone et renvoie après que l’opération de veille a été correctement mise en file d’attente. Elle n’attend pas la fin du cycle de veille/reprise.

Ajouté dans la version 256.

suspend

Suspend le système. Cela déclenche l’activation de l’unité cible spéciale suspend.target. Cette commande est asynchrone et renvoie après que l’opération de suspension a été correctement mise en file d’attente. Elle n’attend pas la fin du cycle de suspension/reprise.

Si --force est spécifié et que systemd-logind a renvoyé une erreur pour l’opération, l’erreur sera ignorée et l’opération sera tentée à nouveau directement en démarrant l’unité cible.

hibernate

Met le système en hibernation. Cela déclenche l’activation de l’unité cible spéciale hibernate.target. Cette commande est asynchrone et renvoie après que l’opération d’hibernation a été correctement mise en file d’attente. Elle n’attend pas la fin du cycle d’hibernation/réveil.

Cette commande prend en charge --force de la même manière que suspend.

hybrid-sleep

Met le système en hibernation et le suspend. Cela déclenche l’activation de l’unité cible spéciale hybrid-sleep.target. Cette commande est asynchrone et renvoie après que l’opération de veille hybride a été correctement mise en file d’attente. Elle n’attend pas la fin du cycle de veille/réveil.

Cette commande prend en charge --force de la même manière que suspend.

Ajouté dans la version 196.

suspend-then-hibernate

Suspend le système et le met en hibernation lorsque la batterie est faible, ou lorsque le délai spécifié dans systemd-sleep.conf est écoulé. Cela déclenche l’activation de l’unité cible spéciale suspend-then-hibernate.target. Cette commande est asynchrone et renvoie après que l’opération de veille hybride a été correctement mise en file d’attente. Elle n’attend pas la fin du cycle de veille/réveil ou du cycle d’hibernation/réveil.

Cette commande prend en charge --force de la même manière que suspend.

Ajouté dans la version 240.

Syntaxe des paramètres

Les commandes d’unité répertoriées ci-dessus prennent soit un seul nom d’unité (désigné par UNIT), soit plusieurs spécifications d’unités (désigné par PATTERN...). 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 approprié, « .service » par défaut, et un suffixe spécifique au type dans le cas des commandes qui fonctionnent uniquement sur des types d’unités spécifiques. Par exemple :

# systemctl start sshd

et

# systemctl start sshd.service

sont équivalents, de même que

# systemctl isolate default

et

# systemctl isolate default.target

Notez que les chemins absolus vers les nœuds de périphériques sont automatiquement convertis en noms d’unités de périphériques, et les autres chemins absolus sont convertis en noms d’unités de montage.

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

sont équivalents à :

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

Dans le deuxième cas, les caractères génériques de type shell seront mis en correspondance avec les noms principaux de toutes les unités actuellement présentes en mémoire ; les noms d’unités littéraux, avec ou sans suffixe, seront traités comme dans le premier cas. Cela signifie que les noms d’unités littéraux font toujours référence à une seule unité, mais les caractères génériques peuvent correspondre à zéro unité, ce qui n’est pas considéré comme une erreur.

Les modèles de caractères génériques utilisent fnmatch(3), de sorte que les règles de caractères génériques de type shell sont utilisées, et "*", "?", "[]" peuvent être utilisés. Voir glob(7) pour plus de détails. Les modèles sont mis en correspondance avec les noms principaux des unités actuellement présentes en mémoire, et les modèles qui ne correspondent à rien sont ignorés silencieusement. Par exemple :

# systemctl stop "sshd@*.service"

arrêtera toutes les instances [email protected]. Notez que les noms alternatifs des unités et les unités qui ne sont pas en mémoire ne sont pas pris en compte pour l’expansion des caractères génériques.

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

# systemctl enable foo.service

ou

# systemctl link /path/to/foo.service

OPTIONS

Les options suivantes sont prises en charge :

-t, --type=

L’argument est une liste séparée par des virgules de types d’unités, 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 spécifiés seront affichées. Par défaut, les unités de tous les types sont affichées.

Dans un cas particulier, si l’un des arguments est help, une liste des valeurs autorisées sera affichée et le programme se terminera.

--state=

L’argument est une liste séparée par des virgules d’états d’unité LOAD, SUB ou ACTIVE. Lorsque les unités sont listées avec list-units, list-dependencies, show ou status, afficher uniquement celles qui se trouvent dans les états spécifiés. Utilisez --state=failed ou --failed pour afficher uniquement les unités ayant échoué.

Dans un cas particulier, si l’un des arguments est help, une liste des valeurs autorisées sera affichée et le programme se terminera.

Ajouté dans la version 206.

-p, --property=

Lorsque les propriétés d’unité/travail/gestionnaire sont affichées avec la commande show, limiter l’affichage aux propriétés spécifiées dans l’argument. L’argument doit être une liste séparée par des virgules de noms de propriétés, tels que « MainPID ». Sauf indication contraire, toutes les propriétés connues sont affichées. Si cela est spécifié plus d’une fois, toutes les propriétés avec les noms spécifiés sont affichées. La complétion automatique est implémentée pour les noms de propriétés.

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

Les propriétés des unités varient en fonction du type d’unité. Afficher une unité (même une unité inexistante) est donc un moyen de lister les propriétés relatives à ce type. De même, afficher une tâche listera les propriétés relatives à toutes les tâches. Les propriétés des unités sont documentées dans systemd.unit(5), et les pages des types d’unités individuels, systemd.service(5), systemd.socket(5), etc.

-P

Équivalent à --value --property=, c’est-à-dire qu’il affiche la valeur de la propriété sans le nom de la propriété ni le signe « = ». Notez que l’utilisation de -P une fois affectera également toutes les propriétés listées avec -p/--property=.

Ajouté dans la version 246.

-a, --all

Lorsque vous listez les unités avec list-units, affichez également les unités inactives et les unités qui suivent d’autres unités. Lorsque vous affichez les propriétés d’une unité/tâche/gestionnaire, affichez toutes les propriétés, qu’elles soient définies ou non.

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

Lorsque vous listez les unités avec list-dependencies, affichez 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).

Lorsqu’il est utilisé avec status, affichez les messages du journal en entier, même s’ils contiennent des caractères non imprimables ou sont très longs. Par défaut, les champs contenant des caractères non imprimables sont abrégés comme « données binaires ». (Notez que le paginateur peut à nouveau échapper les caractères non imprimables).

-r, --recursive

Lorsque vous listez les unités, affichez également les unités des conteneurs locaux. Les unités des conteneurs locaux seront préfixées par le nom du conteneur, séparées par un seul caractère deux-points ( : ).

Ajouté dans la version 212.

--reverse

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

Ajouté dans la version 203.

--after

Avec list-dependencies, affichez les unités qui sont ordonnées avant l’unité spécifiée. En d’autres termes, listez récursivement les unités suivant la dépendance After=.

Notez que toute dépendance After= est automatiquement reflétée pour créer une dépendance Before=. Les dépendances temporelles peuvent être spécifiées explicitement, mais sont également créées implicitement pour les unités qui sont des cibles WantedBy= (voir systemd.target(5)) et à la suite d’autres directives (par exemple, RequiresMountsFor=). Les dépendances introduites explicitement et implicitement sont affichées avec list-dependencies.

Lorsque cela est transmis à la commande list-jobs, pour chaque tâche imprimée, affichez les autres tâches qui l’attendent. Peut être combiné avec --before pour afficher à la fois les tâches qui attendent chaque tâche, ainsi que toutes les tâches qu’une tâche attend.

Ajouté dans la version 203.

--before

Avec list-dependencies, affichez les unités qui sont ordonnées après l’unité spécifiée. En d’autres termes, listez récursivement les unités suivant la dépendance Before=.

Lorsqu’il est utilisé avec la commande list-jobs, pour chaque tâche affichée, indique les autres tâches dont elle dépend. Peut être combiné avec l’option --after pour afficher à la fois les tâches qui dépendent de chaque tâche et toutes les tâches dont chaque tâche dépend.

Ajouté dans la version 212.

^ -with-dependencies Lorsqu’il est utilisé avec status, cat, list-units et list-unit-files, ces commandes affichent toutes les unités spécifiées ainsi que les dépendances de ces unités.

Les options --reverse, --after, --before peuvent être utilisées pour modifier le type de dépendances affichées.

Ajouté dans la version 245.

^ l, --full Ne tronque pas les noms d’unité, les entrées de l’arbre des processus, la sortie du journal ou les descriptions d’unité dans la sortie de status, list-units, list-jobs et list-timers.

Affiche également les cibles d’installation dans la sortie de is-enabled.

^ -value Lors de l’affichage des propriétés avec show, n’affiche que la valeur, et omet le nom de la propriété et le signe « = ». Voir également l’option -P ci-dessus.

Ajouté dans la version 230.

^ -show-types Lors de l’affichage des sockets, affiche 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 la façon de gérer les tâches déjà mises en file d’attente. Elle prend l’une des valeurs : « fail », « lenient », « replace », « replace-irreversibly », « isolate », « ignore-dependencies », « ignore-requirements », « flush », « triggering » ou « restart-dependencies ». Par défaut, « replace », sauf lorsque la commande isolate est utilisée, auquel cas le mode « isolate » est implicite.

Si « fail » est spécifié et qu’une opération demandée sur des dépendances faibles entre en conflit avec une tâche en attente (plus précisément : entraîne la transformation d’une tâche de démarrage en attente en une tâche d’arrêt ou vice versa), l’opération échoue.

Si « lenient » est spécifié et qu’une opération demandée entre en conflit avec une unité active ou en cours d’activation, l’opération échoue.

Si « replace » (par défaut) est spécifié, toute tâche en attente en conflit est remplacée si nécessaire.

Si « replace-irreversibly » est spécifié, le comportement est similaire à « replace », mais les nouvelles tâches sont également marquées comme irréversibles. Cela empêche les futures transactions conflictuelles de remplacer ces tâches (ou même d’être mises en file d’attente tant que les tâches irréversibles sont toujours en attente). Les tâches irréversibles peuvent toujours être annulées à l’aide de la commande cancel. Ce mode de tâche doit être utilisé pour toute transaction qui inclut shutdown.target.

« isolate » n’est valide que pour les opérations de démarrage et entraîne l’arrêt de toutes les autres unités lorsque l’unité spécifiée est démarrée. Ce mode est toujours utilisé lorsque la commande isolate est utilisée.

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

Si « ignore-dependencies » est spécifié, 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 cette option est utilisée, aucune des unités requises de l’unité spécifiée ne sera incluse, et aucune des dépendances d’ordre ne sera respectée. Il s’agit principalement d’un outil de débogage et de récupération pour l’administrateur et ne doit pas être utilisé par les applications.

« ignore-requirements » est similaire à « ignore-dependencies », mais ne fait qu’ignorer les dépendances de exigences, les dépendances d’ordre seront toujours respectées.

« triggering » ne peut être utilisé qu’avec systemctl stop. Dans ce mode, l’unité spécifiée et toutes les unités actives qui la déclenchent sont arrêtées. Voir la discussion sur Triggers= dans systemd.unit(5) pour plus d’informations sur les unités déclenchées.

« restart-dependencies » ne peut être utilisé qu’avec systemctl start. Dans ce mode, les dépendances de l’unité spécifiée recevront une propagation de redémarrage, comme si un travail de redémarrage avait été mis en file d’attente pour l’unité.

Ajouté dans la version 209.

-T, --show-transaction

Lors de la mise en file d’attente d’un travail d’unité (par exemple, en tant qu’effet d’une invocation systemctl start ou similaire), affichez de brèves informations sur tous les travaux mis en file d’attente, couvrant à la fois le travail demandé et tous ceux ajoutés en raison des dépendances de l’unité. Notez que la sortie n’inclura que les travaux qui font immédiatement partie de la transaction demandée. Il est possible que le code du programme de démarrage du service exécuté en tant qu’effet des travaux mis en file d’attente puisse demander l’ajout de davantage de travaux. Cela signifie que l’achèvement des travaux répertoriés peut finalement entraîner un plus grand nombre de travaux que ceux répertoriés.

Ajouté dans la version 242.

--fail

Raccourci pour --job-mode=fail.

Lorsqu’il est utilisé avec la commande kill, si aucune unité n’a été tuée, l’opération entraîne une erreur.

Ajouté dans la version 227.

--check-inhibitors=

Lorsqu’un arrêt ou une mise en veille du système est demandé, cette option contrôle la vérification des verrous d’inhibition. Elle prend l’une des valeurs « auto », « yes » et « no ». La valeur par défaut est « auto », ce qui signifie que logind effectuera la vérification et respectera les verrous d’inhibition actifs, mais systemctl n’effectuera qu’une vérification côté client pour les invocations interactives (c’est-à-dire à partir d’un TTY), de sorte qu’une erreur plus conviviale et plus informative puisse être renvoyée aux utilisateurs. « no » désactive les vérifications à la fois dans systemctl et systemd-logind(8).

Les applications peuvent établir des verrous d’inhibition pour empêcher certaines opérations importantes (telles que la gravure de CD) d’être interrompues par un arrêt ou une mise en veille du système. Tout utilisateur peut prendre ces verrous et les utilisateurs privilégiés peuvent les ignorer. Si des verrous sont pris, les demandes d’arrêt et de mise en veille échoueront généralement (sauf si elles sont explicitement ignorées avec « no »).

L’option --force fournit un autre moyen d’ignorer les inhibiteurs.

Ajouté dans la version 248.

-i

Raccourci pour --check-inhibitors=no.

Ajouté dans la version 198.

--dry-run

Affiche simplement ce qui serait fait. Actuellement pris en charge par les verbes halt, poweroff, reboot, kexec, suspend, hibernate, hybrid-sleep, suspend-then-hibernate, default, rescue, emergency et exit.

Ajouté dans la version 236.

-q, --quiet

Supprime l’impression des résultats de diverses commandes, ainsi que les indications sur les lignes de journal tronquées. Cela ne supprime pas la sortie des commandes pour lesquelles la sortie imprimée est le seul résultat (comme show). Les erreurs sont toujours imprimées.

-v, --verbose

Affiche la sortie du journal de l’unité pendant l’exécution des opérations sur l’unité.

Ajouté dans la version 258.

--no-warn

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

lorsque systemctl est invoqué sans que le système de fichiers procfs ne soit monté sur /proc,

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

lors de l’utilisation de disable combiné avec --user sur des unités qui sont activées dans la portée globale,

lorsqu’une unité arrêtée, désactivée ou masquée a encore des unités de déclenchement actives,

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

Ajouté dans la version 253.

--no-block

Ne pas attendre de manière synchrone que l’opération demandée soit terminée. Si cet argument n’est pas spécifié, le travail sera vérifié, mis en file d’attente et systemctl attendra jusqu’à ce que le démarrage de l’unité soit terminé. En passant cet argument, seule la vérification et la mise en file d’attente seront effectuées. Cette option ne peut pas être combinée avec --wait.

--wait

Lorsqu’il est utilisé avec start ou restart, attendre de manière synchrone que les unités démarrées se terminent à nouveau. Cette option ne peut pas être combinée avec --no-block. Notez que cela attendra indéfiniment si une unité donnée ne se termine jamais (par elle-même ou en étant explicitement arrêtée) ; en particulier les services qui utilisent « RemainAfterExit=yes ».

Lorsqu’il est utilisé avec is-system-running, attendre que le processus de démarrage soit terminé avant de renvoyer une valeur.

Lorsqu’il est utilisé avec kill, attendre que les unités signalées se terminent. Notez que cela attendra indéfiniment si une unité donnée ne se termine jamais.

Ajouté dans la version 232.

--user

Communiquer avec le gestionnaire de services de l’utilisateur appelant, plutôt qu’avec le gestionnaire de services du système.

--system

Communiquer avec le gestionnaire de services du système. C’est la valeur par défaut implicite.

--failed

Lister les unités dans un état d’échec. Ceci est équivalent à --state=failed.

Ajouté dans la version 233.

--no-wall

Ne pas envoyer de message wall avant halt, power-off et reboot.

--global

Lorsqu’il est utilisé avec enable et disable, opérer sur le répertoire de configuration utilisateur global, activant ou désactivant ainsi un fichier d’unité globalement pour toutes les futures connexions de tous les utilisateurs.

--no-reload

Lorsqu’il est utilisé avec enable, disable, preset, mask ou unmask, ne pas recharger implicitement la configuration du daemon après l’exécution des modifications.

--kill-whom=

Lorsqu’il est utilisé avec kill, choisir quels processus doivent recevoir un signal de processus UNIX. Doit être l’un des éléments suivants : main, control, cgroup ou all, afin de sélectionner si seuls le processus principal, le processus de contrôle, tous les processus du groupe de contrôle de l’unité ou tous les processus de l’unité doivent être tués. Le processus principal d’une unité est celui qui définit sa durée de vie. Un processus de contrôle d’une unité est celui qui est invoqué par le gestionnaire pour induire des changements d’état. Par exemple, tous les processus démarrés en raison des paramètres ExecStartPre=, ExecStop= ou ExecReload= des unités de service sont des processus de contrôle. Notez qu’il n’y a qu’un seul processus de contrôle par unité à la fois, car un seul changement d’état est exécuté à la fois. Pour les unités de service de type Type=forking, le processus initial démarré par le gestionnaire pour ExecStart= est un processus de contrôle, tandis que le processus finalement bifurqué par celui-ci est alors considéré comme le 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 bifurqué par le gestionnaire pour ExecStart= est toujours le processus principal lui-même. Une unité de service est composée de zéro ou un processus principal, de zéro ou un processus de contrôle, ainsi que de n’importe quel nombre de processus supplémentaires faisant partie du groupe de contrôle de l’unité. Cependant, tous les types d’unités ne gèrent pas les processus de ces types. Par exemple, pour les unités de montage, les processus de contrôle sont définis (qui sont les invocations de /usr/bin/mount et /usr/bin/umount), mais aucun processus principal n’est défini. S’il est omis, la valeur par défaut est all, sauf si --kill-subgroup= est utilisé, auquel cas la valeur par défaut est cgroup.

Ajouté dans la version 252.

--kill-value=INT

Si utilisé avec la commande kill, met en file d’attente un signal ainsi que la valeur entière spécifiée en tant que paramètre vers le ou les processus spécifiés. Cette opération est uniquement disponible pour les signaux POSIX en temps réel (c’est-à-dire --signal=SIGRTMIN+... ou --signal=SIGRTMAX-...), et garantit que les signaux sont générés via l’appel système sigqueue(3), plutôt que kill(3). La valeur spécifiée doit être un entier signé sur 32 bits, et peut être spécifiée soit en décimal, soit en hexadécimal (si elle est précédée de "0x"), en octal (si elle est précédée de "0o") ou en binaire (si elle est précédée de "0b").

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

Ajouté dans la version 254.

--kill-subgroup=PATH

Prend un sous-chemin de groupe de contrôle pour envoyer des signaux, pour une utilisation avec la commande kill. Par défaut, le signal choisi est envoyé à tous les processus des groupes de contrôle de l’unité (ainsi qu’aux processus principaux/de contrôle (s’ils sont en dehors), sous réserve de --kill-whom=). Mais avec cette option, un sous-groupe peut être sélectionné à la place. Cette fonctionnalité n’est disponible que si « cgroup » ou « cgroup-fail » sont utilisés avec --kill-whom=, et en fait, le premier est la valeur par défaut si --kill-subgroup= est utilisé.

Le chemin spécifié peut, mais n’a pas besoin d’être préfixé par une barre oblique, et son absence ou sa présence n’a aucun effet, le chemin est de toute façon pris par rapport au chemin principal du groupe de contrôle de l’unité.

Cette fonctionnalité n’est disponible que pour les unités où la délégation du groupe de contrôle est activée (voir Delegate= dans systemd.resource-control(5)).

Ajouté dans la version 258.

-s, --signal=

Lorsqu’il est utilisé avec kill, choisissez le signal à envoyer aux processus sélectionnés. Doit être l’une des spécifications de signal bien connues, telles que SIGTERM, SIGINT ou SIGSTOP. S’il est omis, la valeur par défaut est SIGTERM.

La valeur spéciale « help » affichera les valeurs connues et le programme se terminera immédiatement, et la valeur spéciale « list » affichera les valeurs connues ainsi que les numéros de signal numériques, et le programme se terminera immédiatement.

--what=

Sélectionne le type de ressources par unité à supprimer lorsque la commande clean est invoquée, voir ci-dessus. Prend l’une des valeurs configuration, state, cache, logs, runtime, fdstore pour sélectionner le type de ressource. Cette option peut être spécifiée plusieurs fois, auquel cas tous les types de ressources spécifiés sont supprimés. Accepte également la valeur spéciale all comme raccourci pour spécifier les six types de ressources. Si cette option n’est pas spécifiée, la valeur par défaut est la combinaison de cache, runtime et fdstore, c’est-à-dire les trois types de ressources qui sont généralement considérés comme redondants et peuvent être reconstitués lors de l’invocation suivante. Notez que la suppression explicite du type de ressource fdstore n’est utile que si l’option FileDescriptorStorePreserve= est activée, car le magasin de descripteurs de fichiers est automatiquement nettoyé lorsque l’unité est arrêtée.

Ajouté dans la version 243.

-f, --force

Lorsqu’il est utilisé avec enable, il écrase tous les liens symboliques conflictuels existants.

Lorsqu’il est utilisé avec edit, il crée toutes les unités spécifiées qui n’existent pas déjà.

Lorsqu’il est utilisé avec suspend, hibernate, hybrid-sleep ou suspend-then-hibernate, l’erreur renvoyée par systemd-logind est ignorée et l’opération est effectuée directement en démarrant les unités correspondantes.

Lorsqu’il est utilisé avec halt, poweroff, reboot ou kexec, il exécute l’opération sélectionnée sans arrêter toutes les unités. Cependant, 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 donc d’une option radicale mais relativement sûre pour demander un redémarrage immédiat. Si --force est spécifié deux fois pour ces opérations (à l’exception de kexec), elles seront exécutées immédiatement, sans terminer aucun processus ni démonter aucun système de fichiers.

Avertissement Spécifier --force deux fois avec l’une de ces opérations peut entraîner une perte de données. Notez que lorsque --force est spécifié deux fois, la commande 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 doit réussir même si le gestionnaire de système est en panne.

--message=

Lorsqu’il est utilisé avec halt, poweroff ou reboot, il définit un court message expliquant la raison de l’opération. Le message sera enregistré avec le message d’arrêt par défaut.

Ajouté dans la version 225.

--now

Lorsqu’il est utilisé avec enable, disable, mask ou reenable, il démarre/arrête/essaie de redémarrer également les unités après que les opérations de fichiers d’unité spécifiées ont réussi.

Ajouté dans la version 220.

--root=

Lorsqu’il est utilisé avec enable/disable/is-enabled (et les commandes associées), il utilise le chemin racine spécifié lors de la recherche des fichiers d’unité. Si cette option est présente, systemctl opère directement sur le système de fichiers, au lieu de communiquer avec le démon systemd pour effectuer les modifications.

--image=image

Prend un chemin vers un fichier image de disque ou un nœud de périphérique bloc. Si spécifié, toutes les opérations sont appliquées au système de fichiers dans l’image de disque indiquée. Cette option est similaire à --root=, mais fonctionne sur les systèmes de fichiers stockés dans des images de disque ou des périphériques bloc. L’image de disque doit contenir soit un seul système de fichiers, soit un ensemble de systèmes de fichiers dans une table de partition GPT, conformément à la spécification UAPI.2 Discoverable Partitions[2]. Pour plus d’informations sur les images de disque prises en charge, consultez l’option du même nom de systemd-nspawn(1).

Ajouté dans la version 252.

--image-policy=policy
Prend une chaîne de politique d’image en argument, conformément à systemd.image-policy(7). La politique est appliquée lors de l’opération sur l’image disque spécifiée via --image=, voir ci-dessus. Si elle n’est pas spécifiée, la politique par défaut est « * », c’est-à-dire que tous les systèmes de fichiers reconnus dans l’image sont utilisés.

--runtime
Lorsqu’il est utilisé avec enable, disable, edit (et les commandes associées), effectue uniquement des modifications temporaires, de sorte qu’elles sont perdues au prochain redémarrage. Cela aura pour effet que les modifications ne sont pas apportées dans les sous-répertoires de /etc/ mais dans /run/, avec des effets immédiats identiques, cependant, étant donné que ce dernier est perdu au redémarrage, les modifications sont également perdues.

De même, lorsqu’il est utilisé avec set-property, effectue des modifications uniquement temporaires, de sorte qu’elles sont perdues au prochain redémarrage.

--preset-mode=
Prend l’une des valeurs « full » (par défaut), « enable-only », « disable-only ». Lorsqu’il est utilisé avec les commandes preset ou preset-all, il contrôle si les unités doivent être désactivées et activées en fonction des règles de préréglage, ou seulement activées, ou seulement désactivées.

Ajouté dans la version 215.

-n, --lines=
Lorsqu’il est utilisé avec status, contrôle le nombre de lignes du journal à afficher, en comptant à partir des plus récentes. Prend un argument entier positif ou 0 pour désactiver la sortie du journal. Par défaut :

-o, --output=
Lorsqu’il est utilisé avec status, contrôle le format des entrées du journal qui sont affichées. Pour les options disponibles, voir [journalctl]({filename}../../journalctl)(1). Par défaut : « short ».

--firmware-setup
Lorsqu’il est utilisé avec les commandes reboot, poweroff ou halt, indique au micrologiciel du système de démarrer dans l’interface de configuration du micrologiciel lors du prochain démarrage. Notez que cette fonctionnalité n’est pas disponible sur tous les systèmes.

Ajouté dans la version 220.

--boot-loader-menu=timeout
Lorsqu’il est utilisé avec les commandes reboot, poweroff ou halt, indique au gestionnaire de démarrage du système d’afficher le menu du gestionnaire de démarrage au prochain démarrage. Prend une valeur de temps en paramètre, indiquant le délai d’expiration du menu. Passez zéro pour désactiver le délai d’expiration du menu. Notez que tous les gestionnaires de démarrage ne prennent pas en charge cette fonctionnalité.

Ajouté dans la version 242.

--boot-loader-entry=ID
Lorsqu’il est utilisé avec les commandes reboot, poweroff ou halt, indique au gestionnaire de démarrage du système de démarrer dans une entrée spécifique du gestionnaire de démarrage au prochain démarrage. Prend un identifiant d’entrée du gestionnaire de démarrage en argument, ou « help » pour afficher la liste des entrées disponibles. Notez que tous les gestionnaires de démarrage ne prennent pas en charge cette fonctionnalité.

Ajouté dans la version 242.

--reboot-argument=
Cet commutateur est utilisé avec reboot. La valeur est spécifique à l’architecture et au micrologiciel. Par exemple, « recovery » peut être utilisé pour déclencher la récupération du système, et « fota » peut être utilisé pour déclencher une mise à jour « firmware over the air ».

Ajouté dans la version 246.

--plain
Lorsqu’il est utilisé avec list-dependencies, list-units ou list-machines, la sortie est imprimée sous forme de liste au lieu d’un arbre, et les cercles de liste sont omis.

Ajouté dans la version 203.

--timestamp=
Modifie le format des horodatages imprimés. Les valeurs suivantes peuvent être utilisées :

pretty (c'est la valeur par défaut)
"Jour AAAA-MM-JJ HH:MM:SS TZ"

Ajouté dans la version 248.

unix
"@secondes-depuis-l'époque"

Ajouté dans la version 251.

us, μs
"Jour AAAA-MM-JJ HH:MM:SS.UUUUUU TZ"

Ajouté dans la version 248.

utc
"Jour AAAA-MM-JJ HH:MM:SS UTC"

Ajouté dans la version 248.

us+utc, μs+utc
"Jour AAAA-MM-JJ HH:MM:SS.UUUUUU UTC"

Ajouté dans la version 248.

Ajouté dans la version 247.

--mkdir

Lorsqu'il est utilisé avec bind, crée le fichier ou le répertoire de destination avant d'appliquer le montage. Notez que bien que le nom de cette option suggère qu'elle ne convient que pour les répertoires, cette option crée également le nœud de fichier de destination pour le montage si l'objet à monter n'est pas un répertoire, mais un fichier, un nœud de périphérique, une socket ou un FIFO.

Ajouté dans la version 248.

--marked

Autorisé uniquement avec reload-or-restart. Met en file d'attente les tâches de redémarrage pour toutes les unités qui ont le marqueur "needs-restart", et les tâches de rechargement pour les unités qui ont le marqueur "needs-reload". Lorsqu'une unité marquée pour le rechargement ne prend pas en charge le rechargement, une tâche de redémarrage sera mise en file d'attente. Ces propriétés peuvent être définies à l'aide de set-property Markers=....

Sauf si --no-block est utilisé, systemctl attendra que les tâches mises en file d'attente se terminent.

Ajouté dans la version 248.

--read-only

Lorsqu'il est utilisé avec bind, crée un montage bind en lecture seule.

Ajouté dans la version 248.

--drop-in=NOM

Lorsqu'il est utilisé avec edit, utilise NOM comme nom du fichier drop-in au lieu de override.conf.

Ajouté dans la version 253.

--when=

Lorsqu'il est utilisé avec halt, poweroff, reboot ou kexec, planifie l'action pour qu'elle soit effectuée à l'horodatage spécifié, qui doit respecter la syntaxe documentée dans systemd.time(7) section "PARSING TIMESTAMPS". En particulier, si "show" est spécifié, l'action planifiée actuellement sera affichée, ce qui peut être annulé en passant une chaîne vide ou "cancel". "auto" planifiera l'action en fonction de la fenêtre de maintenance ou une minute dans le futur.

Ajouté dans la version 254.

--stdin

Lorsqu'il est utilisé avec edit, le contenu du fichier sera lu à partir de l'entrée standard et l'éditeur ne sera pas lancé. Dans ce mode, le contenu précédent du fichier est complètement remplacé. Cela est utile pour "éditer" des fichiers d'unité à partir de scripts :

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

Plusieurs drop-ins peuvent être "édités" en mode ; le même contenu sera écrit dans tous.

Ajouté dans la version 256.

-H, --host=

Exécute l'opération à distance. Spécifiez un nom d'hôte, ou un nom d'utilisateur et un nom d'hôte séparés par un "@", pour vous connecter. Le nom d'hôte peut être suivi en option d'un port sur lequel SSH écoute, séparé par un ":" , puis d'un nom de conteneur, séparé par un "/", ce qui se connecte directement à un conteneur spécifique sur l'hôte spécifié. Cela utilisera SSH pour communiquer avec l'instance de gestion de machine distante. Les noms de conteneur peuvent être énumérés avec machinectl -H HOST. Placez les adresses IPv6 entre crochets.

-M, --machine=

Exécute l'opération sur un conteneur local. Spécifiez un nom de conteneur pour vous y connecter, éventuellement préfixé par un nom d'utilisateur pour se connecter en tant qu'utilisateur et séparé par un caractère "@". Si la chaîne spéciale ".host" est utilisée à la place du nom du conteneur, une connexion au système local est établie (ce qui est utile pour se connecter au bus utilisateur d'un utilisateur spécifique : "--user [email protected]"). Si la syntaxe "@" n'est pas utilisée, la connexion est établie en tant qu'utilisateur root. Si la syntaxe "@" est utilisée, soit la partie gauche, soit la partie droite peuvent être omises (mais pas les deux), auquel cas le nom d'utilisateur local et ".host" sont implicites.

-C, --capsule=
Exécute une opération sur une capsule. Spécifiez le nom de la capsule à laquelle se connecter. Voir [email protected](5)
pour plus de détails sur les capsules.

Ajouté dans la version 256.

--no-ask-password
Ne pas demander à l'utilisateur une authentification pour les opérations privilégiées.

--no-pager
Ne pas rediriger la sortie vers un paginateur.

--legend=BOOL
Active ou désactive l'impression de la légende, c'est-à-dire des en-têtes de colonne et du pied de page contenant des indications.
La légende est imprimée par défaut, sauf si elle est désactivée avec --quiet ou une option similaire.

-h, --help
Affiche un bref texte d'aide et quitte.

--version
Affiche une brève chaîne de version et quitte.

CODE DE RETOUR

En cas de succès, 0 est renvoyé, un code d'erreur non nul est renvoyé en cas d'échec.

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

Tableau 5. Codes de retour LSB

┌───────┬────────────────────────────┬──────────────────────────┐
│ Valeur│ Description dans LSB        │ Utilisation dans systemd  │
├───────┼────────────────────────────┼──────────────────────────┤
│ 0     │ "le programme est en cours  │ l'unité est active        │
│       │ d'exécution ou le service  │                          │
│       │ est OK"                    │                          │
├───────┼────────────────────────────┼──────────────────────────┤
│ 1     │ "le programme est arrêté et│ l'unité n'a pas échoué    │
│       │ le fichier PID dans        │ (utilisé par is-failed)   │
│       │ /var/run existe"          │                          │
├───────┼────────────────────────────┼──────────────────────────┤
│ 2     │ "le programme est arrêté et│ non utilisé               │
│       │ le fichier de verrouillage │                          │
│       │ dans /var/lock existe"     │                          │
├───────┼────────────────────────────┼──────────────────────────┤
│ 3     │ "le programme n'est pas en  │ l'unité n'est pas active  │
│       │ cours d'exécution"         │                          │
├───────┼────────────────────────────┼──────────────────────────┤
│ 4     │ "le statut du programme ou  │ aucune unité correspondante│
│       │ du service est inconnu"    │                          │
└───────┴────────────────────────────┴──────────────────────────┘

L’appariement entre les états des services LSB et les états des unités systemd est imparfait. Il est donc préférable de ne pas se fier à ces valeurs de retour, mais plutôt de rechercher des états et sous-états d’unités spécifiques.

ENVIRONNEMENT

$SYSTEMD_EDITOR
Éditeur à utiliser lors de la modification des unités ; il remplace $EDITOR et $VISUAL. Si ni $SYSTEMD_EDITOR ni $EDITOR ni $VISUAL ne sont présents, ou s’ils sont définis sur une chaîne vide, ou si leur exécution échoue, systemctl tentera d’exécuter les éditeurs bien connus dans l’ordre suivant : editor(1), [nano]({filename}../../nano)(1), [vim]({filename}../../vim)(1), vi(1).

Ajouté dans la version 218.

$SYSTEMD_LOG_LEVEL
Le niveau de journalisation maximal des messages émis (les messages ayant un niveau de journalisation plus élevé, c’est-à-dire moins importants, seront supprimés). Prend une liste de valeurs séparées par des virgules. Une valeur peut être l’une des suivantes (par ordre d’importance décroissante) : emerg, alert, crit, err, warning, notice, info, debug, ou un entier dans la plage de 0 à 7. Voir syslog(3) pour plus d’informations. Chaque valeur peut éventuellement être préfixée par l’une des valeurs suivantes : console, syslog, kmsg ou journal, suivie d’un deux-points, afin de définir le niveau de journalisation maximal pour cette cible de journalisation spécifique (par exemple, SYSTEMD_LOG_LEVEL=debug,console:info spécifie que la journalisation doit se faire au niveau debug, sauf lors de la journalisation vers la console, ce qui doit se faire au niveau info). Notez que le niveau de journalisation maximal global a la priorité sur tous les niveaux de journalisation maximaux par cible.

$SYSTEMD_LOG_COLOR
Une valeur booléenne. Si la valeur est true, les messages écrits sur le TTY seront colorés en fonction de leur priorité.

Ce paramètre n’est utile que lorsque les messages sont écrits directement sur le terminal, car [journalctl]({filename}../../journalctl)(1) et d’autres outils qui affichent les journaux coloreront les messages en fonction du niveau de journalisation.

$SYSTEMD_LOG_TIME
Une valeur booléenne. Si la valeur est true, les messages de journalisation de la console seront préfixés d’un horodatage.

Ce paramètre n’est utile que lorsque les messages sont écrits directement sur un terminal ou dans un fichier, car [journalctl]({filename}../../journalctl)(1) et d’autres outils qui affichent les journaux attacheront des horodatages en fonction des métadonnées de l’entrée.

$SYSTEMD_LOG_LOCATION
Une valeur booléenne. Si la valeur est true, les messages seront préfixés du nom de fichier et du numéro de ligne dans le code source où le message a été généré.

Notez que l’emplacement du journal est souvent ajouté en tant que métadonnées aux entrées du journal. L’inclure directement dans le texte du message peut néanmoins être pratique lors du débogage des programmes.

$SYSTEMD_LOG_TARGET
La destination des messages de journalisation. L’une des valeurs suivantes : console (journalisation sur le TTY connecté), console-prefixed (journalisation sur le TTY connecté, mais avec des préfixes codant le niveau de journalisation et la « facility », voir syslog(3), kmsg (journalisation sur le tampon de journalisation circulaire du noyau), journal (journalisation dans le journal), journal-or-kmsg (journalisation dans le journal si celui-ci est disponible, et dans kmsg sinon), auto (déterminer automatiquement la cible de journalisation appropriée, la valeur par défaut), null (désactiver la sortie de journalisation).

$SYSTEMD_PAGER, $PAGER
Paginateur à utiliser lorsque l’option --no-pager n’est pas spécifiée. $SYSTEMD_PAGER est utilisé si elle est définie ; sinon, $PAGER est utilisé. Si ni $SYSTEMD_PAGER ni $PAGER ne sont définies, une série d’implémentations de paginateur bien connues est essayée à tour de rôle, notamment [less]({filename}../../less)(1) et more(1), jusqu’à ce qu’une soit trouvée. Si aucune implémentation de paginateur n’est découverte, aucun paginateur n’est invoqué. Définir ces variables d’environnement sur une chaîne vide ou sur la valeur « cat » équivaut à utiliser l’option --no-pager.

Remarque : si $SYSTEMD_PAGERSECURE n’est pas définie, $SYSTEMD_PAGER et $PAGER ne peuvent être utilisées que pour désactiver le paginateur (avec « cat » ou une chaîne vide) et sont sinon ignorées.

$SYSTEMD_LESS
Remplace les options transmises à less (par défaut « FRSXMK »).

Les utilisateurs peuvent souhaiter modifier deux options en particulier :

K
Cette option indique au paginateur de quitter immédiatement lorsque Ctrl+C est enfoncé. Pour permettre à less de gérer Ctrl+C lui-même afin de revenir à l’invite de commandes du paginateur, désactivez cette option.

Si la valeur de $SYSTEMD_LESS n’inclut pas « K », et que le paginateur invoqué est less, Ctrl+C sera ignoré par l’exécutable et devra être géré par le paginateur.

X
Cette option indique au paginateur de ne pas envoyer de chaînes d’initialisation et de désinitialisation termcap au terminal. Elle est définie par défaut pour permettre à la sortie de la commande de rester visible dans le terminal même après la fermeture du paginateur. Cependant, cela empêche certaines fonctionnalités du paginateur de fonctionner, en particulier la sortie paginée ne peut pas être défilée avec la souris.

Remarque : la définition de la variable d’environnement standard $LESS n’a aucun effet pour les invocations de less par les outils systemd.

Consultez [less]({filename}../../less)(1) pour plus d’informations.

$SYSTEMD_LESSCHARSET
Remplace le jeu de caractères transmis à less (par défaut « utf-8 », si le terminal d’invocation est considéré comme compatible UTF-8).

Remarque : la définition de la variable d’environnement standard $LESSCHARSET n’a aucun effet pour les invocations de less par les outils systemd.

$SYSTEMD_PAGERSECURE
Les commandes de paginateur courantes telles que [less]({filename}../../less)(1), en plus de la « pagination », c’est-à-dire du défilement de la sortie, prennent en charge l’ouverture ou l’écriture dans d’autres fichiers et l’exécution de commandes shell arbitraires. Lorsque les commandes sont invoquées avec des privilèges élevés, par exemple sous [sudo]({filename}../../sudo)(8) ou pkexec(1), le paginateur devient une limite de sécurité. Il faut veiller à ce que seuls les programmes ayant une fonctionnalité strictement limitée soient utilisés comme paginateurs, et que des fonctionnalités interactives non intentionnelles telles que l’ouverture ou la création de nouveaux fichiers ou le démarrage de sous-processus ne soient pas autorisées. Le « mode sécurisé » pour le paginateur peut être activé comme décrit ci-dessous, si le paginateur le prend en charge (la plupart des paginateurs ne sont pas écrits de manière à en tenir compte). Il est recommandé d’activer explicitement le « mode sécurisé » ou de désactiver complètement le paginateur à l’aide de l’option --no-pager ou PAGER=cat lorsque des utilisateurs non approuvés 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 sur true, le « mode sécurisé » du paginateur est activé. En « mode sécurisé », LESSSECURE=1 est défini lors de l’appel du paginateur, ce qui lui indique de désactiver les commandes qui ouvrent ou créent de nouveaux fichiers ou qui lancent de nouveaux sous-processus. Actuellement, seul less(1) est connu pour prendre en charge cette variable et implémenter le « mode sécurisé ».

Lorsqu’elle est définie sur false, aucune restriction n’est appliquée au paginateur. Définir SYSTEMD_PAGERSECURE=0 ou ne pas la supprimer de l’environnement hérité peut permettre à l’utilisateur d’exécuter des commandes arbitraires.

Lorsque $SYSTEMD_PAGERSECURE n’est pas défini, les outils systemd tentent de déterminer automatiquement si le « mode sécurisé » doit être activé et si le paginateur le prend en charge. Le « mode sécurisé » est activé si l’UID effectif n’est pas le même que 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 [4]). Dans ces cas, SYSTEMD_PAGERSECURE=1 est défini et les paginateurs qui ne prennent pas en charge le « mode sécurisé » ne sont pas utilisés. Notez que cette détection automatique ne couvre que les mécanismes d’élévation de privilèges les plus courants et est destinée à faciliter son utilisation. Il est recommandé de définir explicitement $SYSTEMD_PAGERSECURE ou de désactiver le paginateur.

Notez que si les variables $SYSTEMD_PAGER ou $PAGER doivent être prises en compte, autre que pour désactiver le paginateur, $SYSTEMD_PAGERSECURE doit également être définie.

$SYSTEMD_COLORS

Prend un argument booléen. Lorsqu’elle est définie sur true, systemd et les utilitaires connexes utiliseront des couleurs dans leur sortie, sinon la sortie sera monochrome. De plus, la variable peut prendre l’une des valeurs spéciales suivantes : « 16 », « 256 » pour limiter l’utilisation des couleurs aux 16 ou 256 couleurs ANSI de base, respectivement. Cela peut être spécifié pour remplacer la décision automatique basée sur $TERM et sur la connexion de la console.

$SYSTEMD_URLIFY

La valeur doit être un booléen. Contrôle si des liens cliquables doivent être générés dans la sortie pour les émulateurs de terminal qui prennent en charge cette fonctionnalité. Cela peut être spécifié pour remplacer la décision que systemd prend en fonction de $TERM et d’autres conditions.

VOIR AUSSI

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

NOTES

Spécification UAPI.1 du chargeur de démarrage
https://uapi-group.org/specifications/specs/boot_loader_specification

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

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

    Il est recommandé que d’autres outils définissent et vérifient $SUDO_UID de manière appropriée, en le traitant comme une interface commune.

Man » Manuel systemctl en ligne - documentation en ligne détaillée pour la page de manuel systemctl

SYNTAXE

DESCRIPTION

COMMANDES

Commandes d’unité (introspection et modification)

Commandes de fichiers d'unité

Commandes Machine

Commandes Job

Commandes Environnement

Commandes d’état du gestionnaire

Commandes système

Syntaxe des paramètres

OPTIONS

CODE DE RETOUR

ENVIRONNEMENT

VOIR AUSSI

NOTES

cron

crontab

service

systemd

as

busybox

date

df

dmesg

efivar

env

expr