Systemd est un système init et un gestionnaire de système qui devient largement le nouveau standard pour les machines Linux. Bien qu'il existe de nombreuses opinions quant à savoir si systemd représente une amélioration par rapport aux systèmes SysVinit qu’il remplace, la majorité des distributions prévoient de l’adopter ou l’ont déjà fait.
Les commandes systemctl suivantes permettent de gérer l'état du système.
| Systemd command | Description |
|---|---|
| systemctl halt | Arrêter le système. |
| systemctl poweroff | Eteint le système. |
| systemctl reboot | Redémarrage du système. |
| systemctl suspend | Suspend le système. |
| systemctl hibernate | Hiberne le système. |
| systemctl hybrid-sleep | Hiberner et suspendre le système. |
| SysVinit runlevel | Systemd target | Notes |
|---|---|---|
| 0 | runlevel0.target, poweroff.target | Halt the system. |
| 1, s, single | runlevel1.target, rescue.target | Single user mode. |
| 2, 4 | runlevel2.target, runlevel4.target, multi-user.target | User-defined runlevels (identical to 3). |
| 3 | runlevel3.target, multi-user.target | Multi-user, non-graphical. |
| 5 | runlevel5.target, graphical.target | Multi-user, graphical. |
| 6 | runlevel6.target, reboot.target | Reboot. |
| emergency | emergency.target | Emergency shell. |
Pour démarrer un service systemd en exécutant des instructions dans le fichier d'unité du service, utilisez la commande start. Si vous travaillez en tant qu'utilisateur non-root, vous devrez utiliser sudo, car cela affectera l'état du système d'exploitation:
sudo systemctl start application.service
Comme nous l'avons mentionné ci-dessus, systemd sait qu'il doit rechercher les fichiers *.service pour les commandes de gestion des services, de sorte que la commande peut tout aussi bien être saisie de la manière suivante:
sudo systemctl start application
Bien que vous puissiez utiliser le format ci-dessus pour l'administration générale, pour des raisons de clarté, nous utiliserons le suffixe .service pour que le reste des commandes soit explicite sur la cible sur laquelle nous opérons.
Pour arrêter un service en cours d'exécution, vous pouvez utiliser la commande stop à la place:
sudo systemctl stop application.service
Pour redémarrer un service en cours d'exécution, vous pouvez utiliser la commande “restart”:
sudo systemctl restart application.service
Si l'application en question est capable de recharger ses fichiers de configuration (sans redémarrer), vous pouvez émettre la commande “reload” pour lancer ce processus:
sudo systemctl reload application.service
Si vous ne savez pas si le service dispose de la fonctionnalité pour recharger sa configuration, vous pouvez émettre la commande “reload-or-restart”. Cela rechargera la configuration sur place si elle est disponible. Sinon, le service redémarrera pour que la nouvelle configuration soit prise en compte:
sudo systemctl reload-or-restart application.service
Les commandes ci-dessus sont utiles pour démarrer ou arrêter des commandes pendant la session en cours. Pour indiquer à systemd de démarrer les services automatiquement au démarrage, vous devez les activer.
Pour démarrer un service au démarrage, utilisez la commande “enable”:
sudo systemctl enable application.service
Cela créera un lien symbolique à partir de la copie système du fichier de service (généralement dans /lib/systemd/system ou /etc/systemd/system) vers l'emplacement sur le disque où systemd recherchera les fichiers à démarrage automatique (habituellement /etc/systemd/system/some_target.target.wants
Pour désactiver le service de démarrage automatique, vous pouvez taper:
sudo systemctl disable application.service
Cela supprimera le lien symbolique indiquant que le service doit être démarré automatiquement.
N'oubliez pas que l'activation d'un service ne le démarre pas dans la session en cours. Si vous souhaitez démarrer le service et l'activer au démarrage, vous devez exécuter les commandes “start” et “enable”.
Pour vérifier le statut d'un service sur votre système, vous pouvez utiliser la commande status:
systemctl status application.service
Cela vous fournira l'état du service, la hiérarchie du groupe de contrôle et les premières lignes de journal.
Par exemple, lors de la vérification de l'état d'un serveur Nginx, vous pouvez voir une sortie comme celle-ci:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
Cela vous donne un bon aperçu du statut actuel de l'application, vous informant de tout problème et de toute action pouvant être requise.
Il existe également des méthodes pour vérifier des états spécifiques. Par exemple, pour vérifier si une unité est actuellement active (en cours d'exécution), vous pouvez utiliser la commande is-active:
systemctl is-active application.service
Cela retournera l'état actuel de l'unité, qui est généralement actif ou inactif. Le code de sortie sera “0” s'il est actif, ce qui simplifie l'analyse du résultat.
Pour voir si l'unité est activée, vous pouvez utiliser la commande is-enabled:
systemctl is-enabled application.service
Cela indiquera si le service est activé ou désactivé et définira à nouveau le code de sortie sur “0” ou “1” en fonction de la réponse à la question de la commande.
Une troisième vérification consiste à déterminer si l'unité est en état d'échec. Cela indique qu’un problème est survenu lors du démarrage de l’unité en question:
systemctl is-failed application.service
Cela retournera actif s'il fonctionne correctement ou échoue si une erreur survient. Si l'unité a été arrêtée intentionnellement, elle peut renvoyer inconnue ou inactive. Un état de sortie de “0” indique qu'une défaillance est survenue et un état de sortie de “1” indique tout autre état.
Jusqu'à présent, les commandes ont été utiles pour gérer des services uniques, mais elles ne le sont pas beaucoup pour explorer l'état actuel du système. Un certain nombre de commandes “systemctl” fournissent ces informations.
Pour voir une liste de toutes les unités actives connues de systemd, utilisez la commande list-units:
systemctl list-units
Cela vous montrera une liste de toutes les unités que systemd a actuellement actives sur le système. La sortie ressemblera à ceci:
UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System getty@tty1.service loaded active running Getty on tty1 . . .
La sortie contient les colonnes suivantes:
Étant donné que la commande “list-units” affiche uniquement les unités actives par défaut, toutes les entrées ci-dessus indiqueront “chargé” dans la colonne LOAD et “actif” dans la colonne ACTIVE. Cet affichage est en fait le comportement par défaut de systemctl lorsqu'il est appelé sans commandes supplémentaires. Vous verrez donc la même chose si vous appelez systemctl sans arguments:
systemctl
Nous pouvons dire à “systemctl” de générer différentes informations en ajoutant des indicateurs supplémentaires. Par exemple, pour voir toutes les unités que “systemd” a chargées (ou tenté de charger), qu'elles soient actives ou non, vous pouvez utiliser l'indicateur –all, comme ceci:
systemctl list-units --all
Vous pouvez utiliser d'autres indicateurs pour filtrer ces résultats. Par exemple, nous pouvons utiliser le flag –state= pour indiquer les états LOAD, ACTIVE ou SUB que nous souhaitons voir. Vous devrez conserver le flag –all pour que “systemctl” autorise l'affichage des unités non actives.
systemctl list-units --all --state=inactive
Un autre filtre commun est le filtre –type=. Nous pouvons dire à “systemctl” de n’afficher que les unités du type qui nous intéresse. Par exemple, pour afficher uniquement les unités de service actives, nous pouvons utiliser:
systemctl list-units --type=service
La commande list-units affiche uniquement les unités que “systemd” a tenté d’analyser et de charger en mémoire. Comme systemd ne lira que les unités dont il pense avoir besoin, cela n'inclura pas nécessairement toutes les unités disponibles sur le système. Pour voir chaque fichier d'unité disponible dans les chemins d'accès systemd, y compris ceux que systemd n'a pas essayé de charger, vous pouvez utiliser la commande list-unit-files:
systemctl list-unit-files
Les unités sont des représentations de ressources connues de systemd. Comme systemd n'a pas nécessairement lu toutes les définitions d'unités de cette vue, il ne présente que des informations sur les fichiers eux-mêmes. La sortie comporte deux colonnes: le fichier unité et l'état.
UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled
L'état sera généralement “enabled”, “disabled”, “static” ou “masked”. Dans ce contexte, “static” signifie que le fichier d'unité ne contient pas de section “install”, utilisée pour activer une unité. En tant que tels, ces unités ne peuvent pas être activées. Cela signifie généralement que l'unité exécute une action unique ou est utilisée uniquement comme dépendance d'une autre unité et ne doit pas être exécutée par elle-même.
Nous pouvons trouver des informations plus spécifiques sur les unités en utilisant des commandes supplémentaires.
Pour afficher le fichier d'unité chargé par systemd dans son système, vous pouvez utiliser la commande “cat” (elle a été ajoutée dans la version 209 de systemd). Par exemple, pour voir le fichier d'unité du démon de planification “atd”, nous pourrions taper:
systemctl cat atd.service
[Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target
La sortie est le fichier d'unité connu du processus systemd en cours d'exécution. Cela peut être important si vous avez récemment modifié des fichiers unité ou si vous redéfinissez certaines options dans un fragment de fichier unité.
Pour voir l'arbre de dépendance d'une unité, vous pouvez utiliser la commande “list-dependencies”:
systemctl list-dependencies sshd.service
Ceci affichera une hiérarchie mappant les dépendances qui doivent être traitées afin de démarrer l'unité en question. Les dépendances, dans ce contexte, incluent les unités qui sont requises ou recherchées par les unités situées au-dessus de celle-ci.
sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target ...
Les dépendances récursives ne sont affichées que pour les unités .target, qui indiquent les états du système. Pour lister toutes les dépendances de manière récursive, incluez l'indicateur --all.
Pour afficher les dépendances inverses (unités qui dépendent de l'unité spécifiée), vous pouvez ajouter l'indicateur --reverse à la commande. Les autres indicateurs utiles sont les indicateurs --before et --after, qui peuvent être utilisés pour afficher les unités dépendant de l'unité spécifiée commençant avant et après elles-mêmes.
Pour voir les propriétés de bas niveau d'une unité, vous pouvez utiliser la commande “show”. Cela affichera une liste des propriétés définies pour l'unité spécifiée à l'aide d'un format clé=valeur:
systemctl show sshd.service
Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon ...
Si vous souhaitez afficher une seule propriété, vous pouvez passer l'indicateur -p avec le nom de la propriété. Par exemple, pour voir les conflits que l'unité “sshd.service” a, vous pouvez taper:
systemctl show sshd.service -p Conflicts
Conflicts=shutdown.target
Systemd a également la possibilité de marquer une unité comme complètement non démarrable, automatiquement ou manuellement, en la reliant à /dev/null.
Ceci s'appelle masquer l'unité, et est possible avec la commande “mask”:
sudo systemctl mask nginx.service
Cela empêchera le démarrage du service Nginx, automatiquement ou manuellement, tant qu'il sera masqué.
Si vous vérifiez les fichiers d'unité de liste, vous verrez que le service est maintenant répertorié comme masqué:
systemctl list-unit-files
... kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static ...
Si vous essayez de démarrer le service, vous verrez un message comme celui-ci:
sudo systemctl start nginx.service
Failed to start nginx.service: Unit nginx.service is masked.
Pour rendre une unité opérationnelle et la rendre utilisable à nouveau, utilisez simplement la commande “unmask”:
sudo systemctl unmask nginx.service
Systemctl fournit des mécanismes intégrés pour l'édition et la modification de fichiers d'unité si vous devez effectuer des ajustements. Cette fonctionnalité a été ajoutée à la version 218 de Systemd.
Par défaut, la commande d'édition ouvre un extrait de fichier d'unité pour l'unité en question:
sudo systemctl edit nginx.service
Si vous souhaitez éditer le fichier d'unité complet au lieu de créer un extrait, vous pouvez passer l'indicateur --full:
sudo systemctl edit --full nginx.service
Cela chargera le fichier d'unité actuel dans l'éditeur, où il pourra être modifié. Lorsque l'éditeur sera fermé, le fichier modifié sera écrit dans “/etc/systemd/system”, qui aura priorité sur la définition de l'unité du système (généralement située quelque part dans “/lib/systemd/system”).
Pour supprimer les ajouts que vous avez apportés, supprimez le répertoire de configuration “.d” de l'unité ou le fichier de service modifié de “/etc/systemd/system”.
Par exemple, pour supprimer un extrait, nous pourrions taper:
sudo rm -r /etc/systemd/system/nginx.service.d
Pour supprimer un fichier d'unité modifié, nous tapons:
sudo rm /etc/systemd/system/nginx.service
Après avoir supprimé le fichier ou le répertoire, vous devez recharger le processus systemd afin qu’il ne tente plus de faire référence à ces fichiers et ne revienne plus à utiliser les copies système.
Vous pouvez le faire en tapant:
sudo systemctl daemon-reload
Les cibles Systemd sont représentées par des unités de cible (« target units »). Les unités de cible se terminent par l'extension de fichier “.target” et leur unique but consiste à regrouper d'autres unités Systemd dans une chaîne de dépendances.
Par exemple, l'unité “graphical.target”, qui est utilisée pour lancer une session graphique, lance des services système comme le gestionnaire d'affichage GNOME (“gdm.service”) ou le services des comptes (“accounts-daemon.service”) et active également l'unité multi-user “.target”.
De manière similaire, l'unité “multi-user.target” lance d'autres services système essentiels, tels que NetworkManager (“NetworkManager.service”) ou D-Bus (“dbus.service”) et active une autre unité cible nommée “basic.target”.
Comparaison des niveaux d'exécution SysV avec les cibles Systemd
| Niveau d'exécution | Unités de cible | Description |
|---|---|---|
| 0 | runlevel0.target, poweroff.target | Quitter et éteindre le système. |
| 1 | runlevel1.target, rescue.target | Installer un shell de secours. |
| 2 | runlevel2.target, multi-user.target | Installer un système multi-utilisateurs non graphique. |
| 3 | runlevel3.target, multi-user.target | Installer un système multi-utilisateurs non graphique. |
| 4 | runlevel4.target, multi-user.target | Installer un système multi-utilisateurs non graphique. |
| 5 | runlevel5.target, graphical.target | Installer un système graphique multi-utilisateurs. |
| 6 | runlevel6.target, reboot.target | Quitter et redémarrer le système. |
Le processus “systemd” a une cible par défaut qu'il utilise lors du démarrage du système. La satisfaction de la cascade de dépendances à partir de cette cible unique amènera le système à l'état souhaité. Pour trouver la cible par défaut pour votre système, tapez:
# systemctl get-default
multi-user.target
Si vous souhaitez définir une cible par défaut différente, vous pouvez utiliser la valeur par défaut. Par exemple, si vous avez un bureau graphique installé et que vous souhaitez que le système démarre par défaut sur cellui-ci, vous pouvez modifier votre cible par défaut en conséquence:
sudo systemctl set-default graphical.target
Vous pouvez obtenir une liste des cibles disponibles sur votre système en tapant:
systemctl list-unit-files --type=target
Contrairement aux niveaux d'exécution, plusieurs cibles peuvent être actives en même temps. Une cible active indique que systemd a tenté de démarrer toutes les unités liées à la cible et n'a pas tenté de les détruire à nouveau.
Pour voir toutes les cibles actives, tapez:
systemctl list-units --type=target
Des cibles sont définies pour des événements importants tels que la mise hors tension ou le redémarrage. Cependant, systemctl a aussi des raccourcis qui ajoutent des fonctionnalités supplémentaires.
Par exemple, pour mettre le système en mode de secours (utilisateur unique), vous pouvez simplement utiliser la commande “rescue” au lieu d’isoler “rescue.target” :
sudo systemctl rescue
Cela fournira la fonctionnalité supplémentaire d'alerter tous les utilisateurs connectés sur l'événement.
Pour arrêter le système, vous pouvez utiliser la commande “halt”:
sudo systemctl halt
Pour lancer un arrêt complet, vous pouvez utiliser la commande “poweroff”:
sudo systemctl poweroff
Un redémarrage peut être démarré avec la commande “reboot”:
sudo systemctl reboot
Ils avertissent tous les utilisateurs connectés que l'événement se produit, ce qui ne fera pas que simplement exécuter ou isoler la cible. Notez que la plupart des machines lieront les commandes les plus courtes et les plus conventionnelles pour ces opérations afin qu'elles fonctionnent correctement avec systemd.
Par exemple, pour redémarrer le système, vous pouvez généralement taper:
sudo reboot