Comment configurer un service Linux pour qu’il démarre automatiquement après un crash ou un redémarrage - Partie 2: Référence

Dans cette deuxième partie du didacticiel sur le démarrage automatique des services Linux, nous allons revenir en arrière et expliquer les processus init plus en détail. Vous devez bien comprendre comment ils contrôlent le comportement de démarrage d’un démon.

Dans lesfirst part de cette série de didacticiels, nous avons partagé quelques exemples pratiques utilisant MySQL pour savoir comment activer un service Linux pour démarrer automatiquement après un crash ou un redémarrage.

Nous avons vu comment faire cela à partir de trois modesinit différents: System V, Upstart et systemd. Lisez lesfirst tutorial pour un rappel sur les distributions qui utilisent quel système init par défaut.

Dans ce tutoriel, nous allons revenir en arrière et expliquer pourquoi nous avons exécuté les commandes et modifié les fichiers de configuration que nous avons créés. Nous allons commencer par le démon init System V. Nous verrons également pourquoi il a été remplacé au fil du temps par de nouveaux modes init.

Pour suivre ce didacticiel, vous aurez besoin des trois gouttelettes DigitalOcean que vous avez crééesbefore.

Nous avons eu:

Nous vous recommandons de revenir à la partie 1 de cette série et de créer les gouttelettes en premier.

En outre, vous devez être l'utilisateur root ou disposer des privilèges sudo sur les serveurs. Pour comprendre le fonctionnement des privilèges sudo, consultezthis DigitalOcean tutorial about sudo.

Vous ne devez exécuter aucune commande, requête ou configuration de ce didacticiel sur un serveur Linux de production.

Unrunlevel représente l'état actuel d'un système Linux.

Le concept vient de System V init, où le système Linux démarre, initialise le noyau, puis entre un (et un seul) niveau d'exécution.

Par exemple, un niveau d'exécution peut être l'état d'arrêt d'un serveur Linux, un mode mono-utilisateur, le mode de redémarrage, etc. Chaque mode dictera quels services peuvent être exécutés dans cet état.

Certains services peuvent s'exécuter dans un ou plusieurs niveaux d'exécution, mais pas dans d'autres.

Les niveaux d'exécution sont indiqués par des chiffres simples et peuvent avoir une valeur comprise entre 0 et 6. La liste suivante indique la signification de chacun de ces niveaux:

Les niveaux d'exécution 2, 3 et 4 varient selon la distribution. Par exemple, certaines distributions Linux n’implémentent pas le niveau d’exécution 4, d’autres le font. Certaines distributions distinguent clairement ces trois niveaux. En général, les niveaux d'exécution 2, 3 ou 4 désignent un état dans lequel Linux a démarré en mode texte multi-utilisateurs, activé par le réseau.

Lorsque nous activons le démarrage automatique d’un service, nous l’ajoutons à un niveau d'exécution. Dans System V, le système d'exploitation démarrera avec un niveau d'exécution particulier. et, au démarrage, il essaiera de démarrer tous les services associés à ce niveau d'exécution.

Les niveaux d’exécution deviennenttargets dans systemd, dont nous parlerons dans la section systemd.

init est le premier processus qui démarre dans un système Linux après le démarrage de la machine et le chargement du noyau en mémoire.

Entre autres choses, il décide comment un processus utilisateur ou un service système doit être chargé, dans quel ordre et s'il doit démarrer automatiquement.

Chaque processus sous Linux a un ID de processus (PID) etinit a un PID de 1. C’est le parent de tous les autres processus qui apparaissent par la suite lorsque le système est mis en ligne.

Histoire d'Init

Comme le comportement de Linux a évolué, le comportement du démon init a également évolué. Initialement, Linux avait démarré avec System V init, le même qui était utilisé sous UNIX. Depuis lors, Linux a implémenté le démon initUpstart (créé par Ubuntu) et maintenant le démon initsystemd (implémenté pour la première fois par Fedora).

La plupart des distributions Linux ont progressivement migré hors de System V ou sur le point de le supprimer progressivement, en ne le conservant que pour des raisons de compatibilité ascendante. FreeBSD, une variante d'UNIX, utilise une implémentation différente de System V, appelée init BSD. Les anciennes versions de Debian utilisent aussi SysVinit.

Chaque version du démon init a différentes manières de gérer les services. La raison de ces changements est la nécessité d’un outil de gestion des services robuste, capable de gérer non seulement les services, mais également les périphériques, les ports et d’autres ressources; cela chargerait les ressources en parallèle et cela se remettrait gracieusement après un crash.

