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

Cette commande produit une sortie similaire à

  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION


  sys-module-fuse.device       loaded active plugged /sys/module/fuse


  -.mount                      loaded active mounted Root Mount


  boot-efi.mount               loaded active mounted /boot/efi


  systemd-journald.service     loaded active running Journal Service


  systemd-logind.service       loaded active running Login Service
● user@1000.service            loaded failed failed  User Manager for UID 1000


  ...


  systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
123 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

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

La colonne LOAD montre l'état de chargement et peut avoir pour valeur loaded, not-found, bad-setting, error ou masked. La colonne ACTIVE montre l'état général de l'unité et peut avoir pour valeur active, reloading, inactive, failed, activating ou deactivating. La colonne SUB montre l’état spécifique au type de l'unité de façon détaillée, les valeurs possibles varient selon le type d'unité. La liste des états possibles LOAD, ACTIVE et SUB n'est pas constante et les nouvelles versions de systemd peuvent à la fois ajouter et supprimer des valeurs.

systemctl --state=help

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

C'est la commande par défaut.

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

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

Ajouté dans la version 252.

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

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

Ajouté dans la version 254.

LISTEN           UNIT                        ACTIVATES
/dev/initctl     systemd-initctl.socket      systemd-initctl.service
...
[::]:22          sshd.socket                 sshd.service
kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
5 sockets listés.

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

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

Ajouté dans la version 202.

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


            

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

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

LAST affiche le dernier moment de fonctionnement du temporisateur.

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

UNIT affiche le nom du temporisateur

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

Voir aussi --all et --state=.

Ajouté dans la version 206.

Ajouté dans la version 197.

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

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

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

Exemple 1.  Exemple de sortie de systemctl status

$ systemctl status bluetooth
● bluetooth.service - Bluetooth service


   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)


   Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago


     Docs: man:bluetoothd(8)


 Main PID: 930 (bluetoothd)


   Status: "Running"


    Tasks: 1


   Memory: 648.0K


      CPU: 435ms


   CGroup: /system.slice/bluetooth.service


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

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

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

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

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

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

Ajouté dans la version 206.

Ajouté dans la version 185.

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

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

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

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

Ajouté dans la version 198.

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

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

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

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

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

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

Ajouté dans la version 229.

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

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

Ajouté dans la version 243.

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

Ajouté dans la version 246.

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

Ajouté dans la version 246.

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

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

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

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

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

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

Ajouté dans la version 206.

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

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

Ajouté dans la version 248.

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

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

Exemple :

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

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

Ajouté dans la version 248.

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

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

Ajouté dans la version 247.

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

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

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

Ajouté dans la version 247.

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

Ajouté dans la version 254.

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

Ajouté dans la version 233.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ajouté dans la version 238.

Ajouté dans la version 238.

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

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

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

Ajouté dans la version 238.

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

Ajouté dans la version 215.

Table 1.  is-enabled output

Ajouté dans la version 238.

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

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

Ajouté dans la version 238.

Ajouté dans la version 238.

Ajouté dans la version 233.

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

Ajouté dans la version 198.

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

Ajouté dans la version 217.

Selon que --system (par défaut), --user ou --global est indiqué, cette commande crée un fichier de substitution pour chaque unité à la fois pour le système, l'utilisateur appelant ou pour toutes les futures connexions de tous les utilisateurs. Ainsi, l'éditeur (voir la section « Environnement » ci-dessous) est invoqué sur des fichiers temporaires qui seront écrits à l'emplacement réel si l'éditeur quitte avec succès.

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

Si --full est indiqué, cette commande copiera les unités d'origine au lieu de créer des fichiers de substitution.

Si --force est indiqué et qu'aucune unité n'existe déjà, des nouveaux fichiers d'unité seront ouverts pour être édités.

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

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

Après que les unités ont été éditées, la configuration de systemd est rechargée (de façon équivalente à daemon-reload).

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

Ajouté dans la version 218.

Ajouté dans la version 205.

Ajouté dans la version 205.

Ajouté dans la version 212.

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

Ajouté dans la version 233.

Ajouté dans la version 233.

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

Notez que cela agit sur un bloc d'environnement séparé du bloc d'environnement configuré par le service gestionnaire de configuration et les générateurs d'environnement. Chaque fois qu'un processus est appelé, les deux blocs sont combinés (incorporant aussi toutes les variables d'environnement par service) et transmis au processus. show-environment affichera la combinaison des blocs, voir ci-dessus.

Ajouté dans la version 233.

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

Ajouté dans la version 233.

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

Ajouté dans la version 206.

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

Ajouté dans la version 244.

Ajouté dans la version 244.

Ajouté dans la version 244.

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

Table 2. sortie de is-system-running

Ajouté dans la version 215.

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

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

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

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

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

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

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

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

Ajouté dans la version 246.

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

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

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

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

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

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

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

Ajouté dans la version 254.

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

Ajouté dans la version 227.

Ajouté dans la version 206.

Ajouté dans la version 196.

Ajouté dans la version 240.

# systemctl start sshd

# systemctl start sshd.service

# systemctl isolate default

# systemctl isolate default.target

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

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

# systemctl stop sshd@*.service

# systemctl enable truc.service

# systemctl link /chemin/vers/truc.service