introduction
Systemd est un système d'initialisation et un gestionnaire de système qui est en train de devenir le nouveau standard pour les machines Linux. Bien qu'il y ait des opinions considérables sur la question de savoir sisystemd est une amélioration par rapport aux systèmes init traditionnels deSysV qu'il remplace, la majorité des distributions prévoient de l'adopter ou l'ont déjà fait.
En raison de son adoption massive, se familiariser avecsystemd en vaut la peine, car cela facilitera considérablement l'administration des serveurs. Apprendre et utiliser les outils et les démons qui composentsystemd vous aidera à mieux apprécier la puissance, la flexibilité et les capacités qu'il offre, ou du moins vous aidera à faire votre travail avec un minimum de tracas.
Dans ce guide, nous discuterons de la commandesystemctl, qui est l'outil de gestion central pour contrôler le système init. Nous verrons comment gérer les services, vérifier les statuts, modifier les statuts du système et utiliser les fichiers de configuration.
Veuillez noter que bien quesystemd soit devenu le système d’initialisation par défaut pour de nombreuses distributions Linux, il n’est pas implémenté universellement dans toutes les distributions. Au cours de ce didacticiel, si votre terminal génère l'erreurbash: systemctl is not installed, il est probable que votre ordinateur dispose d'un système d'initialisation différent.
La gestion des services
L'objectif fondamental d'un système init est d'initialiser les composants qui doivent être démarrés après le démarrage du noyau Linux (généralement appelés composants «utilisateur»). Le système init est également utilisé pour gérer les services et les démons du serveur à tout moment de l'exécution du système. Dans cet esprit, nous allons commencer par quelques opérations simples de gestion des services.
Danssystemd, la cible de la plupart des actions sont les «unités», qui sont des ressources quesystemd sait gérer. Les unités sont classées selon le type de ressource qu'elles représentent et elles sont définies avec des fichiers appelés fichiers d'unités. Le type de chaque unité peut être déduit du suffixe à la fin du fichier.
Pour les tâches de gestion de service, l'unité cible sera les unités de service, qui ont des fichiers d'unité avec un suffixe de.service. Cependant, pour la plupart des commandes de gestion de service, vous pouvez en fait omettre le suffixe.service, carsystemd est suffisamment intelligent pour savoir que vous souhaitez probablement opérer sur un service lorsque vous utilisez des commandes de gestion de service.
Démarrage et arrêt des services
Pour démarrer un servicesystemd, en exécutant des instructions dans le fichier d’unité du service, utilisez la commandestart. Si vous exécutez en tant qu'utilisateur non root, vous devrez utilisersudo car cela affectera l'état du système d'exploitation:
sudo systemctl start application.serviceComme nous l'avons mentionné ci-dessus,systemd sait rechercher les fichiers*.service pour les commandes de gestion de service, donc la commande pourrait tout aussi facilement être saisie comme ceci:
sudo systemctl start applicationBien que vous puissiez utiliser le format ci-dessus pour l'administration générale, pour plus de clarté, nous utiliserons le suffixe.service pour le reste des commandes afin d'être explicite sur la cible sur laquelle nous opérons.
Pour arrêter un service en cours d'exécution, vous pouvez utiliser la commandestop à la place:
sudo systemctl stop application.serviceRedémarrage et rechargement
Pour redémarrer un service en cours d'exécution, vous pouvez utiliser la commanderestart:
sudo systemctl restart application.serviceSi l'application en question est capable de recharger ses fichiers de configuration (sans redémarrer), vous pouvez émettre la commandereload pour lancer ce processus:
sudo systemctl reload application.serviceSi vous ne savez pas si le service dispose de la fonctionnalité pour recharger sa configuration, vous pouvez émettre la commandereload-or-restart. Cela rechargera la configuration sur place si elle est disponible. Sinon, le service redémarrera afin que la nouvelle configuration soit prise en compte:
sudo systemctl reload-or-restart application.serviceActivation et désactivation des services
Les commandes ci-dessus sont utiles pour démarrer ou arrêter des commandes pendant la session en cours. Pour dire àsystemd de démarrer automatiquement les services au démarrage, vous devez les activer.
Pour démarrer un service au démarrage, utilisez la commandeenable:
sudo systemctl enable application.serviceCela créera un lien symbolique à partir de la copie système du fichier de service (généralement en/lib/systemd/system ou/etc/systemd/system) vers l'emplacement sur le disque oùsystemd recherche les fichiers de démarrage automatique (généralement/etc/systemd/system/some_target.target.wants. Nous verrons quelle est la cible plus tard dans ce guide).
Pour désactiver le service de démarrage automatique, vous pouvez taper:
sudo systemctl disable application.serviceCela 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 devrez exécuter les commandesstart etenable.
Vérification de l'état des services
Pour vérifier l'état d'un service sur votre système, vous pouvez utiliser la commandestatus:
systemctl status application.serviceCela 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 commandeis-active:
systemctl is-active application.serviceCela renverra l'état actuel de l'unité, qui est généralementactive ouinactive. Le code de sortie sera «0» s'il est actif, ce qui simplifiera l'analyse du résultat par programme.
Pour voir si l'unité est activée, vous pouvez utiliser la commandeis-enabled:
systemctl is-enabled application.serviceCela affichera si le service estenabled oudisabled et définira à nouveau le code de sortie sur «0» ou «1» selon la réponse à la question de 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.serviceCela renverraactive s'il fonctionne correctement oufailed si une erreur s'est produite. Si l'unité a été arrêtée intentionnellement, elle peut renvoyerunknown ouinactive. Un état de sortie de «0» indique qu'une défaillance est survenue et un état de sortie de «1» indique tout autre état.
Vue d'ensemble de l'état du système
Jusqu'à présent, les commandes ont été utiles pour gérer des services uniques, mais elles ne sont pas très utiles pour explorer l'état actuel du système. Il existe un certain nombre de commandessystemctl qui fournissent ces informations.
Liste des unités actuelles
Pour voir une liste de toutes les unités actives quesystemd connaît, nous pouvons utiliser la commandelist-units:
systemctl list-unitsCela vous montrera une liste de toutes les unités quesystemd 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
[email protected] loaded active running Getty on tty1
. . .La sortie contient les colonnes suivantes:
-
UNIT: le nom de l'unité
systemd -
LOAD: indique si la configuration de l’unité a été analysée par
systemd. La configuration des unités chargées est conservée en mémoire. -
ACTIVE: un état récapitulatif indiquant si l'unité est active. C'est généralement un moyen assez simple de savoir si l'unité a démarré avec succès ou non.
-
SUB: Il s'agit d'un état de niveau inférieur qui indique des informations plus détaillées sur l'unité. Cela varie souvent selon le type, l'état et la méthode réelle d'exécution de l'unité.
-
DESCRIPTION: Une brève description textuelle de ce que l'unité est / fait.
Puisque la commandelist-units n'affiche que les unités actives par défaut, toutes les entrées ci-dessus afficheront «chargé» dans la colonne CHARGE et «actif» dans la colonne ACTIVE. Cet affichage est en fait le comportement par défaut desystemctl lorsqu'il est appelé sans commandes supplémentaires, donc vous verrez la même chose si vous appelezsystemctl sans arguments:
systemctlNous pouvons dire àsystemctl de sortir des informations différentes en ajoutant des indicateurs supplémentaires. Par exemple, pour voir toutes les unités quesystemd a chargées (ou tenté de charger), qu'elles soient ou non actuellement actives, vous pouvez utiliser l'indicateur--all, comme ceci:
systemctl list-units --allCela affichera toute unité quesystemd a chargée ou a tenté de charger, quel que soit son état actuel sur le système. Certaines unités deviennent inactives après l'exécution et certaines unités quesystemd a tenté de charger n'ont peut-être pas été trouvées sur le disque.
Vous pouvez utiliser d'autres indicateurs pour filtrer ces résultats. Par exemple, nous pouvons utiliser l'indicateur--state= pour indiquer les états LOAD, ACTIVE ou SUB que nous souhaitons voir. Vous devrez conserver l'indicateur--all pour quesystemctl autorise l'affichage des unités non actives:
systemctl list-units --all --state=inactiveUn autre filtre courant est le filtre--type=. Nous pouvons dire àsystemctl d'afficher uniquement les unités du type qui nous intéresse. Par exemple, pour ne voir que les unités de service actives, nous pouvons utiliser:
systemctl list-units --type=serviceListe de tous les fichiers d'unité
La commandelist-units affiche uniquement les unités quesystemd a tenté d'analyser et de charger en mémoire. Puisquesystemd 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 le fichier d'unité disponible deevery dans les cheminssystemd, y compris ceux quesystemd n'a pas tenté de charger, vous pouvez utiliser la commandelist-unit-files à la place:
systemctl list-unit-filesLes unités sont des représentations de ressources quesystemd connaît. Puisquesystemd n'a pas nécessairement lu toutes les définitions d'unité dans 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 «activé», «désactivé», «statique» ou «masqué». Dans ce contexte, statique signifie que le fichier d'unité ne contient pas de section «installer», 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 n'est utilisée que comme dépendance d'une autre unité et ne doit pas être exécutée seule.
Nous allons couvrir ce que “masqué” signifie momentanément.
Gestion des unités
Jusqu'à présent, nous avons travaillé avec des services et affiché des informations sur les fichiers unitaires et unitaires quesystemd connaît. Cependant, nous pouvons trouver des informations plus spécifiques sur les unités en utilisant des commandes supplémentaires.
Affichage d'un fichier d'unité
Pour afficher le fichier d'unité quesystemd a chargé dans son système, vous pouvez utiliser la commandecat (elle a été ajoutée dans la version 209 desystemd). Par exemple, pour voir le fichier d'unité du démon de planification deatd, nous pourrions taper:
systemctl cat atd.service[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.targetLa sortie est le fichier d'unité connu du processussystemd en cours d'exécution. Cela peut être important si vous avez récemment modifié des fichiers unité ou si vous substituez certaines options à un fragment de fichier unité (nous en parlerons plus tard).
Affichage des dépendances
Pour voir l’arborescence des dépendances d’une unité, vous pouvez utiliser la commandelist-dependencies:
systemctl list-dependencies sshd.serviceCeci affichera une hiérarchie mappant les dépendances à traiter pour 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 de manière récursive toutes les dépendances, incluez l'indicateur--all.
Pour afficher les dépendances inversées (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 qui dépendent de l'unité spécifiée commençant avant et après elles, respectivement.
Vérification des propriétés de l'unité
Pour voir les propriétés de bas niveau d'une unité, vous pouvez utiliser la commandeshow. Cela affichera une liste de propriétés définies pour l'unité spécifiée en utilisant un formatkey=value:
systemctl show sshd.serviceId=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 de l'unitésshd.service, vous pouvez taper:
systemctl show sshd.service -p ConflictsConflicts=shutdown.targetUnités de masquage et de démasquage
Nous avons vu dans la section gestion des services comment arrêter ou désactiver un service, maissystemd a également la possibilité de marquer une unité commecompletely non démarrable, automatiquement ou manuellement, en la liant à/dev/null . Cela s'appelle le masquage de l'unité, et est possible avec la commandemask:
sudo systemctl mask nginx.serviceCela empêchera le service Nginx d'être démarré, automatiquement ou manuellement, tant qu'il est masqué.
Si vous cochez leslist-unit-files, 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.serviceFailed to start nginx.service: Unit nginx.service is masked.Pour démasquer une unité et la rendre à nouveau disponible, utilisez simplement la commandeunmask:
sudo systemctl unmask nginx.serviceCela ramènera l'unité à son état précédent, lui permettant d'être démarré ou activé.
Modification des fichiers d'unité
Bien que le format spécifique des fichiers d'unité n'entre pas dans le cadre de ce didacticiel,systemctl fournit des mécanismes intégrés pour éditer et modifier les fichiers d'unité si vous devez effectuer des ajustements. Cette fonctionnalité a été ajoutée dans la version 218 desystemd.
La commandeedit, par défaut, ouvrira un extrait de fichier d'unité pour l'unité en question:
sudo systemctl edit nginx.serviceCe sera un fichier vierge pouvant être utilisé pour remplacer ou ajouter des directives à la définition de l'unité. Un répertoire sera créé dans le répertoire/etc/systemd/system qui contient le nom de l'unité avec.d ajouté. Par exemple, pour lesnginx.service, un répertoire appelénginx.service.d sera créé.
Dans ce répertoire, un extrait de code sera créé appeléoverride.conf. Lorsque l'unité est chargée,systemd fusionnera, en mémoire, l'extrait de remplacement avec le fichier d'unité complet. Les directives de l’extrait de code auront la priorité sur celles trouvées dans le fichier d’unités original.
Si vous souhaitez éditer le fichier d'unité complet au lieu de créer un extrait de code, vous pouvez passer l'indicateur--full:
sudo systemctl edit --full nginx.serviceCeci chargera le fichier d'unité actuel dans l'éditeur, où il pourra être modifié. À la fermeture de l’éditeur, le fichier modifié sera écrit dans/etc/systemd/system, qui prévaudra sur la définition de l’unité du système (généralement trouvée quelque part dans/lib/systemd/system).
Pour supprimer les ajouts que vous avez faits, 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.dPour supprimer un fichier unité complètement modifié, nous tapons:
sudo rm /etc/systemd/system/nginx.serviceAprès avoir supprimé le fichier ou le répertoire, vous devez recharger le processussystemd afin qu'il ne tente plus de référencer ces fichiers et revienne à l'utilisation des copies système. Vous pouvez le faire en tapant:
sudo systemctl daemon-reloadRéglage de l'état du système (niveau d'exécution) avec des cibles
Les cibles sont des fichiers d'unité spéciaux décrivant un état du système ou un point de synchronisation. Comme les autres unités, les fichiers qui définissent les cibles peuvent être identifiés par leur suffixe, qui dans ce cas est.target. Les cibles ne font pas beaucoup elles-mêmes, mais sont utilisées pour regrouper d'autres unités.
Ceci peut être utilisé pour amener le système dans certains états, un peu comme les autres systèmes init utilisent des niveaux d'exécution. Ils servent de référence lorsque certaines fonctions sont disponibles, ce qui vous permet de spécifier l'état souhaité au lieu des unités individuelles nécessaires pour produire cet état.
Par exemple, il y a unswap.target qui est utilisé pour indiquer que le swap est prêt à être utilisé. Les unités qui font partie de ce processus peuvent se synchroniser avec cette cible en indiquant dans leur configuration qu'elles sontWantedBy= ouRequiredBy= lesswap.target. Les unités qui nécessitent la disponibilité du swap peuvent spécifier cette condition à l'aide des spécificationsWants=,Requires= etAfter= pour indiquer la nature de leur relation.
Obtenir et définir la cible par défaut
Le processussystemd 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-defaultmulti-user.targetSi vous souhaitez définir une cible par défaut différente, vous pouvez utiliser lesset-default. Par exemple, si vous avez un bureau graphique installé et que vous souhaitez que le système démarre par défaut, vous pouvez modifier votre cible par défaut en conséquence:
sudo systemctl set-default graphical.targetListe des cibles disponibles
Vous pouvez obtenir une liste des cibles disponibles sur votre système en tapant:
systemctl list-unit-files --type=targetContrairement aux niveaux d'exécution, plusieurs cibles peuvent être actives en même temps. Une cible active indique quesystemd a tenté de démarrer toutes les unités liées à la cible et n'a pas essayé de les détruire à nouveau. Pour voir toutes les cibles actives, tapez:
systemctl list-units --type=targetIsoler les cibles
Il est possible de démarrer toutes les unités associées à une cible et d’arrêter toutes les unités qui ne font pas partie de l’arbre de dépendance. La commande dont nous avons besoin pour ce faire est appelée, de manière appropriée,isolate. Ceci est similaire à la modification du niveau d'exécution dans d'autres systèmes init.
Par exemple, si vous travaillez dans un environnement graphique avecgraphical.target actif, vous pouvez arrêter le système graphique et mettre le système dans un état de ligne de commande multi-utilisateur en isolant lesmulti-user.target. Puisquegraphical.target dépend demulti-user.target mais pas l'inverse, toutes les unités graphiques seront arrêtées.
Vous voudrez peut-être examiner les dépendances de la cible que vous isolez avant d'effectuer cette procédure pour vous assurer que vous n'interrompez pas les services essentiels:
systemctl list-dependencies multi-user.targetLorsque vous êtes satisfait des unités qui seront maintenues en vie, vous pouvez isoler la cible en tapant:
sudo systemctl isolate multi-user.targetUtilisation de raccourcis pour des événements importants
Des cibles sont définies pour des événements importants tels que la mise hors tension ou le redémarrage. Cependant,systemctl a également des raccourcis qui ajoutent un peu de fonctionnalités supplémentaires.
Par exemple, pour mettre le système en mode de secours (mono-utilisateur), vous pouvez simplement utiliser la commanderescue au lieu deisolate rescue.target:
sudo systemctl rescueCela 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 commandehalt:
sudo systemctl haltPour lancer un arrêt complet, vous pouvez utiliser la commandepoweroff:
sudo systemctl poweroffUn redémarrage peut être lancé avec la commandereboot:
sudo systemctl rebootTous ces messages alertent les utilisateurs connectés que l'événement se produit, ce qui ne fera pas qu'exécuter ou isoler la cible. Notez que la plupart des machines lieront les commandes plus courtes et plus conventionnelles pour ces opérations afin qu'elles fonctionnent correctement avecsystemd.
Par exemple, pour redémarrer le système, vous pouvez généralement taper:
sudo rebootConclusion
À présent, vous devriez être familiarisé avec certaines des fonctionnalités de base de la commandesystemctl qui vous permettent d'interagir avec et de contrôler votre instancesystemd. L'utilitairesystemctl sera votre principal point d'interaction pour la gestion des services et de l'état du système.
Alors quesystemctl fonctionne principalement avec le processus de basesystemd, il existe d'autres composants de l'écosystèmesystemd qui sont contrôlés par d'autres services publics. D'autres fonctionnalités, telles que la gestion des journaux et les sessions utilisateur, sont gérées par des démons et des utilitaires de gestion distincts (journald /journalctl etlogind /loginctl respectivement). Prendre le temps de se familiariser avec ces autres outils et démons facilitera la gestion.