System V utilise un fichierinittab, que les méthodes d'initialisation ultérieures comme Upstart ont conservées pour une compatibilité ascendante.

Parcourons la séquence de démarrage de System V:

Ainsi, lorsque le démon init trouve les scripts d’initialisation qu’il doit exécuter pour un niveau d’exécution donné, il recherche essentiellement les services dont il a besoin pour démarrer. Ces scripts d’initialisation permettent de configurer le comportement de démarrage de services individuels, comme ce fut le cas pour MySQL dans le premier tutoriel.

Ensuite, regardons les scripts d’initialisation en détail.

Un script init est ce qui contrôle un service spécifique, comme MySQL Server, dans System V.

Les scripts d’initialisation des services sont fournis par le fournisseur de l’application ou fournis avec la distribution Linux (pour les services natifs). Nous pouvons également créer nos propres scripts d'initialisation pour des services créés sur mesure.

Lorsqu'un processus ou un service tel que MySQL Server démarre, son fichier de programme binaire doit être chargé en mémoire.

Selon la configuration du service, ce programme devra peut-être continuer à s'exécuter en arrière-plan (et accepter les connexions client). Le travail de démarrage, d’arrêt ou de rechargement de cette application binaire est géré par le script init du service. Il s’appelle le script init car ilinitializesest le service.

Dans System V, un script init est un script shell.

Les scripts d'initialisation sont également appelés scriptsrc (commande d'exécution).

Comme nous permettons à un service de démarrer automatiquement au démarrage, nous modifions en réalité le comportement init.

Ainsi, par exemple, lorsque nous permettons à un service de démarrer automatiquement au niveau d'exécution 3, dans les coulisses, le processus crée les liens appropriés dans le répertoire/etc/rc3.d.

Si cela semble déroutant, ne vous inquiétez pas, nous verrons ce que tout cela signifie dans une minute.

Nous allons revenir à notre exemple de service MySQL, cette fois avec plus de théorie.

[[step-1 -—- logging-in-to-debian-droplet]] === Étape 1 - Connexion à Debian Droplet

Pour les besoins de cette partie du didacticiel, nous allons revenir à la gouttelette Debian 6 créée dans la première partie. Utilisez la commande SSH pour vous connecter au serveur (les utilisateurs Windows peuvent se connecter à l’aide d’un outil tel que PuTTy).

[[step-2 -—- looking-at-inittab]] === Étape 2 - Regard sur inittab

Exécutez la commande suivante pour voir le contenu du fichierinittab:

Le résultat devrait ressembler à ceci:

Le champ 2 après le champ id indique que le système est configuré pour démarrer avec le niveau d'exécution 2. C’est le niveau d’exécution par défaut. Dans ce cas, Debian désigne 2 en mode texte multi-utilisateur. Si vous exécutez la commande suivante:

la sortie confirme ceci:

[[step-3 -—- looking-at-the-rc-directory]] === Étape 3 - Consultation des répertoires rc

Exécutez la commande suivante pour répertorier les répertoiresrc. Vous devriez voir qu'il y en a six:

Etant donné que le système démarre au niveau d'exécution 2 (init par défaut du fichier inittab), les scripts du répertoire/etc/rc2.d s'exécuteront au démarrage du système.

Listez le contenu de ce répertoire:

Cela montre que les fichiers ne sont que des liens symboliques, chacun pointant vers des fichiers de script sous /etc/init.d:

Nous pouvons voir qu'il n'y a pas de scripts K ici, seulement des scripts S (start). Les scripts démarrent des services connus tels quersyslog,cron oussh.

Rappelez-vous que les deux chiffres après S déterminent l'ordre de démarrage: par exemple, rsyslog démarre avant le démon cron. Nous pouvons également voir que MySQL est répertorié ici.

[[step-4 -—- looking-at-an-init-script]] === Étape 4 - Consultation d'un script d'initialisation

Nous savons maintenant que lorsqu'un service compatible System V est installé, il crée un script shell sous le répertoire/etc/init.d. Vérifiez le script shell pour MySQL:

Pour voir à quoi ressemble le script de démarrage, lisez le fichier:

A la sortie, vous verrez qu’il s’agit d’un gros script bash.

[[step-5 -—- using-chkconfig-or-sysv-rc-conf]] === Étape 5 - Utilisation de chkconfig ou sysv-rc-conf

