Comment configurer un service Linux pour qu'il démarre automatiquement après un redémarrage ou un plantage du système : Partie 2 (Explications théoriques)

Dans ce deuxième volet du tutoriel en deux parties sur la configuration de Linux des services pour qu'ils démarrent automatiquement après un redémarrage ou un plantage du système, nous aborderons le système init en détail. Vous pouvez vous référer à la Partie 1 de la série : Comment configurer un service Linux pour qu'il démarre automatiquement après un redémarrage ou un plantage du système : Exemples pratiques ici.

Le présent tutoriel sera très théorique. Par conséquent, vous devriez l'utiliser comme référence pour acquérir une compréhension plus approfondie du fonctionnement du système init sous Linux. Dans le premier volet de ce tutoriel, nous avons partagé quelques extraits de code et scripts de démarrage que le système init lit lors du démarrage. Nous avons également utilisé MySQL comme exemple pour apprendre à activer et désactiver le démarrage automatique d'un service Linux après un plantage ou un redémarrage. Comme vous l'avez appris dans le premier volet de ce tutoriel en deux parties, trois systèmes init sont utilisés dans les différentes distributions de Linux : System V, Upstart et Systemd. Vous pouvez vous référer à la première partie de ce tutoriel pour comprendre la distribution et la version configurées pour utiliser un système init particulier.

Dans ce tutoriel, nous expliquerons le code que nous avons utilisé dans la première partie du tutoriel. Nous détaillerons les commandes et les fichiers de configuration que le système init utilise. Commençons !

Prérequis

Dans la conclusion de la première partie de ce tutoriel en deux parties, nous avons mentionné que vous deviez garder les trois serveurs de test actifs. Si vous les aviez supprimés, vous pouvez revenir en arrière et les recréer. Cela vous aidera à suivre le tutoriel. Les trois serveurs de test que vous devriez avoir sont :

