One place for hosting & domains

      systemd

      What is systemd?


      Many Linux distributions use systemd to manage system settings and services.
      systemd organizes tasks into components called units, and groups of units into targets, that can be used to create dependencies on other system services and resources.

      systemd can start units and targets automatically at boot time, or when requested by a user or another systemd target when a server is already running.

      The systemctl command is used to interact with processes that are controlled by systemd. It can examine the status of units and targets, as well as start, stop, and reconfigure them.

      To learn more about managing services with systemd and defining and using systemd unit files, visit:

      Finally, to learn how to interact with systemd logs using the journalctl command, visit this tutorial, How To Use Journalctl to View and Manipulate Systemd Logs, which explains how systemd collects logs from units and displays them in a centralized location and unified format.



      Source link

      Comment utiliser Systemctl pour gérer les services et les unités de Systemd


      Introduction

      systemd est un gestionnaire de systèmes d’initialisation et de systèmes qui est devenu la nouvelle norme pour les distributions de Linux. Étant largement adopté, cela vaut la peine de se familiariser avec systemd car l’administration de serveurs vous sera considérablement plus facile. En apprendre davantage sur les outils et les démons qui composent systemd vous permettra de mieux apprécier la puissance, la flexibilité et les capacités qu’il vous offre ou, tout du moins, de travailler avec un minimum de tracas.

      Au cours de ce guide, nous allons discuter de la commande systemctl, qui est l’outil de gestion essentiel pour contrôler le système d’initialisation. Nous allons voir de quelle la manière vous pouvez gérer les services, vérifier les états, modifier les états du système et travailler avec les fichiers de configuration.

      Notez que, bien que systemd soit devenu le système d’initialisation par défaut de nombreuses distributions Linux, il n’est pas universellement implémenté sur toutes les distributions. Si au cours de ce tutoriel votre terminal déclenche l’erreur bash: systemctl is not installed, il est alors probable que votre machine ait installé un système d’initialisation.

      Gestion de service

      L’objectif fondamental d’un système d’initialisation est d’initialiser les composants qui doivent être démarrés une fois que le noyau Linux est lancé (traditionnellement connus sous le nom de composants « userland »). De plus, le système d’initialisation vous permet de gérer à tout moment les services et les démons du serveur alors que le système est en marche. Dans cette optique, nous allons commencer par certaines des opérations de base de gestion de service.

      Dans systemd, la cible de la plupart des actions sont des « unités », c’est-à-dire des ressources que systemd sait gérer. Les unités sont classées par le type de ressources qu’elles représentent. Leur configuration se fait avec des fichiers que l’on appelle des « fichiers de l’unité ». Vous pouvez déduire le type de chaque unité à l’aide du suffixe qui se trouve à la fin du fichier.

      Pour les tâches de gestion de service, l’unité cible correspondra aux unités de service pour lesquelles les fichiers de l’unité se terminent par le suffixe .service. Cependant, en réalité, pour la plupart des commandes de gestion de service, vous n’avez pas nécessairement besoin du suffixe .service. En effet, systemd est assez intelligent pour savoir que, lorsque vous utilisez les commandes de gestion de service, vous souhaitez probablement travailler sur un service.

      Démarrage et arrêt des services

      Si vous souhaitez démarrer un service systemd en exécutant les instructions qui se trouvent dans le fichier de l’unité du service, utilisez la commande start. Si vous opérez comme un non-root user, vous devrez utiliser sudo car cela affectera l’état du système d’exploitation :

      • sudo systemctl start application.service

      Comme nous l’avons précédemment mentionné, étant donné que systemd sait qu’il doit rechercher les fichiers *.service pour les commandes de gestion de service, il vous suffirait de saisir la commande de la manière suivante :

      • sudo systemctl start application

      Même si, à des fins d’administration générale, vous pouvez utiliser le format ci-dessus, nous allons utiliser le suffixe .service pour le reste des commandes par soucis de clarté afin de définir clairement la cible sur laquelle nous travaillons.

      Pour arrêter un service en cours d’exécution, vous pouvez plutôt utiliser la commande stop :

      • sudo systemctl stop application.service

      Redémarrage et rechargement

      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 en capacité de recharger ses fichiers de configuration (sans redémarrage), vous pouvez lancer la commande reload pour initier ce processus :

      • sudo systemctl reload application.service

      Si vous ne savez pas si le service intègre la fonctionnalité qui lui permet de recharger sa configuration, vous pouvez lancer la commande reload-or-restart Si disponible, vous rechargerez la configuration en place. Sinon, le service redémarrera pour récupérer la nouvelle configuration :

      • sudo systemctl reload-or-restart application.service

      Activation et désactivation des services

      Les commandes ci-dessus vous seront utiles pour démarrer ou arrêter des services pendant la session en cours. Vous devez les activer pour demander à systemd de lancer automatiquement les services au démarrage.

      Pour lancer un service au démarrage, utilisez la commande enable :

      • sudo systemctl enable application.service

      Cela créera un lien symbolique à partir de la copie du fichier de service du système (généralement dans /lib/systemd/system ou /etc/systemd/system) à l’emplacement du disque où systemd cherche les fichiers de démarrage automatique (généralement /etc/systemd/system/some_target.target.wants. Nous verrons ce qu’est une cible plus tard dans ce guide).

      Pour désactiver le démarrage automatique d’un service, vous pouvez saisir :

      • 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 du service ne le déclenche pas pendant la session en cours. Si vous souhaitez démarrer le service et, dans le même temps, l’activer au démarrage, vous devez lancer à la fois la commande start et la commande enable.

      Vérification de l’état des services

      Pour vérifier l’état d’un service sur votre système, vous pouvez utiliser la commande status :

      • systemctl status application.service

      Vous pourrez ainsi consulter l’état des services, la hiérarchie des groupes et les premières lignes du journal.

      Par exemple, lorsque vous souhaitez vérifier l’état d’un serveur Nginx, le résultat peut s’afficher comme suit :

      Output

      ● 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 de l’état actuel de l’application, vous signalant tout problème et toute action à mettre en œuvre.

      Certaines méthodes vous permettent également de contrôler des états spécifiques. Par exemple, si vous souhaitez 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 renverra l’état actuel de l’unité, qui est généralement active ou inactive. Si elle est active, le code de sortie affichera « 0 », ce qui simplifie l’analyse dans les scripts shell.

      Pour voir si l’unité est activée, vous pouvez utiliser la commande is-enabled :

      • systemctl is-enabled application.service

      Vous pourrez ainsi voir si le service est enabled ou disabled et le code de sortie sera à nouveau configuré sur « 0 » ou « 1 » en fonction de la réponse à la question de la commande.

      Une troisième vérification consiste à voir si l’état de l’unité indique un échec. Cela indique qu’un problème est survenu au démarrage de l’unité en question :

      • systemctl is-failed application.service

      Cela reverra active si l’exécution se fait correctement ou failed si une erreur survient. Si l’unité est intentionnellement arrêtée, elle peut renvoyer unknown ou inactive. Le statut de sortie « 0 » indique qu’une défaillance est survenue. Le statut de sortie « 1 » indique tout autre statut.

      Présentation générale des états du système

      Jusqu’à présent, les commandes nous ont permis de gérer des services uniques, mais pas vraiment de consulter l’état actuel du système. Il existe un certain nombre de commandes systemctl qui vous donnent ces informations.

      Liste des unités en cours d’utilisation

      Pour avoir une liste de toutes les unités actives que systemd reconnaît, nous pouvons utiliser la commande list-units :

      Cela affichera une liste de toutes les unités considérées comme actives par systemd sur le système. La sortie finale ressemblera à peu près à ceci :

      Output

      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 affiche les colonnes suivantes :

      • UNIT : le nom de l'unité systemd
      • LOAD : si la configuration de l'unité a été analysée par systemd. La configuration des unités chargées est gardée en mémoire.
      • ACTIVE : un état résumé indiquant si l'unité est active. Il s'agit généralement d'une méthode assez simple d'établir si l'unité a bien démarré ou pas.
      • SUB : il s'agit d'un état de niveau inférieur qui donne des informations plus détaillées sur l'unité. Il varie souvent en fonction du type, de l'état et du mode de fonctionnement réel de l'unité.
      • DESCRIPTION : une courte description textuelle de ce que l'unité est/fait.

      Étant donné que la commande list-units affiche uniquement les unités actives par défaut, toutes les entrées ci-dessus afficheront loaded dans la colonne LOAD et active dans la colonne ACTIVE. Cet affichage correspond en réalité au comportement par défaut de systemctl lorsque vous l'appelez sans commandes supplémentaires. Vous verrez donc la même chose se produire si vous appelez systemctl sans arguments :

      Nous pouvons instruire systemctl de générer des informations différentes en ajoutant des balises supplémentaires. Par exemple, pour consulter toutes les unités que systemd a chargées (ou tente de charger), qu'elles soient actuellement actives ou pas, vous pouvez utiliser la balise --all comme suit :

      • systemctl list-units --all

      Cela affichera toute unité que systemd a chargée ou tenté de charger, quel que soit l'état actuel du système. Certaines unités deviennent inactives après leur exécution et il se peut que certaines autres, celles que systemd a tenté de charger, restent introuvables sur le disque.

      Vous pouvez filtrer ces résultats en utilisant d'autres balises. Par exemple, nous pouvons utiliser la balise --state= pour indiquer les états LOAD, ACTIVE ou SUB que nous souhaitons consulter. Nous allons devoir garder la balise --all pour que systemctl permette l'affichage des unités inactives :

      • systemctl list-units --all --state=inactive

      Un autre filtre est couramment utilisé, le filtre --type=. Nous pouvons indiquer à systemctl d'afficher uniquement le type d'unités qui nous intéresse. Par exemple, pour consulter uniquement les unités de service actives, nous pouvons utiliser :

      • systemctl list-units --type=service

      Liste de tous les fichiers de l'unité

      La commande list-units affiche uniquement les unités que systemd a tentées d'analyser et de charger en mémoire. Étant donné que systemd lira uniquement les unités dont il pense avoir besoin, les unités disponibles sur le système ne seront pas nécessairement toutes répertoriées. Pour voir tous les fichiers de l'unité disponibles au sein des chemins de systemd, notamment ceux que systemd n'a pas tenté de charger, vous pouvez utiliser la commande list-unit-files à la place :

      • systemctl list-unit-files

      Les unités sont des représentations des ressources dont systemd a connaissance. Étant donné que systemd n'a pas nécessairement lu toutes les définitions de l'unité dans cet écran, seules les informations concernant les fichiers en eux-mêmes sont présentées. La sortie a deux colonnes : le fichier de l'unité et l'état.

      Output

      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 indiquera généralement enabled, disabled, static ou masked. Dans ce contexte, static signifie que le fichier de l'unité ne contient pas de section install, qui sert à activer une unité. De ce fait, ces unités ne peuvent pas être activées. Habituellement, cela signifie que soit l'unité effectue une action unique, soit elle est uniquement utilisée qu'en tant que dépendance d'une autre unité et ne doit pas être exécutée seule.

      Nous allons voir dans un moment ce que masked signifie.

      Gestion de l'unité

      Jusque-là, nous avons travaillé avec les services et affiché des informations sur l'unité et sur les fichiers de l'unité dont systemd a connaissance. Cependant, en utilisant d'autres commandes, nous pouvons trouver des informations plus spécifiques sur les unités.

      Affichage du fichier de l'unité

      Pour afficher le fichier de l'unité que systemd a chargé sur son système, vous pouvez utiliser la commande cat qui a été ajoutée dans la version 209 de systemd). Par exemple, pour voir le fichier de l'unité de démon de planification atd, nous pourrions saisir :

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      On obtient ainsi le fichier de l'unité tel que reconnu par le processus systemd en cours d'exécution. Cela peut s'avérer important si vous avez récemment modifié des fichiers de l'unité ou si vous écrasez certaines options dans un fragment du fichier de l'unité (nous allons couvrir cela plus tard).

      Affichage des dépendances

      Pour voir une arborescence des dépendances de l'unité, vous pouvez utiliser la commande list-dependencies :

      • systemctl list-dependencies sshd.service

      Cela affichera une cartographie hiérarchisée des dépendances qui doivent être traitées afin de démarrer l'unité concernée. Dans ce contexte, les dépendances incluent les unités qui sont soit requises ou souhaitées par les unités au-dessus.

      Output

      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 s'affichent uniquement pour .target, qui indique les états du système. Pour lister de manière récursive toutes les dépendances, ajoutez la balise --all.

      Pour afficher les dépendances inverses (les unités qui dépendent de l'unité spécifiée), vous pouvez ajouter la balise --reverse à la commande. D'autres balises vous seront utiles : --before et --after. Vous pouvez les utiliser pour afficher les unités qui dépendent de l'unité spécifiée qui a démarré avant et après elles, respectivement.

      Vérification des propriétés de l'unité

      Pour consulter les propriétés de niveau inférieur d'une unité, vous pouvez utiliser la commande show. Elle affichera une liste de propriétés configurées pour l'unité spécifiée en utilisant un format key=value :

      • systemctl show sshd.service

      Output

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

      Pour afficher une seule propriété, vous pouvez faire utiliser la balise -p accompagnée du nom de la propriété. Par exemple, pour voir les conflits que l'unité sshd.service a, vous pouvez saisir :

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Masquage et affichage des unités

      Dans la section Gestion de service, nous avons vu de quelle manière arrêter ou désactiver un service, mais systemd a également la possibilité de marquer une unité comme étant totalement impossible à démarrer, automatiquement ou manuellement, en la reliant à /dev/null. On dit alors que l'on « masque » l'unité, et il est possible de le faire avec la commande mask :

      • sudo systemctl mask nginx.service

      Tant qu'elle est masquée, tout démarrage automatique ou manuel du service Nginx est impossible.

      Si vous vérifiez la list-unit-files, vous verrez que le service est maintenant répertorié comme étant masqué :

      • systemctl list-unit-files

      Output

      . . . 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 tentez de lancer le service, vous verrez s'afficher le message suivant :

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Pour afficher une unité et rendre son utilisation à nouveau possible, utilisez la commande unmask :

      • sudo systemctl unmask nginx.service

      Cela renverra l'unité à l'état précédent, ce qui lui permettra son démarrage ou son activation.

      Modification des fichiers de l'unité

      Bien que ce tutoriel ne traite pas du format spécifique des fichiers de l'unité, systemctl met à votre disposition des mécanismes intégrés d'édition et de modification des fichiers de l'unité pour vous permettre de faire des réglages. Cette fonctionnalité a été ajoutée dans la version 218 de systemd.

      Par défaut, la commande edit ouvrira le fragment de code du fichier de l'unité concerné :

      • sudo systemctl edit nginx.service

      Il s'agira d'un fichier vierge qui pourra ê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/systemd qui contient le nom de l'unité avec un .d annexé. Par exemple, pour le nginx.service, un répertoire appelé nginx.service.d sera créé.

      Au sein de ce répertoire, un fragment de code appelé override.conf sera créé. Une fois l'unité chargée, systemd fusionnera, en mémoire, le fragment de code de remplacement avec le fichier de l'unité dans son intégralité. Les directives du fragment de code auront la priorité sur celles qui se trouvent dans le fichier de l'unité d'origine.

      Si vous souhaitez modifier l'intégralité du fichier de l'unité au lieu de créer un fragment de code, vous pouvez passer la balise --full.

      • sudo systemctl edit --full nginx.service

      Cela chargera le fichier de l'unité actuelle dans l'éditeur dans lequel vous pouvez le modifier. Lorsque l'éditeur se ferme, le fichier modifié sera écrit dans /etc/systemd/system, ce qui aura la priorité sur la définition de l'unité du système (qui se trouve généralement dans /lib/systemd/system).

      Pour supprimer tous les ajouts que vous avez effectués, vous pouvez supprimer soit le répertoire de configuration de l'unité .d ou le fichier de service modifié de /etc/systemd/system. Par exemple, pour supprimer un fragment de code, nous pourrions saisir :

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Pour supprimer un fichier complet de l'unité modifié, il faudrait entrer :

      • sudo rm /etc/systemd/system/nginx.service

      Après avoir supprimé le fichier ou le répertoire, vous devez recharger le processus systemd pour qu'il ne tente plus de référencer ces fichiers et réutilise les copies du système. Vous pouvez le faire en tapant :

      • sudo systemctl daemon-reload

      Réglage de l'état du système (niveau d'exécution) avec des cibles

      Les cibles sont des fichiers spéciaux de l'unité qui décrivent un état ou un point de synchronisation du système. Comme avec les autres unités, les fichiers qui définissent des cibles peuvent être identifiés par leur suffixe, dans ce cas .target. Seules, les cibles ne font pas grand-chose, mais elles permettent de regrouper d'autres unités ensemble.

      Vous pouvez les utiliser pour mettre le système dans certains états, tout comme les autres systèmes d'initialisation utilisent les niveaux d'exécution. Elles servent de référence lorsque certaines fonctions sont disponibles. Elles vous permettent ainsi de spécifier l'état souhaité au lieu d'avoir à spécifier les unités individuellement pour produire cet état.

      Par exemple, il existe un swap.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 sont WantedBy= ou RequiredBy= le swap.target. Les unités qui nécessitent la disponibilité d'un swap peuvent spécifier cette condition en utilisant les spécifications Wants=, Requires=, et After= pour indiquer la nature de leur relation.

      Obtention et configuration de la cible par défaut

      Le processus systemd a une cible par défaut qu'il utilise au lancement du système. En satisfaisant la cascade des dépendances de cette cible unique, le système est amené à l'état souhaité. Pour trouver la cible par défaut de votre système, saisissez :

      Output

      multi-user.target

      Au besoin, pour configurer une autre cible par défaut, vous pouvez utiliser le set-default. Par exemple, si vous avez installé un bureau graphique et que vous souhaitez que le système s'y lance par défaut, vous pouvez modifier votre cible par défaut en conséquence :

      • sudo systemctl set-default graphical.target

      Liste des cibles disponibles

      Vous pouvez obtenir une liste des cibles disponibles sur votre système en saisissant :

      • systemctl list-unit-files --type=target

      Contrairement aux niveaux d'exécution, plusieurs cibles peuvent être actives à la fois. Une cible active indique que systemd a tenté de lancer toutes les unités liées à la cible et n'a pas encore réessayé de les détruire. Pour voir toutes les cibles actives, entrez :

      • systemctl list-units --type=target

      Isolation des cibles

      Il est possible de lancer toutes les unités associées à une cible et d'arrêter toutes celles qui ne font pas partie de l'arborescence de dépendance. La commande dont nous avons besoin pour cela s'appelle, comme il se doit, isolate. Le processus est similaire à celui qui permet de changer le niveau d'exécution sur les autres systèmes d'initialisation.

      Par exemple, si vous opérez dans un environnement graphique dans lequel graphical.target est active, vous pouvez arrêter le système graphique et mettre le système dans un état de ligne de commande multi-utilisateur en isolant le multi-user.target. Étant donné que graphical.target dépend de multi-user.target, mais pas l'inverse, toutes les unités graphiques seront arrêtées.

      Il est conseillé de consulter les dépendances de la cible que vous isolez avant d'effectuer cette procédure afin de s'assurer de ne pas arrêter les services essentiels :

      • systemctl list-dependencies multi-user.target

      Une fois satisfait des unités qui seront restées actives, vous pouvez isoler la cible en saisissant le texte suivant :

      • sudo systemctl isolate multi-user.target

      Utilisation de raccourcis pour les événements importants

      Il existe des cibles définies pour les événements importants comme la mise à l'arrêt ou le redémarrage. Cependant, systemctl intègre également quelques raccourcis qui ajoutent quelques fonctionnalités supplémentaires.

      Par exemple, pour mettre le système en mode sauvetage (utilisateur unique), vous pouvez utiliser la commande rescue au lieu de isolate rescue.target :

      Cela permettra d'avoir une fonctionnalité supplémentaire qui avertira tous les utilisateurs connectés de l'événement.

      Pour arrêter le système, vous pouvez utiliser la commande halt :

      Pour lancer un arrêt complet, vous pouvez utiliser la commande poweroff :

      Vous pouvez déclencher un redémarrage avec la commande reboot :

      Ces fonctionnalités avertiront les utilisateurs que l'événement est en cours, ce qui ne se fera pas en exécutant ou isolant uniquement la cible. Notez que la plupart des machines relieront les commandes les plus courtes et les plus classiques de ces opérations afin qu'elles fonctionnent correctement avec systemd.

      Par exemple, pour redémarrer le système, vous pouvez généralement taper :

      Conclusion

      Maintenant, vous devriez vous être familiarisé avec certaines des capacités de base de la commande systemctl qui vous permettent d'interagir avec votre instance systemd et de la contrôler. L'utilitaire systemctl sera votre principal point d'interaction pour gérer l'état des services et l'état du système.

      Bien que systemctl fonctionne principalement avec le processus de base systemd, il existe d'autres composants de l'écosystème systemd qui sont contrôlés par d'autres utilitaires . D'autres capacités, comme la gestion des journaux et les sessions utilisateur, sont traitées par des démons et des utilitaires de gestion distincts (journald/journalctl et (logind/loginctl respectivement). Prenez le temps de vous familiariser avec les autres outils et démons pour que la gestion soit plus facile.



      Source link

      Cómo usar Systemctl para gestionar servicios y unidades de Systemd


      Introducción

      systemd es un sistema init y un administrador del sistema que se ha convertido en el nuevo estándar para las distribuciones Linux. Debido a su gran adopción, merece la pena familiarizarse con systemd, ya que hará que administrar servidores sea mucho más fácil. Conocer y utilizar las herramientas y daemons que componen systemd le ayudará a apreciar mejor la potencia, la flexibilidad y las capacidades que proporciona, o al menos a simplificar su trabajo.

      En esta guía, hablaremos del comando systemctl, que es la herramienta de administración central para controlar el sistema init. Explicaremos cómo administrar servicios, comprobar estados, cambiar estados del sistema y trabajar con los archivos de configuración.

      Tenga en cuenta que aunque systemd es el sistema init predeterminado para muchas distribuciones Linux, no se implementa universalmente en todas las distribuciones. A medida que avanza en este tutorial, si su terminal arroja el error bash: systemctl is not installed, es probable que su equipo tenga un sistema init diferente instalado.

      Administración de servicios

      La finalidad principal de un sistema init es inicializar los componentes que deben iniciarse tras arrancar el kernel Linux (tradicionalmente conocidos como componentes “userland”). El sistema init también se utiliza para administrar servicios y daemons para el servidor en cualquier momento mientras se ejecuta el sistema. Teniendo eso en cuenta, comenzaremos con algunas operaciones básicas de administración de servicio.

      En systemd, el destino de la mayoría de las acciones son “unidades”, que son recursos que systemd sabe cómo administrar. Las unidades se categorizan por el tipo de recurso al que representan y se definen con archivos conocidos como archivos de unidad. El tipo de cada unidad puede deducirse del sufijo al final del archivo.

      Para las tareas de administración de servicio, la unidad de destino será unidades de servicio, que tienen archivos de unidad con un sufijo .service. Sin embargo, para la mayoría de los comandos de administración de servicio, puede dejar fuera el sufijo .service, ya que systemd es lo suficientemente inteligente para saber que probablemente quiere operar sobre un servicio cuando utiliza comandos de administración de servicio.

      Iniciar y detener servicios

      Para iniciar un servicio systemd, ejecutar instrucciones en el archivo de la unidad del servicio, utilice el comando start. Si está ejecutando como usuario non-root, tendrá que usar sudo, ya que esto afectará al estado del sistema operativo.

      • sudo systemctl start application.service

      Como hemos mencionado antes, systemd sabe buscar los archivos *.service para los comandos de administración de servicio, de forma que el comando podría escribirse fácilmente así:

      • sudo systemctl start application

      Aunque puede usar el formato anterior para la administración general, para mayor claridad, usaremos el sufijo .service para el resto de los comandos, con el objetivo de ser explícitos sobre el destino en el que estamos operando.

      Para detener un servicio que se esté ejecutando actualmente, puede usar el comando stop:

      • sudo systemctl stop application.service

      Reiniciar y volver a cargar

      Para reiniciar un servicio en ejecución, puede usar el comando restart:

      • sudo systemctl restart application.service

      Si la aplicación en cuestión puede volver a cargar sus archivos de configuración (sin reiniciar), puede emitir el comando reload para iniciar ese proceso:

      • sudo systemctl reload application.service

      Si no está seguro de si el servicio tiene la funcionalidad de volver a cargar su configuración, puede emitir el comando reload-or-restart. Esto volverá a cargar la configuración en vigor, si está disponible. De lo contrario, reiniciará el servicio de forma que se recoja la nueva configuración:

      • sudo systemctl reload-or-restart application.service

      Cómo habilitar y deshabilitar servicios

      Los comandos anteriores son útiles para iniciar o detener servicios durante la sesión actual. Para indicar a systemd que inicie servicios automáticamente en el arranque, debe habilitarlos.

      Para iniciar un servicio en el arranque, utilice el comando enable:

      • sudo systemctl enable application.service

      Esto creará un enlace simbólico desde la copia del sistema del archivo de servicio (normalmente en /lib/systemd/system o /etc/systemd/system) en la ubicación del disco donde systemd busca los archivos de inicio automático (normalmente /etc/systemd/system/some_target.target.wants. Repasaremos qué es un destino más adelante en esta guía).

      Para impedir que el servicio se inicie automáticamente, puede escribir:

      • sudo systemctl disable application.service

      Esto eliminará el enlace simbólico que indicaba que el servicio debía iniciarse automáticamente.

      Tenga en cuenta que habilitar el servicio no lo inicia en la sesión actual. Si desea iniciar el servicio y habilitarlo en el arranque, tendrá que emitir los comandos start y enable.

      Cómo comprobar el estado de los servicios

      Para comprobar el estado de un servicio en su sistema, puede usar el comando status:

      • systemctl status application.service

      Esto le proporcionará el estado del servicio, la jerarquía de cgroup y las primeras líneas de registro.

      Por ejemplo, cuando se comprueba el estado de un servidor Nginx, puede ver un resultado como este:

      Output

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

      Esto le proporciona una buena visión general del estado actual de la aplicación, y le notifica de cualquier problema y cualquier acción que pueda ser necesaria.

      También hay métodos para comprobar los estados específicos. Por ejemplo, para comprobar si una unidad está activa actualmente (ejecutándose) puede usar el comando is-active:

      • systemctl is-active application.service

      Esto devolverá el estado actual de la unidad, que es normalmente activo o inactivo. El código de salida será “0” si está activo, lo que hace que el resultado sea más sencillo de analizar en las secuencias de comando shell.

      Para ver si la unidad está habilitada, puede usar el comando is-enabled:

      • systemctl is-enabled application.service

      Esto indicará si el servicio está habilitado o deshabilitado y establecerá el código de salida a “0” o “1”, dependiendo de la respuesta a la pregunta del comando.

      Una tercera comprobación es si la unidad está en estado fallido. Esto indica que hubo un problema al iniciar la unidad en cuestión:

      • systemctl is-failed application.service

      Esto devolverá active si se está ejecutando adecuadamente o failed si se ha producido un error. Si la unidad se detuvo intencionadamente, puede devolver unknown o inactive. Un estado de salida de “0” indica que se produjo un error y un estado de salida de “1” indica cualquier otro estado.

      Descripción general del estado del sistema

      Los comandos hasta ahora han sido útiles para administrar servicios individuales, pero no son muy útiles para explorar el estado actual del sistema. Hay varios comandos systemctl que proporcionan esta información.

      Cómo enumerar las unidades actuales

      Para ver una lista de todas las unidades activas que systemd conoce, podemos usar el comando list-units:

      Esto le mostrará una lista de todas las unidades que systemd tiene activas actualmente en el sistema. El resultado tendrá un aspecto similar a este:

      Output

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

      El resultado tiene las siguientes columnas:

      • UNIT: El nombre de la unidad de systemd
      • LOAD: Si la configuración de la unidad ha sido analizada por systemd. La configuración de las unidades cargadas se mantiene en la memoria.
      • ACTIVE: Un estado resumido que indica si la unidad está activa. Esta es normalmente una forma bastante básica de saber si la unidad se ha iniciado correctamente o no.
      • SUB: Este es un estado de nivel inferior que indica información más detallada sobre la unidad. Esto a menudo varía por tipo de unidad, estado y el método real en el que se ejecuta la unidad.
      • DESCRIPTION: Una descripción textual breve de qué es y hace la unidad.

      Ya que el comando list-units muestra solo las unidades activas por defecto, todas las entradas por encima se mostrarán loaded en la columna LOAD y active en la columna ACTIVE. Esta pantalla es, en realidad, el comportamiento predeterminado de systemctl cuando se invoca sin comandos adicionales, de modo que verá lo mismo si invoca systemctl sin argumentos:

      Podemos indicar a systemctl que produzca información diferente añadiendo marcadores adicionales. Por ejemplo, para ver todas las unidades que systemd ha cargado (o intentado cargar), independientemente de si están activas actualmente, puede usar el marcador --all, de esta forma:

      • systemctl list-units --all

      Esto mostrará cualquier unidad que systemd haya cargado o intentado cargar, independientemente de su estado actual en el sistema. Ciertas unidades se vuelven inactivas tras ejecutarse, y algunas de las unidades que systemd intentó cargar pueden no haberse encontrado en el disco.

      Puede usar otros marcadores para filtrar estos resultados. Por ejemplo, puede usar el indicador --state= para indicar los estados LOAD, ACTIVE o SUB que deseamos ver. Tendremos que mantener el marcador --all para que systemctl permita que se muestren las unidades no activas:

      • systemctl list-units --all --state=inactive

      Otro filtro común es el filtro --type=. Podemos indicar a systemctl que solo muestre unidades del tipo en el que estemos interesados. Por ejemplo, para ver únicamente las unidades de servicio activas, podemos usar:

      • systemctl list-units --type=service

      Listar todos los archivos de la unidad

      El comando list-units solo muestra las unidades que systemd ha intentado analizar y cargar en la memoria. Ya que systemd solo leerá unidades que cree que necesita, esto no incluirá necesariamente todas las unidades disponibles en el sistema. Para ver todos los archivos de unidad disponibles en las rutas systemd, incluidos aquellos que systemd no haya intentado cargar, puede usar el comando list-unit-files:

      • systemctl list-unit-files

      Las unidades son representaciones de los recursos que systemd conoce. Ya que systemd no ha leído necesariamente todas las definiciones de la unidades en esta vista, solo presente información sobre los propios archivos. El resultado tiene dos columnas, el archivo de la unidad y el estado.

      Output

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

      El estado normalmente estará habilitado, deshabilitado, estático o enmascarado. En este contexto, “estático” significa que el archivo de unidad no contiene una sección install, que se utiliza para habilitar una unidad. Como tal, estas unidades no pueden habilitarse. Normalmente, esto significa que la unidad realiza una única acción o se utiliza solo como dependencia de otra unidad y no debería ejecutarse por sí misma.

      En breve explicaremos lo que significa enmascarado.

      Gestión de la unidad

      Hasta ahora, hemos estado trabajando con servicios y mostrando información sobre la unidad y los archivos de la unidad que systemd conoce. Sin embargo, encontraremos más información específica sobre las unidades usando algunos comandos adicionales.

      Mostrar un archivo de unidad

      Para mostrar el archivo de unidad que systemd ha cargado en su sistema, puede usar el comando cat (esto se añadió en la versión 209 de systemd). Por ejemplo, para ver el archivo de unidad del daemon de programación atd, podríamos escribir:

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      El resultado es el archivo de unidad tal como lo conoce el proceso systemd que se está ejecutando actualmente. Esto puede ser importante si ha modificado archivos de unidad recientemente o si está omitiendo ciertas opciones en un fragmento del archivo de unidad (hablaremos de esto más tarde).

      Mostrar dependencias

      Para ver el árbol de dependencias de una unidad, puede usar el comando list-dependencies:

      • systemctl list-dependencies sshd.service

      Esto mostrará una jerarquía asignando las dependencias que deben tratarse para iniciar la unidad en cuestión. Las dependencias, en este contexto, incluyen las unidades que son necesarias o deseadas por unidades de nivel superior.

      Output

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

      Las dependencias recursivas solo se muestran para las unidades .target, que indican los estados del sistema. Para listar de forma recursiva todas las dependencias, incluya el indicador --all.

      Para mostrar las dependencias inversas (unidades que dependen de la unidad especificada) puede añadir el indicador --reverse al comando. Otros indicadores que son útiles son los indicadores --before y --after, que pueden usarse para mostrar las unidades que dependen de la unidad especificada que comienza antes y después de ellas mismas respectivamente.

      Comprobar las propiedades de la unidad

      Para ver las propiedades de nivel bajo de una unidad, puede usar el comando show. Esto mostrará una lista de propiedades que se establecen para la unidad especificada usando un formato key=value:

      • systemctl show sshd.service

      Output

      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 desea mostrar una única propiedad, pude pasar el indicador -p con el nombre de la propiedad. Por ejemplo, para ver los conflictos que la unidad sshd.service tiene, puede escribir:

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Enmascarar y desenmascarar unidades

      Vimos en la sección de administración del servicio cómo detener o deshabilitar un servicio, pero systemd también tiene la capacidad de marcar una unidad como completamente no iniciable, automática o manualmente, vinculándola a /dev/null. Esto se denomina enmascarar la unidad, y es posible con el comando mask:

      • sudo systemctl mask nginx.service

      Esto impedirá que el servicio Nginx se inicie, automática o manualmente, siempre que esté enmascarado.

      Si comprueba los list-unit-files, verá que el servicio ahora se lista como enmascarado:

      • systemctl list-unit-files

      Output

      . . . 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 intenta iniciar el servicio, verá un mensaje como este:

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Para desenmascarar una unidad, y hacer que esté disponible de nuevo para su uso, utilice el comando unmask:

      • sudo systemctl unmask nginx.service

      Esto devolverá la unidad a su estado anterior, permitiendo que se inicie o habilite.

      Editar archivos de la unidad

      Aunque el formato específico de los archivos de unidad está fuera del alcance de este tutorial, si necesita realizar ajustes, systemctl proporciona mecanismos integrados para editar y modificar archivos de unidad. Esta funcionalidad fue añadida en la versión 218 de systemd.

      El comando edit, por defecto, abrirá un fragmento de código del archivo de la unidad para la unidad en cuestión:

      • sudo systemctl edit nginx.service

      Este será un archivo en blanco que puede usarse para omitir o añadir directivas a la definición de la unidad. Se creará un directorio en el directorio /etc/systemd/system que contiene el nombre de la unidad con .d anexada. Por ejemplo, para el nginx.service, se creará un directorio llamado nginx.service.d.

      En este directorio, se creará un fragmento de código llamado override.conf. Cuando se carga la unidad, systemd, en la memoria, fusionará el fragmento de código de anulación con el archivo de unidad completo. Las directivas del snippet prevalecerán sobre las encontradas en el archivo original de la unidad.

      Si desea editar el archivo completo de la unidad en vez de crear un fragmento de código, puede pasar el indicador --full:

      • sudo systemctl edit --full nginx.service

      Esto cargará el archivo de unidad actual en el editor, donde se podrá modificar. Cuando sale el editor, el archivo cambiado se escribirá a /etc/systemd/system, que tendrá prioridad sobre la definición de la unidad del sistema (normalmente se encuentra en algún lugar de /lib/systemd/system).

      Para eliminar cualquier adición que haya realizado, elimine el directorio de configuración .d de la unidad o el archivo de servicio modificado de /etc/systemd/system. Por ejemplo, para eliminar un fragmento de código, podríamos escribir lo siguiente:

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Para eliminar un archivo de unidad completo modificado, escribiríamos:

      • sudo rm /etc/systemd/system/nginx.service

      Tras eliminar el archivo o directorio, debería volver a cargar el proceso systemd de forma que deje de intentar hacer referencia a estos archivos y vuelve a usar las copias del sistema. Puede hacerlo escribiendo lo siguiente:

      • sudo systemctl daemon-reload

      Ajustar el estado del sistema (Runlevel) con los destinos

      Los destinos son archivos de unidad especiales que describen el estado de un sistema o un punto de sincronización. Igual que otras unidades, los archivos que definen los destinos pueden identificarse por su sufijo, que en este caso es .target. Los destinos no hacen mucho por sí mismos, pero se utilizan para agrupar otras unidades.

      Esto puede usarse para llevar al sistema a ciertos estados, de forma muy similar que otros sistemas init utilizan runlevels. Se utilizan como referencia para cuando ciertas funciones estén disponibles, lo que le permite especificar el estado deseado en vez de las unidades individuales necesarias para producir ese estado.

      Por ejemplo, hay un swap.target que se usa para indicar que swap está listo para usarse. Las unidades que son parte de este proceso pueden sincronizarse con este destino indicando en su configuración que son WantedBy= o RequiredBy= el swap.target. Las unidades que requieren que swap esté disponible pueden especificar esta condición usando las especificaciones Wants=, Requires= y After= para indicar la naturaleza de su relación.

      Obtener y establecer el destino predeterminado

      El proceso systemd tiene un destino predeterminado que utiliza cuando se inicia el sistema. Satisfacer la cascada de dependencias de ese destino individual llevará al sistema al estado deseado. Para encontrar el destino predeterminado de su sistema, escriba:

      Output

      multi-user.target

      Si desea establecer un destino predeterminado diferente, puede usar set-default. Por ejemplo, si tiene un escritorio gráfico instalado y desea que el sistema se inicie a esto por defecto, puede cambiar el destino predeterminado:

      • sudo systemctl set-default graphical.target

      Cómo enumerar los destinos disponibles

      Puede obtener una lista de los destinos disponibles en su sistema escribiendo:

      • systemctl list-unit-files --type=target

      A diferencia de runlevels, puede haber múltiples destinos activos a la vez. Un destino activo indica que systemd ha intentado iniciar todas las unidades relacionadas con el destino y no ha intentado desglosarlas de nuevo. Para ver todos los destinos activos, escriba:

      • systemctl list-units --type=target

      Aislar destinos

      Es posible iniciar todas las unidades asociadas con un destino y detener todas las que no son parte del árbol de dependencias. El comando que necesitamos para hacer esto se denomina, apropiadamente, isolate. Esto es similar a cambiar el runlevel en otros sistemas init.

      Por ejemplo, si está operando en un entorno gráfico con graphical.target activo, puede apagar el sistema gráfico y poner el sistema en un estado de línea de comando multi usuario asilando el multi-user.target. Ya que graphical.target depende de multi-user.target pero no al revés, todas las unidades gráficas se detendrán.

      Quizá desee echar un vistazo a las dependencias del destino que está aislando antes de realizar este procedimiento para asegurarse de que no está deteniendo servicios cruciales:

      • systemctl list-dependencies multi-user.target

      Cuando esté satisfecho con las unidades que se mantendrán activas, puede aislar el destino escribiendo lo siguiente:

      • sudo systemctl isolate multi-user.target

      Cómo usar atajos para eventos importantes

      Existen destinos definidos para eventos importantes como apagar o reiniciar. Sin embargo, systemctl también tiene algunos atajos que añaden ciertas funciones adicionales.

      Por ejemplo, para poner el sistema en el modo rescate (usuario único), puede usar simplemente el comando rescue en vez de isolate rescue.target,

      Esto proporcionará la funcionalidad adicional de alertar a todos los usuarios con sesión iniciada sobre el evento.

      Para detener el sistema, puede usar el comando halt:

      Para iniciar un apagado completo, puede usar el comando poweroff:

      Puede iniciar un reinicio con el comando reboot:

      Todos estos comandos alertan a los usuarios con sesión iniciada de que se va a producir el evento, algo que ejecutar o aislar el destino únicamente no hará. Observe que la mayoría de los equipos vincularán los comandos más cortos y convencionales para estas operaciones de forma que funcionen adecuadamente con systemd.

      Por ejemplo, para reiniciar el sistema, normalmente puede escribir:

      Conclusión

      Ahora debería estar familiarizado con algunas de las capacidades básicas del comando systemctl que le permite controlar e interactuar con su instancia de systemd. La utilidad systemctl será su punto de interacción principal para la administración del estado del servicio y del sistema.

      Aunque systemctl opera principalmente con el proceso central systemd, hay otros componentes para el ecosistema de systemd que están controlados por otras utilidades. Otras capacidades, como la administración de registros y las sesiones de usuario se administran mediante daemons y utilidades de administración independientes (journald/journalctl y logind/loginctl, respectivamente). Al tomarse el tiempo para familiarizarse con estas herramientas y daemons, la administración le resultará más sencilla.



      Source link