Dans les distributions basées sur RHEL comme CentOS, une commande appeléechkconfig peut être utilisée pour activer ou désactiver un service dans System V. Il peut également répertorier les services installés et leurs niveaux d'exécution.

[.Remarque]##

La syntaxe pour vérifier l'état d'un service pour tous les niveaux d'exécution sur un système CentOS serait:

Aucun de ces utilitaires n'est livré avec Debian de manière native (update-rc.d installe ou supprime des services des niveaux d'exécution uniquement). Nous pouvons cependant installer un outil personnalisé appelésysv-rc-conf pour nous aider à gérer les services.

Exécutez la commande suivante pour installersysv-rc-conf:

Une fois l’outil installé, exécutez simplement cette commande pour voir le comportement du niveau d’exécution de divers services:

La sortie sera une jolie fenêtre graphique comme montré ci-dessous. À partir de là, nous pouvons voir clairement quels services sont activés pour quels niveaux d'exécution (marqués d'un X).

En utilisant les touches fléchées etSPACEBAR, nous pouvons activer ou désactiver un service pour un ou plusieurs niveaux d'exécution.

Pour l'instant, quittez l'écran en appuyant surQ.

[[step-7 -—- testing-mysql-startup-behavior-at-boot]] === Étape 7 - Test du comportement de démarrage de MySQL au démarrage

Comme vous pouvez le voir sur la capture d'écran de la section précédente et sur nos tests de la partie 1 du didacticiel, MySQL est actuellement activé sur les niveaux d'exécution 2-5.

Exécutez la commande ci-dessous pourdisable le service MySQL:

Maintenant, lancez la commande:

La sortie doit montrer que le lien symbolique de/etc/rc2.d vers/etc/init.d/mysql a changé enK:

En d'autres termes, MySQL ne démarrera plus au niveau d'exécution par défaut (2).

C’est ce qui se passe dans les coulisses de System V lorsque nous activons et désactivons un service. Tant qu'il y a un script S dans le répertoire de niveau d'exécution par défaut du service, init démarrera ce service lors du démarrage.

Activez à nouveau le service:

[[step-8 -—- testing-mysql-start-up-behavior-on-crash]] === Étape 8 - Test du comportement de démarrage de MySQL en cas de crash

Voyons comment System V gère les pannes de service.

Rappelez-vous que nous avons modifié le fichier/etc/inittab dans la partie 1 de ce tutoriel, pour permettre à MySQL de démarrer automatiquement après un crash. Nous avons ajouté la ligne suivante:

/etc/inittab

C'était pour s'assurer que le service MySQL démarre après un crash. Pour vérifier si cela se produit, redémarrez d'abord le serveur:

Une fois le serveur revenu, connectez-vous à SSH et vérifiez les ID de processus MySQL comme auparavant:

Notez les ID de processus pourmysqld_safe etmysqld. Dans notre cas, il s’agissait respectivement de 895 et 1019:

Tuez à nouveau les processus avec un commutateur-9 (remplacez les PID par ceux de votre système Debian):

Attendez cinq minutes environ, puis exécutez la commande:

La sortie indiquera que le service MySQL est en cours d’exécution, en commençant par cette ligne:

Si vous exécutez à nouveau la commandeps -ef | grep mysql, vous verrez que les processusmysqld_safe etmysqld ont démarré.

Essayez de tuer le processus plusieurs fois de plus, et dans chaque cas, il devrait réapparaître après cinq minutes.

C'est la raison pour laquelle nous avons ajouté cette ligne supplémentaire dans/etc/inittab: c'est ainsi que vous configurez un service System V pour qu'il réapparaisse en cas de plantage. Il y a une explication détaillée de la syntaxe de cette ligne enPart 1.

Cependant, faites attention lorsque vous ajoutez un redémarrage automatique pour un service: si un service tente de se réapparaître et échoue plus de dix fois en deux minutes, Linux le désactive pendant cinq minutes. Ainsi, le système reste stable et ne manque pas de ressources informatiques.

Si vous recevez un message dans la console à propos de cet événement ou si vous le trouvez dans les journaux système, vous saurez qu’il ya un problème avec l’application qui doit être corrigée, car elle continue de planter.

Classic SysVinit faisait partie des distributions Linux traditionnelles depuis longtemps avant l’arrivée de Upstart.

Avec la croissance du marché Linux, les méthodes sérialisées de chargement des travaux et des services sont devenues de plus en plus longues et complexes. Dans le même temps, alors que de plus en plus de dispositifs modernes, tels que des supports de stockage enfichables à chaud, proliféraient sur le marché, SysVinit s'est avéré incapable de le gérer rapidement.