• Ubuntu 9.04 et versions antérieures, ou Debian 6 x64 (nous l'utiliserons pour faire la démonstration du système init System V)
• Ubuntu 14.04 x64 (nous l'utiliserons pour faire la démonstration d'Upstart). Voici un tutoriel sur la façon de configurer facilement votre serveur Ubuntu.
• CentOS 7 x64 (nous l'utiliserons pour faire la démonstration de Systemd).

Vous should disposer d'un utilisateur avec des privilèges sudo sur chacun des serveurs que vous utiliserez pour exécuter les commandes. Ce tutoriel sur la configuration du fichier sudoers de Linux peut vous guider.

Remarque : Les commandes de ce tutoriel vont interférer avec les services du système. Par conséquent, vous ne devez pas les appliquer sur un serveur de production actif.

Niveaux d'exécution

Un niveau d'exécution est un niveau opérationnel qui décrit l'état actuel d'un système Linux par rapport aux services disponibles. Le concept provient de l'init System V. Lorsque le système Linux démarre, il initialise le noyau, entre dans un niveau d'exécution et exécute le script de démarrage associé à ce niveau d'exécution. Vous ne pouvez exécuter qu'un seul niveau d'exécution au démarrage.

D'autres exemples de niveaux d'exécution incluent l'état d'arrêt, le mode de redémarrage, un mode mono-utilisateur, etc. Chaque niveau détermine quels services exécuter dans cet état. Certains services peuvent s'exécuter sur plus d'un niveau, tandis que d'autres ne le peuvent pas.

Il existe sept niveaux d'exécution : de 0 à 6. Voici une définition des sept niveaux d'exécution :

• Niveau d'exécution 0 : Arrêt du système
• Niveau d'exécution 1 : Mode mono-utilisateur et de secours
• Niveaux d'exécution 2, 3, 4 : Mode multi-utilisateur et texte avec réseau activé
• Niveau d'exécution 5 : Mode multi-utilisateur, réseau activé et graphique
• Niveau d'exécution 6 : Redémarrage du système

Les niveaux d'exécution ne sont pas nécessairement exécutés de manière séquentielle. Les niveaux d'exécution 2, 3 et 4 varient selon la distribution Linux que vous utilisez. Vous pouvez implémenter le niveau d'exécution 4 dans certaines distributions et pas dans d'autres. Lorsque vous avez activé le démarrage automatique d'un service, comme expliqué dans la première partie, vous l'avez en fait ajouté à un niveau d'exécution. Dans System V, le système d'exploitation démarre avec un niveau d'exécution particulier et, pendant le démarrage, il tente de démarrer tous les services associés à ce niveau d'exécution. Les niveaux d'exécution sont des cibles (targets) dans Systemd, que nous aborderons dans la section Systemd.

Init et PID 1

Le système init est le tout premier processus qui s'exécute lorsqu'un système Linux démarre et que le noyau se charge en mémoire. Il effectue diverses tâches, notamment déterminer comment un processus utilisateur ou un service système va se charger, dans quel ordre, et s'il doit démarrer automatiquement. Dans chaque distribution Linux, chaque processus est identifié par un identifiant de processus (PID) et init a un PID de 1. C'est le parent de tous les autres processus qui démarrent successivement au fur et à mesure du démarrage du système.

Histoire d'init

Le système d'init présent dans les distributions Linux récentes est une amélioration de l'original. Les premières versions des distributions Linux utilisaient l'init System V, qui était également utilisé dans les systèmes Unix. À mesure que Linux a évolué, le démon d'init Upstart a été implémenté – il a été créé par Ubuntu. Aujourd'hui (au moment de la rédaction de ce tutoriel, en 2021), nous avons le démon d'init Systemd – qui a été implémenté pour la première fois par Fedora. Alors que les systèmes Linux continuent d'évoluer, il se peut qu'un nouveau système d'init apparaisse. Pour ce tutoriel, nous allons aborder ces trois-là : System V, Upstart et Systemd.

Les versions récentes de Linux sont équipées par défaut du système d'init Systemd. Cependant, elles ont conservé les autres systèmes d'init plus anciens pour des raisons de rétrocompatibilité. Il existe différentes implémentations de System V que vous pouvez utiliser dans d'autres variantes de Linux. Par exemple, FreeBSD, une variante d'UNIX, utilise BSD init. Les anciennes versions de Debian utilisent SysVinit. Les deux proviennent de System V.

La manière dont chaque version du démon d'init gère les services est différente. Les améliorations apportées à chaque version visaient à obtenir un outil de gestion de services robuste, capable de gérer tout ce dont un système Linux a besoin, qu'il s'agisse de services, de périphériques, de ports ou d'autres ressources. Il y avait un besoin pour un système puissant capable de charger des ressources en parallèle et de se rétablir élégamment après un plantage du système.

Séquence d'init de System V

System V utilise un fichier inittab pour stocker les instructions d'initialisation. Upstart conserve le fichier inittab pour des raisons de rétrocompatibilité. Voici le flux de démarrage de System V :

• Le système d'init provient du fichier binaire /sbin/init.
• Une fois que le système d'init est chargé en mémoire, il lit son premier fichier à l'emplacement /etc/inittab.
• L'une des entrées de ce fichier détermine le niveau d'exécution (runlevel) dans lequel la machine doit démarrer. Par exemple, si la valeur du runlevel est définie sur 5, Linux démarrera en mode multi-utilisateur, graphique, avec le réseau activé (courant dans les distributions conçues pour un usage de bureau). Le runlevel spécifié ici est appelé le runlevel par défaut car c'est celui qui sera toujours utilisé.
• Ensuite, le système d'init cherche plus loin dans le fichier /etc/inittab et lit les scripts d'init qu'il doit exécuter pour ce runlevel.

En trouvant quels scripts exécuter pour un runlevel donné, le système d'init trouvera les services qu'il doit démarrer. C'est généralement dans ces scripts d'init que vous configurez le comportement de démarrage de chaque service, de la même manière que nous configurons le service MySQL dans la première partie de ce tutoriel.

Structure des scripts d'init de System V

Dans cette section, nous allons examiner les scripts d'init en détail. Les fichiers de configuration ou scripts d'init de System V sont ce qui contrôle les services. Les scripts d'init initialisent un service, d'où le nom de script d'init.

Chaque service a son propre script d'init. Par exemple, le script d'init MySQL contrôle le serveur MySQL. Les fournisseurs d'applications fournissent les scripts d'init pour leur application spécifique, tandis que les services Linux natifs sont fournis avec l'installation du système d'exploitation. Lorsque vous créez une application personnalisée, vous pouvez également créer vos propres scripts d'init personnalisés pour celle-ci.

Pour démarrer un service comme le serveur MySQL, son programme binaire est d'abord chargé en mémoire. Selon sa configuration, le programme peut continuer à s'exécuter en arrière-plan pour continuer à accepter les connexions des clients. Le script d'init du service gère le démarrage, l'arrêt ou le rechargement de l'application binaire. Les scripts d'init dans System V sont des scripts shell. Un autre nom pour ceux-ci est scripts rc (run command).

Structure des répertoires de System V

Le répertoire parent des scripts d'init est le répertoire /etc. Le répertoire /etc/init.d est le répertoire réel des scripts shell d'init. Les scripts sont liés par des liens symboliques (symlinks) aux répertoires rc.

Il existe plusieurs répertoires rc dans le répertoire /etc, chacun ayant un numéro dans son nom. Les numéros représentent différents runlevels. Si vous listez le contenu du répertoire, vous verrez des noms comme /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, etc.

Si vous affichez le contenu de chacun des répertoires rc, vous verrez des fichiers qui commencent par K ou S dans leur nom de fichier, suivi de deux chiffres. Ces fichiers contiennent des liens symboliques pointant vers les scripts shell init réels du programme réel. Les lettres K et S sont des abréviations : K signifie Kill ou Stop, tandis que S signifie Start. Les deux chiffres dans les noms de fichiers représentent l'ordre d'exécution. Si vous voyez un fichier nommé K05script_name, il s'exécutera avant un fichier nommé K09script_name.

Démarrage

En progressant dans la séquence de démarrage, voyons comment les scripts init sont appelés.

Les scripts S et K ne sont pas appelés directement par le système init. Ils sont plutôt appelés par un autre script : le script /etc/init.d/rc. Le fichier /etc/inittab indique au démon init dans quel niveau d'exécution (runlevel) le système doit démarrer par défaut. Selon le niveau d'exécution spécifié, une ligne dans le fichier /etc/inittab appelle le script /etc/init.d/rc, en passant le niveau d'exécution par défaut en paramètre. À l'aide de ce paramètre, le script appellera les fichiers sous le répertoire /etc/rc correspondantN.d, où N désigne le niveau d'exécution. Par exemple, si le serveur démarre avec le niveau d'exécution 5, les fichiers correspondants sous le répertoire /etc/rc5.d seront appelés.

À l'intérieur du répertoire rc, tous les scripts K sont exécutés numériquement avec un argument de stop, tandis que tous les scripts S sont exécutés de la même manière avec un argument de start. Les scripts shell init réels correspondants pour le programme vers lequel pointent les liens symboliques sous /etc/rcN.d seront appelés avec les paramètres stop et start respectivement.

En termes simples, ce qui se passe chaque fois qu'un système Linux entre ou passe à un certain niveau d'exécution, c'est que certains scripts seront exécutés pour arrêter certains services, tandis que d'autres seront exécutés pour démarrer d'autres services. Ce processus garantit que tout processus qui n'est pas censé s'exécuter dans un état Linux donné est arrêté, et que tout processus qui devrait s'exécuter est démarré automatiquement.

Démarrage automatique de System V

Lorsque vous activez le démarrage automatique d'un service au démarrage, vous modifiez directement le comportement d'init. Par exemple, si vous configurez un service pour qu'il démarre automatiquement au niveau d'exécution 2, le processus init crée les liens symboliques appropriés dans le répertoire /etc/rc2.d. Pour vous aider à comprendre, nous allons vous expliquer cela à l'aide d'un exemple.

Exemple System V

Pour vous donner un exemple pratique, nous utiliserons la configuration du service MySQL de la partie 1. Ainsi, connectez-vous au VPS Debian 6 avec votre utilisateur sudo/root en utilisant ssh (ou putty si vous êtes sous Windows), et procédez aux étapes suivantes.

Étape 1 : Ouvrir et examiner le fichier inittab

Tout d'abord, saisissez la commande suivante pour afficher le contenu du fichier inittab sur le terminal :

Le contenu du fichier devrait ressembler à ceci :

Le chiffre 2 indique le niveau d'exécution avec lequel le système démarre. Dans ce cas, le niveau d'exécution 2 est le niveau par défaut, ce Debian démarrera donc en niveau d'exécution 2 en mode multi-utilisateur, mode texte. Vous pouvez exécuter la commande suivante pour confirmer :

Il affichera un résultat similaire à :

Étape 2 : Examen des répertoires rc

Ensuite, pour lister les répertoires rc, exécutez la commande suivante :

Voici une capture d'écran du résultat :

Comme nous l'avons vu précédemment dans le fichier inittab, le système est configuré pour démarrer au runlevel 2, par conséquent les scripts sous /etc/rc2.d seront exécutés au démarrage du système. Vous pouvez lister le contenu de ce répertoire en utilisant la commande :

Comme vous pouvez le voir sur le résultat, les fichiers ne sont que des liens symboliques pointant vers les fichiers de script réels sous /etc/init.d. Voici un extrait du résultat :

Il n'y a pas de scripts K dans ce répertoire, seulement des scripts S (start). Les scripts démarreront les services liés ici, comme rsync. Vous pouvez également remarquer le service mysql répertorié, dont nous parlerons dans le prochain sous-thème.

Étape 3 : Examen du script d'initialisation

Lorsqu'un service conforme à System V est installé, il crée un script shell sous le répertoire /etc/init.d. Vous pouvez vérifier la disponibilité du script shell MySQL en saisissant la commande suivante :

Il affiche la sortie ci-dessous :

Le fichier est assez volumineux. Vous pouvez saisir la commande suivante pour afficher son contenu :

Étape 4 : Utilisation de chkconfig ou sysv-rc-conf

Chkconfig est une commande que vous pouvez utiliser dans les distributions basées sur RHEL comme CentOS pour activer ou désactiver les services compatibles System V. Vous pouvez également l'utiliser pour lister les services installés et leurs niveaux d'exécution respectifs. Voici la commande pour cela (fonctionne sur CentOS) :

Dans les distributions Debian, un tel utilitaire n'existe pas nativement. L'outil update-rc.d dans les systèmes Debian installe et supprime uniquement des services des niveaux d'exécution. Un outil personnalisé est disponible et vous pouvez l'utiliser pour apporter la fonctionnalité chkconfig aux systèmes Debian. Saisissez la commande suivante pour l'installer :

Une fois installé, vous pouvez exécuter la commande suivante pour afficher les comportements des niveaux d'exécution pour divers services :

La sortie de cette commande est formatée dans un tableau qui montre le nom du service à gauche et le niveau d'exécution sous lequel le service s'exécute :

Le X indique le niveau d'exécution sous lequel le service s'exécutera. Cet outil vous permet de désactiver ou d'activer un service pour un niveau d'exécution à l'aide des touches fléchées et de la barre d'espace. Pour quitter l'outil, appuyez sur Q.

Étape 5 : Tester le comportement au démarrage de MySQL pendant le démarrage du système

D'après la capture d'écran ci-dessus, vous pouvez voir que le service mysql est activé sur les niveaux d'exécution 2,3,4,5. Vous pouvez désactiver MySQL à l'aide de la commande suivante :

La sortie ressemble à ceci. Notez que le service s'est arrêté pour tous les niveaux d'exécution :

Exécutez la commande ci-dessous pour voir le contenu du répertoire :

Consultez la ligne mysql dans la sortie ci-dessous :

La sortie montre que le lien symbolique a changé pour K, ce qui signifie Kill (arrêter). Par conséquent, MySQL ne démarrera pas automatiquement par défaut au niveau d'exécution 2. Chaque fois que vous activez ou désactivez un service dans System V, c'est ce qui se produit. Tant qu'il y a un script S (start) sous le répertoire du niveau d'exécution par défaut pour un service, le démon init démarrera ce service lors du démarrage du système.

Pour réactiver le service, saisissez la commande suivante :

Étape 6 : Tester le comportement au démarrage de MySQL après un plantage du système

Dans cette section, nous verrons comment System V gère les plantages de services. Vous pouvez utiliser ces connaissances pour configurer le comportement de vos services personnalisés après un plantage.

Dans la première partie de ce tutoriel, nous avions apporté une modification au fichier /etc/inittab pour permettre à MySQL de démarrer automatiquement après un plantage. Nous avons ajouté la ligne suivante pour activer ce comportement :

Nous pouvons vérifier ce comportement en effectuant quelques tests. Tout d'abord, redémarrez votre VPS en saisissant la commande suivante :

Après le redémarrage, vérifiez avec quels identifiants de processus (PID) mysql_safe et mysqld s'exécutent, saisissez la commande suivante pour obtenir les identifiants de processus :

La sortie que nous avons obtenue était :

Prenez note des ID de processus. Dans notre cas, il s'agissait de 1836 et 186338. Maintenant, simulez un plantage en tuant le processus avec le commutateur -9 en saisissant la commande suivante. N'oubliez pas de remplacer par vos ID de processus :

Après quelques minutes, vérifiez le statut de MySQL en exécutant la commande suivante :

La sortie indique que MySQL est en cours d'exécution, ce qui signifie qu'il a été relancé après la simulation de plantage. Si vous exécutez la commande ps -ef | grep mysql à nouveau, vous constaterez que les deux processus mysqld_safe et mysqld sont en cours d'exécution, bien qu'avec de nouveaux ID.

Vous pouvez essayer de tuer les processus plusieurs fois et ils se relanceront après quelques minutes. Ce comportement est possible grâce à la ligne que nous avons ajoutée au fichier /etc/inittab. C'est ainsi que vous configurez les services pour qu'ils redémarrent automatiquement après un plantage dans System V. Pour revoir la syntaxe, jetez un œil à la partie 1 de ce tutoriel.

Certains services personnalisés peuvent comporter des bogues et ne pas réussir à se relancer après plusieurs tentatives. Le démon init tentera de relancer un service, mais s'il échoue plus de dix fois en deux minutes, le système Linux désactive le service pendant un maximum de 5 minutes. Cela permet de maintenir la stabilité du système et de s'assurer que les ressources système ne sont pas gaspillées pour des services défaillants. C'est une bonne idée de vérifier les journaux de votre système pour identifier les problèmes de vos applications personnalisées qui doivent être corrigés.

Introduction à Upstart

Le système d'initialisation System V a été crucial pour les distributions Linux pendant longtemps. Cependant, comme c'est le cas avec la technologie, elle continue de progresser. L'écosystème Linux s'est considérablement développé grâce au soutien de la communauté open-source. System V charge les tâches et les services de manière sérialisée, ce qui apporte de la complexité et consomme du temps. De plus, l'introduction de supports de stockage amovibles modernes pour lesquels System V n'avait pas été conçu a motivé le besoin d'un système d'initialisation différent.

Les développeurs d'Ubuntu ont commencé à travailler sur un autre système d'initialisation. Ce système d'initialisation a été conçu pour permettre un chargement plus rapide du système d'exploitation, assurer un nettoyage propre des services plantés, maintenir la prévisibilité des dépendances entre les services système et prendre en compte les supports de stockage amovibles. Le démon Upstart était né.

L'initialisation Upstart présente plusieurs avantages par rapport à l'initialisation System V de la manière suivante :

• Upstart ne charge pas les services de manière sérialisée comme System V, réduisant ainsi le temps de démarrage du système.
• Il est conçu pour mieux gérer les services plantés grâce à un nettoyage propre et à une relance du service.
• Upstart utilise un système d'événements flexible pour personnaliser la gestion des services dans différents états.
• L'init évite les scripts shell complexes pour charger et gérer les services comme dans System V. Upstart utilise des fichiers de configuration simples, faciles à comprendre et à modifier.
• Upstart a été conçu dans un souci de rétrocompatibilité. Le script /etc/init.d/rc s'exécute toujours pour gérer les services System V natifs.
• Il évite de conserver des liens symboliques redondants, pointant tous vers le même script.

Événements Upstart

Upstart est basé sur les événements, ce qui permet d'associer plusieurs événements au même service. Cette architecture événementielle garantit une gestion flexible des services. Chaque événement peut appeler un script shell spécifique à l'événement.

Les événements Upstart incluent :

• Starting
• Started
• Stopping
• Stopped

Entre deux événements, un service peut se trouver dans différents états, y compris, mais sans s'y limiter :

• Waiting
• Pre-start
• Starting
• Post-start
• Running
• Pre-stop
• Stopping
• Post-stop

L'init Upstart peut être configuré pour entreprendre des actions pour chacun de ces états, d'où sa conception flexible.

Séquence de démarrage de l'init Upstart

L'init Upstart exécute le script /etc/init.d/rc au démarrage, tout comme System V. Ce script exécute normalement tous les scripts d'initialisation System V pour assurer la rétrocompatibilité.

Les fichiers de configuration d'Upstart sont situés dans le répertoire /etc/init, il y regarde donc par défaut et exécute les commandes shell trouvées dans les fichiers de configuration de ce répertoire.

Fichiers de configuration Upstart

L'init Upstart utilise des fichiers de configuration de service pour contrôler les services, contrairement aux scripts bash utilisés dans System V. La norme de nommage pour ces fichiers de configuration de service est service_name.conf.

Les fichiers contiennent du contenu en texte brut divisé en plusieurs sections appelées stanzas. Chaque stanza décrit un état différent d'un service et son comportement. Différentes stanzas contrôlent différents événements d'un service. Par exemple, waiting, pre-start, start, pre-stop, stopping, etc.

Une stanza contient des commandes shell, ce qui permet d'initier plusieurs actions pour chaque événement de chaque service. De plus, chaque fichier de configuration de service spécifie les deux choses suivantes :

• Les niveaux d'exécution (runlevels) sur lesquels le service doit démarrer et s'arrêter.
• Si le service doit redémarrer (respawn) s'il plante.

Structure des répertoires d'Upstart

Les fichiers de configuration du service Upstart sont situés sous le répertoire /etc/init . Ne confondez pas cela avec /etc/init.d.

Exemple Upstart

Dans cet exemple, nous verrons comment Upstart gère un service lors du démarrage du système et en cas de plantage. Nous entrerons plus en détail en expliquant les exemples pratiques présentés dans la première partie de ce tutoriel.

Étape 1 : Connectez-vous au serveur Ubuntu 14.0.4

Tout d'abord, pour tester Upstart, nous utiliserons le deuxième VPS, celui qui exécute Ubuntu 14.0.4. C'est parce que cette distribution Linux implémente Upstart nativement. Utilisez ssh ou putty si vous êtes sous Windows. Vous devez vous connecter avec un utilisateur disposant des privilèges root ou sudo. J'ai un utilisateur appelé hackins, voici donc comment je me connecterais :

Remplacez par votre utilisateur root/sudo et l'adresse IP publique du serveur. Ensuite, appuyez sur Entrée et fournissez un mot de passe ou une phrase secrète.

Étape 2 : Examinez les répertoires init et rc

Les fichiers de configuration d'Upstart sont stockés dans le répertoire /etc/init. C'est le répertoire que vous utiliserez lors de la création de nouveaux fichiers de configuration de service.

Pour lister les noms des fichiers de configuration dans le répertoire /etc/init, exécutez la commande suivante :

Comme vous le verrez dans la sortie de la commande ci-dessus, de nombreux services s'exécutent sous Upstart. Appuyez sur Q pour quitter less.

Si vous exécutez la commande suivante pour lister les fichiers de configuration de service pour System V dans le répertoire rc, vous n'en verrez que quelques-uns :

Étape 3 : Examinez un fichier Upstart

Dans le premier volet de ce tutoriel, nous avions utilisé un fichier mysql.conf pour en savoir plus sur la configuration du serveur. Pour approfondir nos connaissances, utilisons une configuration différente. Le fichier de configuration cron est un bon candidat. Entrez la commande suivante pour ouvrir le fichier :

Vous devriez obtenir une sortie similaire à la capture d'écran ci-dessous :

Le script est assez simple. Notez les champs importants suivants : start on, stop on, fork, et respawn. Définissons ce que font ces directives :

• start on indique à Ubuntu de démarrer le démon cron lorsque le système entre dans les niveaux d'exécution 2, 3, 4 ou 5. Il ne s'exécutera pas sur les autres niveaux d'exécution non spécifiés ici, c'est-à-dire 0, 1 ou 6.
• stop on indique à Ubuntu d'arrêter un démon en cours d'exécution. Cependant, dans ce cas, il y a un point d'exclamation (!) qui est un signe de négation. Le script ne doit pas être arrêté sur les niveaux d'exécution après le point d'exclamation : 2,3,4,5.
• fork indique à Upstart de détacher le processus de la console et de le maintenir en cours d'exécution en arrière-plan.
• respawn indique au système de démarrer cron automatiquement s'il plante pour une raison quelconque.

Appuyez sur Ctrl X pour quitter l'éditeur sans rien saisir.

Les autres fichiers de configuration d'Upstart suivent la même structure, avec des stanzas pour start, stop et respawn. Certains fichiers de configuration peuvent avoir des blocs de script supplémentaires pour pre-start, pre-stop, post-start, etc. Ces blocs de code indiquent au système ce qu'il doit exécuter lorsqu'un processus se trouve dans l'un des états définis.

Étape 4 : Tester le comportement au démarrage du service MySQL après le démarrage du système

Par défaut, MySQL est configuré pour démarrer automatiquement après le démarrage du système. Nous allons essayer de le désactiver et voir son comportement. Dans Upstart, un service peut être désactivé en créant un fichier nommé service_name.override sous le répertoire /etc/init/. Le contenu du fichier est juste un mot : manual.

Voyons comment nous pouvons utiliser cette commande pour désactiver le service MySQL. Saisissez la commande suivante pour ouvrir le fichier avec l'éditeur nano :

Dans le fichier ouvert, ajoutez la ligne suivante :

Enregistrez les modifications en appuyant sur Ctrl + O, puis Entrée. Quittez l'éditeur en appuyant sur Ctrl + X. Exécutez la commande suivante pour redémarrer le serveur :

Attendez quelques minutes, puis reconnectez-vous. Une fois connecté, testez l'état du service MySQL en saisissant la commande suivante :

La sortie indiquera que le service n'est pas en cours d'exécution :

Cela indique que MySQL n'a pas démarré automatiquement après le démarrage du système. Ensuite, ouvrez le fichier de configuration de MySQL et vérifiez si la directive start a changé :

La sortie indiquera que rien n'a été modifié :

Cela signifie que si votre service ne démarre pas automatiquement et que vous vérifiez uniquement le fichier de configuration du service (service_name.conf), vous risquez de ne pas trouver l'erreur. Vous devriez également vérifier l'existence du fichier service_name.override dans le répertoire.

Saisissez la commande suivante pour supprimer le fichier d'override et réactiver le service MySQL. Ensuite, redémarrez le serveur :

Une fois que le serveur a démarré, testez à nouveau l'état du service MySQL :

Il devrait indiquer que le service MySQL a démarré automatiquement.

Étape 5 : Tester le comportement au démarrage du service MySQL après un plantage du système

Par défaut, le service MySQL redémarre automatiquement s'il plante. Pour arrêter ce comportement, nous allons modifier le fichier mysql.conf. Saisissez la commande suivante pour ouvrir le fichier avec l'éditeur nano :

Recherchez les lignes de la directive respawn et commentez-les comme indiqué ci-dessous avec #:

Exécutez les commandes suivantes pour redémarrer le service :

Nous avons utilisé les commandes ci-dessus pour arrêter et démarrer le service car l'utilisation de initctl restart ou initctl reload ne fonctionnerait pas ici. Lorsque vous exécutez la commande pour démarrer le service MySQL, la sortie affichera un PID pour MySQL comme :

Notre PID était 1439. Ensuite, notez ce que vous avez obtenu lorsque vous avez exécuté la commande, nous l'utiliserons à l'étape suivante. Pour simuler un plantage, tuez le processus MySQL à l'aide de la commande suivante, en n'oubliant pas de remplacer votre PID comme expliqué ci-dessus :

Pour vérifier si MySQL a redémarré après le plantage, attendez quelques minutes puis saisissez la commande suivante :

La sortie indiquera que MySQL est arrêté :

Essayez de vérifier l'état encore quelques fois pour voir s'il y a un changement. Vous remarquerez que MySQL reste arrêté. Cela est dû au fait que le fichier de configuration du service ne contient pas les directives respawn (celles que nous avons commentées). Consultez la partie 1 de ce tutoriel pour plus d'explications sur la directive respawn.

Pourquoi vous avons-nous montré comment désactiver le redémarrage automatique des services après le démarrage ou le plantage du système ? C'est principalement à des fins de dépannage. Si, par exemple, votre service démarre et ne cesse de planter, vous pouvez souhaiter le désactiver afin de pouvoir résoudre le problème, tout en maintenant la stabilité de votre système. Vous pouvez également empêcher certaines anciennes configurations de services de redémarrer automatiquement si vous passez à une nouvelle distribution Linux qui intègre nativement systemd abordé dans la section suivante.

Introduction à Systemd

Systemd est le système d'initialisation le plus récent, présent dans les distributions Linux les plus récentes. Il comprend de nombreux composants qui constituent un système Linux moderne.

Systemd gère non seulement les services mais aussi l'ensemble du système Linux. Dans cette section, nous allons nous concentrer sur la façon dont systemd contrôle le comportement des services après un démarrage ou un plantage du système.

Systemd est rétrocompatible avec les scripts d'initialisation et les commandes de System V. Par conséquent, si vous avez des services configurés pour System V, ils fonctionneront également sous Systemd. La plupart des commandes d'administration d'Upstart et de System V ont été modifiées pour fonctionner avec Systemd. Systemd se renomme en init au moment du démarrage. Un fichier /sbin/init existe et pointe par un lien symbolique vers /bin/systemd.

Fichiers de configuration Systemd : Fichiers d'unité

La configuration de Systemd se compose de fichiers d'unité. Chaque fichier d'unité représente une ressource système. Alors que les deux autres systèmes d'initialisation (à savoir System V et Upstart) étaient chargés de gérer les services d'un système Linux, Systemd gère non seulement les démons de service, mais aussi d'autres types de ressources système telles que les chemins du système d'exploitation des périphériques, les sockets, les points de montage, etc. Les fichiers d'unité stockent des informations sur la ressource.

Chaque fichier d'unité représente une ressource système particulière avec un style de nommage de type service_name.unit_type. Cela signifie que vous trouverez des fichiers comme home.mount, dbus.service, sshd.socket, etc. Les fichiers d'unité sont de simples fichiers texte avec une syntaxe déclarative facile à comprendre et à modifier.

Structure des répertoires

L'emplacement principal des fichiers d'unité natifs est le répertoire /lib/systemd/system/. Les fichiers d'unité que vous créez ou ceux créés sur mesure par les administrateurs système, ainsi que d'autres fichiers d'unité natifs modifiés, sont stockés dans le répertoire /etc/systemd/system.

Si un fichier d'unité portant le même nom existe à la fois dans les répertoires /lib/systemd/system/ et /etc/systemd/system, systemd utilisera celui situé sous le répertoire /etc.

Lorsque vous activez un service pour qu'il démarre au démarrage ou à tout autre niveau d'exécution (target/runlevel), un lien symbolique est créé pour ce fichier d'unité de service sous les répertoires appropriés dans /etc/systemd/system. Les fichiers d'unité dans le répertoire /etc/systemd/system ne sont que des liens symboliques vers les fichiers portant un nom similaire dans le répertoire /lib/systemd/system.

Séquence d'initialisation Systemd : Unités cibles (Target Units)

Les unités cibles sont des types uniques de fichiers d'unité généralement suffixés par .target. Les unités cibles diffèrent des autres types de fichiers d'unité car elles ne représentent pas une ressource particulière. Au lieu de cela, elles représentent l'état de l'ensemble du système à un moment donné.

Pour y parvenir, les unités cibles regroupent et lancent plusieurs fichiers d'unité qui font partie d'un état particulier. Bien que les cibles Systemd et les niveaux d'exécution (runlevels) de System V puissent être comparés de manière lâche, ils ne sont pas identiques. Un fichier d'unité cible a un nom au lieu d'un numéro. Par exemple, vous trouverez quelque chose comme multi-user.target au lieu du runlevel 3 ou reboot.target au lieu du runlevel 6. Un système Linux peut démarrer avec multi-user.target. Dans ce cas, cela amène essentiellement le serveur au runlevel 2, 3 ou 4, ce qui démarre le système en mode texte multi-utilisateur avec le réseau activé.

La différence réside dans la manière dont il amène le serveur à ce niveau. System V lance les services de manière séquentielle. D'un autre côté, au démarrage du système, systemd vérifie si d'autres services ou ressources existent et détermine leur ordre de chargement.

Une autre différence entre les unités cibles de systemd et les niveaux d'exécution de System V est qu'une distribution Linux utilisant System V n'existera que dans un seul niveau d'exécution. Si vous modifiez le niveau d'exécution, elle basculera simplement vers ce nouveau niveau d'exécution et y restera. D'un autre côté, les fichiers d'unités cibles peuvent être inclusifs. De plus, l'activation d'une unité cible garantit que d'autres unités cibles sont chargées dans le cadre de celle-ci. Par exemple, si vous démarrez un système Linux avec une interface graphique, il aura le graphical.target activé. Cela garantit à son tour automatiquement que multi-user.target est également chargé et activé.

Voici un tableau comparant les niveaux d'exécution et les cibles.

Niveau d'exécution (System V)	Unités cibles (systemd)
niveau d'exécution 0	poweroff.target
niveau d'exécution 1	rescue.target
niveau d'exécution 2,3,4	multi-user.target
niveau d'exécution 5	graphical.target
niveau d'exécution 6	reboot.target

Systemd default.target

Dans systemd, default.target est l'équivalent du niveau d'exécution par défaut dans System V. Nous avons vu que le niveau d'exécution par défaut dans System V était défini dans le fichier inittab. Dans systemd, nous avons le fichier default.target. Le fichier cible par défaut est stocké dans le répertoire /etc/systemd/system. Il s'agit d'un lien symbolique vers l'un des fichiers d'unités cibles sous /lib/systemd/system. Changer la cible par défaut signifie simplement recréer un lien symbolique et modifier le niveau d'exécution du système.

Dans System V, l'inittab spécifiait dans quel répertoire Linux trouverait les scripts d'initialisation. Il pouvait s'agir de n'importe lequel des répertoires rc comme expliqué précédemment. D'un autre côté, la cible par défaut de systemd détermine les unités de ressources à charger au moment du démarrage. Toutes les unités définies sont chargées. Cependant, elles ne sont pas toutes chargées en parallèle, et elles ne sont pas toutes chargées de manière séquentielle. Le chargement de l'unité de ressource dépend des autres ressources qu'elle veut ou requiert.

Dépendances Systemd : Wants et Requires

Dans cette section, nous verrons comment Systemd gère les dépendances. Nous avons vu qu'avec Upstart, le chargement parallèle des services est possible lors de l'utilisation de fichiers de configuration. Nous avons également vu comment System V utilise les niveaux d'exécution pour déterminer quel service démarrer automatiquement ou s'il faut attendre qu'un autre service ou ressource soit disponible. De même, les services Systemd peuvent être configurés pour se charger dans une ou plusieurs cibles, ou pour attendre qu'un autre service ou ressource soit disponible.

Dans Systemd, un fichier d'unité qui requiert une autre unité ne démarrera pas tant que l'unité requise n'aura pas été chargée et ne sera pas devenue active. Si l'unité requise ne parvient pas à se charger alors que la première unité est active, la première unité s'arrêtera.

Ce comportement garantit la stabilité du système. Un service qui requiert une ressource particulière (par exemple, un port) pour être disponible et actif peut ainsi être mis en attente jusqu'à ce que la ressource soit disponible (c'est-à-dire que le port soit ouvert).

En revanche, une unité qui veut une autre unité n'impose pas de telles restrictions. Elle ne s'arrêtera pas si l'unité voulue s'arrête alors que l'unité appelante est toujours active. Par exemple, certains services non essentiels en mode graphical-target.

Exemple Systemd

Voyons comment nous pouvons configurer le comportement d'un service sous systemd.

Étape 1 : Connectez-vous à votre instance VPS

Nous utiliserons MySQL comme service réel et CentOS 7 comme serveur. Pour suivre les étapes de manière pratique et comprendre les concepts, connectez-vous à votre VPS CentOS 7 ou créez-en un sur CloudSigma. Un VPS exécutant une distribution CentOS 7, Debian 7 ou 8, ou Ubuntu 15 ou plus récente convient pour cette section car ils sont tous équipés de systemd. Connectez-vous à l'aide de la commande ssh ou, si vous êtes sous Windows, utilisez PuTTY :

Étape 2 : Examinez le fichier default.target et ses dépendances

La séquence de démarrage de Systemd suit une longue chaîne de dépendances dont nous discuterons en détail dans cette section.

• default.target

Le fichier default.target contrôle les services qui démarrent lors d'un démarrage normal. Vous pouvez lister le fichier d'unité cible par défaut à l'aide de la commande suivante :

La sortie affiche quelque chose comme la capture d'écran ci-dessous :

La capture d'écran montre que la cible par défaut pointe par un lien symbolique vers le fichier multi-user.target dans le répertoire /lib/systemd/system/ répertoire. Cela signifie que, par défaut, le système démarrera sous multi-user.target, équivalent au runlevel 3.

• multi-user.target.wants

Pour voir tous les services requis par le fichier multi-user.target, entrez la commande suivante :

La sortie contient beaucoup de lignes, en voici un extrait :

Comme le montre la sortie, ce sont des liens symboliques pointant vers les fichiers d'unité réels dans le /lib/systemd/system/ répertoire. Nous avons mis en évidence mysqld.service pour vous signaler qu'il fait également partie de multi-user.target. Si vous souhaitez confirmer si un certain service est configuré pour le démarrage, vous pouvez modifier la commande pour ce fichier. Par exemple, nous pouvons filtrer les sorties pour trouver le démon mysql ou cron à l'aide des commandes suivantes :

La sortie affichera :

Pour filtrer le résultat pour le démon cron, entrez la commande suivante :

La sortie affichera :

En dehors de multi-user.target, d'autres types de cibles existent, par exemple system-update.target ou basic.target.

Entrez la commande suivante pour voir de quelles cibles dépend la cible multi-user :

La sortie montre :

Cela signifie que basic-target doit d'abord se charger pour que le système démarre en mode multi-user.target.

• basic-target

Entrez la commande suivante pour voir quelles autres cibles basic.target requiert :

La sortie affichera :

• sysinit.target

Vous pouvez exécuter la commande suivante pour voir s'il y a des cibles requises pour sysinit.target. La syntaxe de la commande est la même. Vous pouvez continuer à la modifier pour voir quelles unités de cible sont requises par une autre unité de cible au fur et à mesure. Voici la commande :

La sortie affichera qu'il n'y a pas d'unités requises pour sysinit.target. Nous pouvons vérifier s'il y a d'autres services et cibles souhaités par sysinit.target en utilisant la commande suivante :

La sortie montre une longue liste de services et de cibles souhaités par sysinit.target. Vous pouvez voir une partie de la sortie ci-dessous :

Lors de l'initialisation du système avec system4, le système ne reste pas dans une seule cible. Au lieu de cela, il charge les services de manière dépendante au fur et à mesure qu'il passe d'une cible à une autre.

Étape 3 : Examiner un fichier d'unité

Voyons à quoi ressemble un fichier d'unité. Nous avions utilisé le fichier d'unité du service MySQL dans la première partie de ce tutoriel, et nous allons l'utiliser à nouveau. Cependant, nous pouvons également examiner un autre fichier d'unité de service – le fichier d'unité sshd. Entrez la commande suivante pour ouvrir le fichier de configuration sshd :

Ci-dessous se trouve une capture d'écran montrant les lignes du fichier :

Comme vous pouvez le voir, les blocs de code délimités dans le fichier le rendent facile à comprendre et à modifier si nécessaire. Voici quelques directives importantes à comprendre :

• After – la clause After indique au système de ne charger le service qu'après le chargement des cibles et services spécifiés. Dans ce cas, le service SSHD se chargera après le chargement de la cible réseau et du service keygen.
• Wants – la clause Wants indique quelles cibles souhaitent ce service. Dans ce cas, le ssh-keygen.service souhaite le sshd.service. Cependant, si sshd échoue ou plante, cela n'arrêtera pas le ssh-keygen.service.

Appuyez sur Ctrl + X pour fermer l'éditeur.

Étape 4 : Tester le comportement au démarrage du service MySQL lors du démarrage du système

Dans cette section, nous allons vous montrer comment vous pouvez modifier et tester le comportement du service MySQL au démarrage du système. Dans la section précédente, nous avons vu que le mysqld.service est souhaité par multi-user.target. Par conséquent, il démarrera automatiquement au démarrage.

Vous pouvez désactiver le service en exécutant la commande suivante :

L'exécution de la commande montre que le lien symbolique mysql est supprimé du répertoire /etc/systemd/system/multi-user.target.wants/. Afin de tester cela, exécutez la commande suivante pour vérifier si MySQL est toujours souhaité par multi-user.target:

La commande ne renvoie rien. Si vous essayez de redémarrer le serveur et de vérifier le statut de MySQL, il ne sera pas en cours d'exécution, ce qui signifie qu'il n'a pas démarré automatiquement au démarrage.

Maintenant, réactivez le service à l'aide de la commande :

La sortie affichera un lien symbolique. Si vous redémarrez votre serveur, MySQL devrait démarrer automatiquement. L'activation d'un service Systemd crée un lien symbolique dans le répertoire wants de la cible par défaut. La désactivation d'un service Systemd supprime le lien symbolique du wants répertoire.

Étape 5 : Tester le comportement au démarrage du service MySQL après un plantage du service

Par défaut, le service MySQL démarrera automatiquement en cas de plantage. Nous pouvons désactiver ce comportement dans le fichier de configuration Systemd pour MySQL. Tout d'abord, jetons un coup d'œil au fichier. Entrez la commande suivante pour ouvrir le fichier :

La capture d'écran ci-dessous montre la sortie :

La valeur de la directive Restart est définie sur on-failure. Cela signifie que le service MySQL redémarrera après des codes de sortie incorrects, un délai d'attente ou des signaux incorrects. Vous trouverez ci-dessous un tableau présentant certains des paramètres de redémarrage de la page de manuel.

Paramètres de redémarrage/Causes de sortie	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
code de sortie propre ou signal		X	X
Code de sortie incorrect		X		X
Signal incorrect		X		X	X	X
Délai d'attente		X		X	X
Watchdog		X		X	X		X

Les deux directives importantes dans un fichier d'unité Systemd sont Restart et RestartSec. Elles contrôlent le comportement du service en cas de plantage. Restart spécifie quand le service doit redémarrer, et RestartSec spécifie le temps d'attente avant de redémarrer après un plantage. Pour désactiver le comportement de redémarrage, commentez la directive Restart en ajoutant un # au début de la ligne comme indiqué :

Maintenant, rechargez le démon système, puis rechargez le service mysqld à l'aide des commandes suivantes :

Ensuite, exécutez la commande suivante pour trouver le PID principal (Main PID) du service MySQL :

Le PID principal pour notre test était 23809. Notez le vôtre pour l'utiliser dans la commande suivante. À l'aide de la commande kill -9, simulez un plantage en tuant le processus. N'oubliez pas non plus de remplacer par le numéro de processus que vous avez obtenu lors de votre test :

Si vous exécutez la commande qui vérifie le statut de MySQL, vous constaterez qu'il n'est pas actif et qu'il n'a pas réussi à redémarrer :

Il restera dans l'état d'échec tant que la directive Restart sera commentée dans le fichier de configuration mysqld.service . Cela simule un plantage où un service s'arrête et ne redémarre pas.

Pour réactiver le service, vous pouvez modifier le fichier de configuration mysqld.service , décommenter la directive Restart, puis enregistrer et fermer. Comme vous l'avez fait précédemment, rechargez le démon et redémarrez le service. Cela ramène le service à sa configuration initiale, et il peut désormais démarrer automatiquement après un plantage. Enfin, c'est tout pour la configuration d'un service pour qu'il démarre automatiquement après un plantage. Si vous souhaitez configurer des services pour qu'ils démarrent automatiquement après un plantage, il vous suffit d'ajouter la directive Restart , (et si vous le souhaitez, vous pouvez également ajouter la directive RestartSec), sous la section [Service] du fichier d'unité de service.

Conclusion

Dans ce tutoriel, nous avons vu comment Linux gère les services lors du démarrage ou après un plantage. Pour comprendre le processus d'initialisation du système Linux, nous avons abordé les trois systèmes d'initialisation utilisés par Linux : System V, Upstart et Systemd. Nous avons discuté de leur évolution et de la manière dont chaque processus init fonctionne par rapport au démarrage automatique d'un service après un redémarrage ou un plantage du système.

Comme les démons init et les distributions Linux ont évolué au fil du temps, n'oubliez pas de vérifier la version de la distribution Linux que vous utilisez afin de savoir quel démon init votre système prend en charge nativement.

Les applications natives Linux et la plupart des applications tierces démarrent déjà automatiquement après un démarrage ou un plantage du système, vous n'aurez donc rien à faire. Les connaissances de ce tutoriel sont cruciales lorsque vous configurez le comportement de démarrage et de relance de vos propres services personnalisés, ou lors du dépannage de services qui plantent constamment.

Bonne informatique !