La nécessité d'un chargement plus rapide du système d'exploitation, d'un nettoyage en douceur des services bloqués et d'une dépendance prévisible entre les services système ont fait apparaître la nécessité d'un meilleur gestionnaire de services. Les développeurs d’Ubuntu ont proposé un autre moyen d’initialisation, le démon Upstart.

Upstart init est meilleur que System V init de plusieurs manières:

Upstart permet d'associer plusieursevents à un service. Cette architecture basée sur les événements permet à Upstart de traiter la gestion de services de manière flexible.

Chaque événement peut déclencher un script shell qui s’occupe de cet événement.

Les événements à venir incluent:

Entre ces événements, un service peut être dans un nombre destates, comme:

Upstart peut également prendre des mesures pour chacun de ces états, créant ainsi une architecture très flexible.

Comme System V, Upstart exécute également le script/etc/init.d/rc au démarrage. Ce script exécute normalement tous les scripts d'initialisation System V.

Upstart regarde également sous le répertoire/etc/init et exécute les commandes shell dans chaque fichier de configuration de service.

Upstart utilise des fichiers de configuration pour contrôler les services.

Upstart n'utilise pas les scripts Bash comme System V. Au lieu de cela, Upstart utilise des fichiersservice configuration avec une norme de dénomination deservice_name.conf.

Les fichiers ont un contenu en texte brut avec différentes sections, appeléesstanzas. Chaque strophe décrit un aspect différent du service et son comportement.

Différentes strophes contrôlent différents événements pour le service, commepre-start,start,pre-stop oupost-stop.

Les strophes elles-mêmes contiennent des commandes shell. Par conséquent, il est possible d’appeler plusieurs actions pour chaque événement pour chaque service.

Chaque fichier de configuration spécifie également deux choses:

Voyons comment Upstart gère à nouveau le serveur MySQL, cette fois avec davantage de connaissances de base.

[[step-1 -—- logging-in-to-ubuntu-droplet]] === Étape 1 - Connexion à Ubuntu Droplet

Retournez à la Droplet Ubuntu 14.04 créée dans la première partie.

Utilisez la commande SSH pour vous connecter au serveur (les utilisateurs Windows peuvent se connecter à l’aide d’un outil tel que PuTTy).

[[step-2 -—- looking-at-the-init-and-rc-directory]] === Étape 2 - Consultation des répertoires init et rc

La plupart des fichiers de configuration d'Upstart se trouvent dans le répertoire/etc/init. C'est le répertoire que vous devez utiliser lors de la création de nouveaux services.

Une fois connecté au serveur, exécutez la commande suivante:

Le résultat affichera un grand nombre de fichiers de configuration de service, écran par écran. Ce sont des services qui s'exécutent nativement sous Upstart:

Appuyez surQ pour quitterless.

Comparez cela avec les services natifs System V init du système:

Il n'y aura qu'une poignée:

[[step-3 -—- looking-at-an-upstart-file]] === Étape 3 - Consultation d'un fichier Upstart

Nous avons déjà vu le fichiermysql.conf dans la première partie de ce didacticiel. Alors ouvrons un autre fichier de configuration: celui du démon cron.

Comme vous pouvez le constater, il s’agit d’un fichier de configuration assez simple pour le démon cron:

/etc/init/cron.conf

Les champs importants dont il faut tenir compte ici sontstart on,stop on etrespawn.

La directivestart on indique à Ubuntu de démarrer le démoncrond lorsque le système entre aux niveaux d'exécution 2, 3, 4 ou 5. 2, 3 et 4 sont des modes texte multi-utilisateurs avec la mise en réseau activée et 5 est un mode graphique multi-utilisateurs. Le service ne fonctionne sur aucun autre niveau d'exécution (comme 0,1 ou 6).

La directivefork indique à Upstart que le processus doit se détacher de la console et s'exécuter en arrière-plan.

Vient ensuite la directiverespawn. Cela indique au système que cron devrait démarrer automatiquement s'il se bloque pour une raison quelconque.

Quittez l'éditeur sans apporter de modifications.

Le fichier de configuration cron est un fichier de configuration assez petit. Le fichier de configuration MySQL est structurellement similaire au fichier de configuration cron; il a également des strophes pour démarrer, arrêter et réapparaître. En outre, il comporte également deux blocs de script pour les événements de pré-démarrage et de post-démarrage. Ces blocs de code indiquent au système ce qu’il faut exécuter lorsque le processus mysqld est en cours ou est déjà en cours.

Pour une aide pratique sur la création de votre propre fichier Upstart, consultezthis tutorial about Upstart.

[[step-4 -—- testing-mysql-startup-behavior-at-boot]] === Étape 4 - Test du comportement de démarrage de MySQL au démarrage

Nous savons que l'instance MySQL sur notre serveur Ubuntu 14.04 est configurée pour démarrer automatiquement au démarrage par défaut. Voyons comment nous pouvons le désactiver.

Dans Upstart, la désactivation d'un service dépend de l'existence d'un fichier sous/etc/init/ appeléservice_name.override. Le contenu du fichier doit être un simple mot:manual.

Pour voir comment nous pouvons utiliser ce fichier pour désactiver MySQL, exécutez la commande suivante pour créer ce fichier de remplacement pour MySQL:

Ajouter cette seule ligne:

/etc/init/mysql.override

Enregistrez vos modifications.

Ensuite, redémarrez le serveur:

Une fois le serveur remis en ligne, vérifiez l'état du service.

Le résultat devrait être:

Cela signifie que MySQL n’a pas démarré.

Vérifiez si la directivestart a changé dans le fichier de configuration du service MySQL:

Ce devrait toujours être le même:

Cela signifie que vérifier le fichier.conf dans le répertoireinit n'est pas le seul facteur pour voir si le service démarrera aux niveaux appropriés. Vous devez également vous assurer que le fichier.override n’existe pas.

Pour activer MySQL, supprimez le fichier de remplacement et redémarrez le serveur:

Une fois le serveur redémarré, connectez-vous à distance.

L'exécution de la commandesudo initctl status mysql montrera que le service a démarré automatiquement.

[[step-5 -—- testing-mysql-startup-behavior-on-crash]] === Étape 5 - Test du comportement de démarrage de MySQL en cas de crash

Par défaut, MySQL apparaît automatiquement après un crash.

Pour arrêter MySQL, ouvrez le fichier de configuration du service/etc/init/mysql.conf:

Mettez en commentaire les deux directivesrespawn.

/etc/init/mysql.conf

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

Nous arrêtons et démarrons explicitement le service car notre test a montré queinitctl restart ouinitctl reload ne fonctionnerait pas ici.

La deuxième commande de démarrage du service montre le PID que MySQL a commencé avec:

Notez le PID pour votre instance de MySQL. Si vous plantez le processusmysql maintenant, il ne sera pas lancé automatiquement. Tuez l'ID de processus (en le remplaçant par votre propre numéro):

Maintenant, vérifiez son statut:

Essayez de trouver le statut plusieurs fois en laissant un peu de temps entre chaque. Dans tous les cas, MySQL sera toujours arrêté. Cela se produit parce que le fichier de configuration du service ne contient plus les directivesrespawn.

Part 1 du tutoriel a une explication plus détaillée des directivesrespawn.

[.Remarque]##

Quand voudriez-vousnot qu'un service Upstart apparaisse après un redémarrage ou une panne?

Supposons que vous ayez mis à jour votre noyau Linux ou inséré le dernier correctif. Vous ne voulez aucun drame; vous venez du serveur à venir. Vous pouvez largement éliminer les risques en désactivant le démarrage automatique pour tout processus Upstart.

Si votre service démarre mais continue de planter, vous pouvez d'abord l'arrêter, puis modifier également son comportement de réapparition.

Le dernier démon Linux init est systemd. En fait, c’est plus qu’un démon init: systemd est un tout nouveau framework qui englobe de nombreux composants d’un système Linux moderne.

Une de ses fonctions est de fonctionner comme unsystem and service manager pour Linux. En cette qualité, l'un des éléments contrôlés par systemd est le comportement d'un service en cas de panne ou de redémarrage de la machine. Vous pouvez en savoir plus sursystemd’s systemctl here.

compatible avec les commandes et les scripts d’initialisation System V de Systemd. Cela signifie que tout service System V fonctionnera également sous systemd. Cela est possible car la plupart des commandes administratives Upstart et System V ont été modifiées pour fonctionner sous systemd.

En fait, si nous exécutons la commandeps -ef | grep systemd dans un système d’exploitation qui la prend en charge, nous ne verrons rien, carsystemd se renomme eninit au démarrage. Il existe un fichier/sbin/init qui est un lien symbolique vers/bin/systemd.

Au cœur de systemd se trouventunit files. Chaque fichier d'unité représente une ressource système. La principale différence entre systemd et les deux autres méthodes init est qu’il est responsable de l’initialisation non seulement des démons de service, mais également d’autres types de ressources telles que les sockets, les chemins du système d’exploitation du périphérique, les points de montage, les sockets, etc. Une ressource peut être n'importe laquelle.

Les informations sur la ressource sont conservées dans le fichier d'unité.

Chaque fichier d'unité représente une ressource système spécifique et a un style de dénomination deservice name.unit type.

Donc, nous aurons des fichiers commedbus.service,sshd.socket ouhome.mount.

Comme nous le verrons plus tard, les fichiers d'unité de service sont de simples fichiers texte (comme les fichiers Upstart.conf) avec une syntaxe déclarative. Ces fichiers sont assez faciles à comprendre et à modifier.

Un type spécial de fichier d'unité est untarget unit.

Un nom de fichier d'unité cible est suffixé par.target. Les unités cibles sont différentes des autres fichiers d’unités car elles ne représentent aucune ressource en particulier. Ils représentent plutôt l'état du système à tout moment.

Pour ce faire, les unités cibles regroupent et lancent plusieurs fichiers d’unités qui devraient faire partie de cet état. systemdtargets peut donc être vaguement comparé aux niveaux d'exécution System V, bien qu'ils ne soient pas les mêmes.

Chaque cible a un nom au lieu d'un nombre. Par exemple, nous avonsmulti-user.target au lieu du niveau d'exécution 3 oureboot.target au lieu du niveau d'exécution 6.

Lorsqu'un serveur Linux démarre avec, disons,multi-user.target, il amène essentiellement le serveur au niveau d'exécution 2, 3 ou 4, qui est le mode texte multi-utilisateur avec mise en réseau activée.

La différence réside dans la manière dont il met le serveur à niveau. Contrairement à System V, Systemd n'active pas les services de manière séquentielle. En cours de route, il peut vérifier l’existence d’autres services ou ressources et décider de l’ordre de leur chargement. Cela permet aux services de se charger en parallèle.

Une autre différence entre les unités cibles et les niveaux d'exécution réside dans le fait que, dans System V, un système Linux ne peut exister que dans un seul niveau d'exécution. Vous pouvez changer le niveau d'exécution, mais le système n'existe que dans ce nouveau niveau d'exécution. Avec systemd, les unités cibles peuvent êtreinclusive, ce qui signifie que lorsqu'une unité cible s'active, elle peut s'assurer que d'autres unités cibles sont chargées en tant que partie de celle-ci.

Par exemple, un système Linux qui démarre avec une interface utilisateur graphique aura legraphical.target activé, qui à son tour garantira automatiquement quemulti-user.target est également chargé et activé.

(En termes de système V, ce serait comme si les niveaux d'exécution 3 et 5 étaient activés en même temps.)

Le tableau ci-dessous compare les niveaux d'exécution et les objectifs:

default.target équivaut au niveau d'exécution par défaut.

Dans System V, nous avions le niveau d'exécution par défaut défini dans un fichier appeléinittab. Dans systemd, ce fichier est remplacé pardefault.target. Le fichier d'unité cible par défaut se trouve sous le répertoire/etc/systemd/system. Il s’agit d’un lien symbolique vers l’un des fichiers d’unité cible sous/lib/systemd/system.

Lorsque nous modifions la cible par défaut, nous recréons essentiellement ce lien symbolique et modifions le niveau d’exécution du système.

Le fichier inittab de System V spécifiait également le répertoire à partir duquel Linux exécutera ses scripts d'initialisation: il peut s'agir de n'importe lequel des répertoires rcn.d. Dans systemd, l'unité cible par défaut détermine les unités de ressources qui seront chargées au démarrage.

Toutes ces unités sont activées, mais pas toutes en parallèle ou en séquence. La façon dont une unité de ressource se charge peut dépendre des autres unités de ressource itwants ourequires.

La raison de cette discussion sur les fichiers d'unité et les unités cibles est de mettre en évidence la manière dont systemd traite la dépendance entre ses démons.

Comme nous l'avons vu précédemment, Upstart assure le chargement parallèle des services à l'aide de fichiers de configuration. Dans System V, un service pouvait démarrer dans des niveaux d'exécution particuliers, mais il était également possible d'attendre qu'un autre service ou une autre ressource devienne disponible. De la même manière, les services systemd peuvent être chargés de charger une ou plusieurs cibles ou d'attendre qu'un autre service ou une autre ressource soit devenu actif.

Dans systemd, une unité quirequiresest une autre unité ne démarrera pas tant que l'unité requise ne sera pas chargée et activée. Si l'unité requise échoue pour une raison quelconque pendant que la première unité est active, la première unité s'arrêtera également.

Si vous y réfléchissez, cela garantit la stabilité du système. Un service nécessitant la présence d'un répertoire particulier peut donc être amené à attendre que le point de montage de ce répertoire soit actif. Par contre, une unité quiwants une autre unité n'imposera pas de telles restrictions. Il ne s’arrêtera pas si l’unité recherchée s’arrête lorsque l’appelant est actif. Un exemple de ceci serait les services non essentiels qui apparaissent en mode cible graphique.

Il est temps de plonger de plus près dans le comportement de MySQL au démarrage sous systemd.

[[step-1 -—- log-in-to-centos-droplet]] === Étape 1 - Connectez-vous à CentOS Droplet

Pour comprendre tous ces concepts et leur lien avec le fait de permettre le démarrage automatique d’un service, revenons à la gouttelette CentOS 7 que nous avons créée dans la première partie.

Utilisez la commande SSH pour vous connecter au serveur (les utilisateurs Windows peuvent se connecter à l’aide d’un outil tel que PuTTy).

[[step-2 -—- looking-at-the-default-target-file-and-dependencies]] === Étape 2 - Examen du fichier default.target et des dépendances

C'est une longue section, car nous allons suivre la piste du lapin de.target aussi loin que possible. La séquence de démarrage de systemd suit une longue chaîne de dépendances.

defaul.target

Le fichierdefault.target contrôle quels services démarrent lors d'un démarrage normal du serveur.

Exécutez la commande suivante pour répertorier le fichier d'unité cible par défaut:

Cela montre la sortie comme suit:

Comme nous pouvons le voir, la cible par défaut est en fait un lien symbolique vers le fichier cible multi-utilisateurs sous/lib/systemd/system/. Ainsi, le système est censé démarrer sousmulti-user.target, ce qui est similaire au niveau d'exécution 3.

multi-user.target.wants

Ensuite, exécutez la commande suivante pour vérifier tous les services du fichiermulti-user.targetwants:

Cela devrait montrer une sortie comme celle-ci:

Nous pouvons voir que ce sont tous des fichiers de liens symboliques, pointant vers des fichiers unitaires réels sous/lib/systemd/system/. Nous pouvons également voir quemysqld.service fait partie demulti-user.target.

Les mêmes informations peuvent être trouvées si vous exécutez cette commande pour filtrer la sortie:

À partmulti-user.target, il existe différents types de cibles commesystem-update.target oubasic.target.

Pour voir sur quelles cibles dépend notre cible multi-utilisateurs, exécutez la commande suivante:

Donc, pour démarrer le système en modemulti-user.target,basic.target devra d'abord se charger.

basic.target

Pour voir de quelles autres ciblesbasic.target dépend, exécutez cette commande:

La sortie sera:

sysinit.target

De manière récursive, nous pouvons voir s'il y a des unités requises poursysinit.target. Il n'y en a pas. Cependant, nous pouvons voir quels services sontwanted parsysinit.target:

Cela montrera un certain nombre de services recherchés par sysinit.

Comme vous pouvez le constater, le système ne reste pas dans une seule cible. Il charge les services de manière dépendante lors de la transition entre les cibles.

[[step-3 -—- looking-at-a-unit-file]] === Étape 3 - Consultation d'un fichier d'unité

Pour aller plus loin maintenant, examinons un fichier d’unité de service. Nous avons vu le fichier d’unités de service MySQL dans la première partie de ce didacticiel, et nous l’utiliserons de nouveau dans un moment. Mais pour l’instant, ouvrons un autre fichier d’unités de services, celui de sshd:

Cela ressemble à ceci:

Tout comme un fichier de configuration de démon Upstart, ce fichier d'unité de service est propre et facile à comprendre.

Le premier bit important à comprendre est la clauseAfter. Cela signifie que le service SSHD doit être chargé après le chargement des cibles système et réseau et du service de journalisation d'audit.

Le fichier montre également que le service estwanted par lemulti-user.target, ce qui signifie que la cible chargera ce service, mais il ne s'arrêtera pas ou ne plantera pas si sshd échoue.

Puisquemulti-user.target est la cible par défaut, le démon sshd est censé démarrer au démarrage.

Quittez l'éditeur.

[[step-4 -—- testing-mysql-startup-behavior-at-boot]] === Étape 4 - Test du comportement de démarrage de MySQL au démarrage

Dans la première partie du didacticiel, nous avons laissé le service MySQL activé et en cours d'exécution. Voyons comment changer cela.

Dans la dernière section, nous avons exécuté une commande pour confirmer quemysqld.service est recherché parmulti-user.target. Lorsque nous avons répertorié le contenu du répertoire/etc/systemd/system/multi-user.target.wants/, nous avons vu un lien symbolique pointant vers l'unité de service d'origine sous/usr/lib/systemd/system/.

Exécutez la commande suivante pour désactiver le service afin qu'il ne démarre pas automatiquement au démarrage:

Maintenant, exécutez cette commande pour vérifier si MySQL est toujours recherché parmulti-user.target:

Rien ne sera retourné. Exécutez la commande ci-dessous pour vérifier si le lien symbolique existe toujours:

Le lien n'existe pas:

Si vous le souhaitez, essayez de redémarrer le serveur. MySQL ne devrait pas apparaître.

Activez maintenant le service:

Le lien va revenir:

(Si vous avez redémarré avant, vous devriez redémarrer MySQL.)

Comme vous pouvez le voir, l’activation ou la désactivation d’un service systemd crée ou supprime le lien symbolique du répertoirewants de la cible par défaut.

[[step-5 -—- testing-mysql-startup-behavior-on-crash]] === Étape 5 - Test du comportement de démarrage de MySQL en cas de crash

MySQL apparaîtra automatiquement après un crash. Voyons comment désactiver cela.

Ouvrez le fichier d'unité de service MySQL dans un éditeur:

Après les informations d'en-tête, le contenu du fichier se présente comme suit:

/etc/systemd/system/multi-user.target.wants/mysqld.service

Comme nous l'avons vu dans la partie 1, la valeur du paramètreRestart est définie suralways (pour sshd, elle a été définie suron-failure uniquement). Cela signifie que le service MySQL va redémarrer pour des codes de sortie ou des délais d'attente propres ou impurs.

Leman page for systemd service affiche le tableau suivant pour les paramètres de redémarrage:

Dans un fichier d'unité de service systemd, les deux paramètres -Restart etRestartSec - contrôlent le comportement en cas de panne. Le premier paramètre spécifie quand le service doit redémarrer et le second paramètre pendant combien de temps il doit attendre avant de redémarrer.

Mettez en commentaire la directive Restart, enregistrez le fichier et quittez l'éditeur. Cela désactivera le comportement de redémarrage.

/etc/systemd/system/multi-user.target.wants/mysqld.service

Ensuite, rechargez le démon systemd, suivi d'un redémarrage du servicemysqld:

Ensuite, recherchez le PID principal du service en exécutant cette commande:

À l'aide de la commandekill -9, supprimez le PID principal en utilisant votre propre numéro.

Exécuter à nouveau lessudo systemctl status mysqld.service montrera que le service a échoué:

Essayez de trouver l’état du service plusieurs fois, et chaque fois, le service sera présenté comme ayant échoué.

Nous avons donc imité un crash dans lequel le service s’est arrêté et n’est pas revenu. En effet, nous avons demandé à Systemd de ne pas redémarrer le service.

Maintenant, si vous modifiez à nouveau le fichier d'unité demysqld.service, supprimez les commentaires du paramètreRestart, enregistrez-le, rechargez le démon systemctl et enfin démarrez le service, il devrait être de retour à ce qu'il était auparavant.

Voici comment un service systemd natif peut être configuré pour un démarrage automatique après un crash. Tout ce que nous avons à faire est d'ajouter une directive supplémentaire pourRestart (et éventuellementRestartSec) dans la section[Service] du fichier d'unité de service.

Voilà comment Linux gère le démarrage du service. Nous avons vu le fonctionnement des processus System V, Upstart et systemd init et leur relation avec le démarrage automatique d'un service après un redémarrage ou un blocage.

La syntaxe déclarative des fichiers de configuration Upstart ou des fichiers unité Systemd constitue une amélioration par rapport aux scripts initiaux System V.

Lorsque vous travaillez avec votre propre environnement Linux, vérifiez la version de votre distribution et voyez quel démon init est pris en charge.

Il sera utile de penser aux endroits où vous voudriez activer un service et où vous voudriez le désactiver. Dans la plupart des cas, vous n’avez rien à changer pour les applications tierces ou les démons Linux natifs. Ce n’est que lorsque vous créez vos propres applications basées sur les services que vous devez réfléchir à leur comportement de démarrage et de réapparition.