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

introduction

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.

Conditions préalables

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

Nous avons eu:

  • Un serveur Debian 6 exécutant MySQL

  • Un serveur Ubuntu 14.04 exécutant MySQL

  • Un serveur CentOS 7 exécutant MySQL

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.

Niveaux d'exécution

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:

  • Runlevel 0: Arrêt du système

  • Runlevel 1: Mono-utilisateur, mode de secours

  • Runlevels 2, 3, 4: Multi-utilisateur, mode texte avec mise en réseau activée

  • Runlevel 5: Multi-utilisateur, réseau activé, mode graphique

  • Runlevel 6: Redémarrage du système

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 et PID 1

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.

Séquence d'initialisation du système V

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:

  1. Le démon init est créé à partir du fichier binaire/sbin/init

  2. Le premier fichier lu par le démon init est/etc/inittab

  3. L'une des entrées de ce fichier détermine le niveau d'exécution dans lequel la machine doit démarrer. Par exemple, si la valeur du niveau d'exécution est définie sur 3, Linux démarre en mode texte multi-utilisateur avec la mise en réseau activée. (Ce niveau d'exécution est appelé niveau d'exécution par défaut)

  4. Ensuite, le démon init examine plus en détail le fichier/etc/inittab et lit lesinit scripts dont il a besoin pour ce niveau d'exécution

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.

Fichiers de configuration System V: scripts d'initialisation

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

Structure du répertoire

Le répertoire/etc est le répertoire parent des scripts d'initialisation.

L'emplacement réel des scripts shell d'initialisation est sous/etc/init.d. Ces scripts sont liés par un lien symbolique aux répertoiresrc.

Dans le répertoire/etc, nous avons un certain nombre de répertoiresrc, chacun avec un numéro dans son nom.

Les nombres représentent différents niveaux d'exécution. Nous avons donc/etc/rc0.d,/etc/rc1.d,/etc/rc2.d et ainsi de suite.

Ensuite, dans chaque répertoirercn.d, nous avons des fichiers qui commencent parK ouS dans leur nom de fichier, suivis de deux chiffres. Ce sont des fichiers de liens symboliques qui renvoient aux scripts shell init réels. Pourquoi lesK etS? K signifie Kill (i.e. stop) et «S» signifie Start.

Les deux chiffres représentent l'ordre d'exécution du script. Donc, si nous avons un fichier nommé K25some_script, il s'exécutera avant K99another_script.

Commencez

Reprenons notre séquence de démarrage. Alors, comment s'appellent les scripts d'initialisation? Qui les appelle?

Les scripts K et S ne sont pas appelés directement par le démon init, mais par un autre script: le script/etc/init.d/rc.

Si vous vous en souvenez, le fichier/etc/inittab indique au démon init quel niveau d'exécution le système doit entrer par défaut. Pour chaque niveau d'exécution, une ligne dans le fichier/etc/inittab appelle le script/etc/init.d/rc, en passant ce niveau d'exécution comme paramètre. Sur la base de ce paramètre, le script appelle ensuite les fichiers sous le répertoire/etc/rcn.d correspondant. Ainsi, si le serveur démarre avec le niveau d'exécution 2, les scripts sous les/etc/rc2.d seront appelés; pour le niveau d'exécution 3, les scripts sous/etc/rc3.d sont exécutés, et ainsi de suite.

Dans un répertoirerc, tout d'abord, tous les scripts K sont exécutés dans l'ordre numérique avec un argument «stop», puis tous les scripts S sont exécutés de la même manière avec un argument «start». Dans les coulisses, les scripts de shell init correspondants seront appelés respectivement avec des paramètres d'arrêt et de démarrage.

Maintenant que les fichiers sous les répertoires/etc/rcn.d (fichiersKnn etSnn) ne sont que des liens symboliques, les appeler signifie appeler les scripts shell init réels avec des paramètres d'arrêt et de démarrage.

En résumé, lorsque le serveur Linux entre dans un niveau d'exécution, certains scripts seront exécutés pour arrêter certains services, tandis que d'autres seront exécutés pour en démarrer d'autres.

[.Remarque]##

Cet appel de scripts d'initialisation se produit également chaque fois que le système passe à un nouveau niveau d'exécution: les scripts de répertoire/etc/rc<n>.d correspondants sont exécutés. Et comme ces fichiers K et S ne sont que des liens, les scripts shell réels sous le répertoire/etc/init.d sont exécutés avec l'argument start ou stop approprié.

L'ensemble du processus garantit que tout service non censé s'exécuter dans ce niveau d'exécution est arrêté et que tous les services censés s'exécuter dans ce niveau d'exécution sont démarrés.

Démarrage automatique du système V

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.

Exemple de système V

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

ssh [email protected]_server_ip

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

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

cat /etc/inittab | grep initdefault

Le résultat devrait ressembler à ceci:

Outputid:2:initdefault:

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:

cat /etc/inittab | grep Runlevel

la sortie confirme ceci:

Output# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

[[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:

ls -ld /etc/rc*.d
Outputdrwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc0.d
drwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc1.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc2.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc3.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc4.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc5.d
drwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc6.d
drwxr-xr-x 2 root root 4096 Jul 23  2012 /etc/rcS.d

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:

ls -l /etc/rc2.d

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

Output. . .
lrwxrwxrwx 1 root root  17 Jul 23  2012 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root  22 Jul 23  2012 S02acpi-support -> ../init.d/acpi-support
lrwxrwxrwx 1 root root  15 Jul 23  2012 S02acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root  17 Jul 23  2012 S02anacron -> ../init.d/anacron
lrwxrwxrwx 1 root root  13 Jul 23  2012 S02atd -> ../init.d/atd
lrwxrwxrwx 1 root root  14 Jul 23  2012 S02cron -> ../init.d/cron
lrwxrwxrwx 1 root root  15 Jul 31 07:09 S02mysql -> ../init.d/mysql
lrwxrwxrwx 1 root root  13 Jul 23  2012 S02ssh -> ../init.d/ssh
. . .

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:

ls -l /etc/init.d/my*
Output-rwxr-xr-x 1 root root 5437 Jan 14  2014 /etc/init.d/mysql

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

cat /etc/init.d/mysql | less

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:

chkonfig --list | grep service_name

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:

sudo apt-get install sysv-rc-conf -y

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

sudo sysv-rc-conf

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

sysv-rc-conf Window showing X marks for various services for each runlevel

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:

sudo update-rc.d mysql disable
Outputupdate-rc.d: using dependency based boot sequencing
insserv: warning: current start runlevel(s) (empty) of script `mysql' overwrites defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' overwrites defaults (0 1 6).

Maintenant, lancez la commande:

ls -l /etc/rc2.d

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

Output. . .
lrwxrwxrwx 1 root root  15 Jul 31 07:09 K02mysql -> ../init.d/mysql
. . .

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:

sudo update-rc.d mysql enable

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

ms:2345:respawn:/bin/sh /usr/bin/mysqld_safe

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:

sudo reboot

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

ps -ef | grep mysql

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

Outputroot       907     1  0 07:30 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql     1031   907  0 07:30 ?        00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
root      1032   907  0 07:30 ?        00:00:00 logger -t mysqld -p daemon.error
root      2550  2532  0 07:31 pts/0    00:00:00 grep mysql

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

sudo kill -9 907
sudo kill -9 1031

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

sudo service mysql status

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

Output/usr/bin/mysqladmin  Ver 8.42 Distrib 5.1.73, for debian-linux-gnu on x86_64

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.

Introduction récente

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 ne traite pas les scripts du shell arcane pour charger et gérer les services. Au lieu de cela, il utilise des fichiers de configuration simples, faciles à comprendre et à modifier.

  • Upstart ne charge pas les services en série comme System V. Cela réduit le temps de démarrage du système

  • Upstart’s utilise un systèmeevent flexible pour personnaliser la manière dont les services sont gérés dans divers états

  • Upstart a de meilleurs moyens de gérer la réapparition d'un service bloqué

  • Il n'est pas nécessaire de conserver un certain nombre de liens symboliques redondants, tous pointant vers le même script.

  • Upstart est rétro-compatible avec System V. Le script/etc/init.d/rc s’exécute toujours pour gérer les services System V natifs

Événements Upstart

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:

  • Départ

  • Commencé

  • Arrêt

  • Arrêté

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

  • attendre

  • pré-départ

  • départ

  • fonctionnement

  • pré-stop

  • arrêt

  • etc.

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

Séquence Init Upstart

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.

Fichiers de configuration par défaut

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:

  • Quels niveaux d'exécution le service doit-il démarrer et arrêter?

  • Indique si le service doitrespawn s'il plante

Structure du répertoire

Les fichiers de configuration Upstart sont situés sous le répertoire/etc/init (à ne pas confondre avec/etc/init.d).

Exemple de démarrage

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

ssh [email protected]_server_ip

[[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:

sudo ls -l /etc/init/ | less

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:

Outputtotal 356
. . .
-rw-r--r-- 1 root root  297 Feb  9  2013 cron.conf
-rw-r--r-- 1 root root  489 Nov 11  2013 dbus.conf
-rw-r--r-- 1 root root  273 Nov 19  2010 dmesg.conf
. . .
-rw-r--r-- 1 root root 1770 Feb 19  2014 mysql.conf
-rw-r--r-- 1 root root 2493 Mar 20  2014 networking.conf

Appuyez surQ pour quitterless.

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

sudo ls -l /etc/rc3.d/* | less

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

Output-rw-r--r-- 1 root root 677 Jun 14 23:31 /etc/rc3.d/README
lrwxrwxrwx 1 root root  15 Apr 17  2014 /etc/rc3.d/S20rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root  24 Apr 17  2014 /etc/rc3.d/S20screen-cleanup -> ../init.d/screen-cleanup
lrwxrwxrwx 1 root root  19 Apr 17  2014 /etc/rc3.d/S70dns-clean -> ../init.d/dns-clean
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S70pppd-dns -> ../init.d/pppd-dns
lrwxrwxrwx 1 root root  26 Apr 17  2014 /etc/rc3.d/S99digitalocean -> ../init.d//rc.digitalocean
lrwxrwxrwx 1 root root  21 Apr 17  2014 /etc/rc3.d/S99grub-common -> ../init.d/grub-common
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S99ondemand -> ../init.d/ondemand
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S99rc.local -> ../init.d/rc.local

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

sudo nano /etc/init/cron.conf

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

/etc/init/cron.conf

# cron - regular background program processing daemon
#
# cron is a standard UNIX program that runs user-specified programs at
# periodic scheduled times

description     "regular background program processing daemon"

start on runlevel [2345]
stop on runlevel [!2345]

expect fork
respawn

exec cron

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:

sudo nano /etc/init/mysql.override

Ajouter cette seule ligne:

/etc/init/mysql.override

manual

Enregistrez vos modifications.

Ensuite, redémarrez le serveur:

sudo reboot

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

sudo initctl status mysql

Le résultat devrait être:

Outputmysql stop/waiting

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

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

sudo cat /etc/init/mysql.conf | grep start\ on

Ce devrait toujours être le même:

Outputstart on runlevel [2345]

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:

sudo rm -f /etc/init/mysql.override
sudo reboot

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:

sudo nano /etc/init/mysql.conf

Mettez en commentaire les deux directivesrespawn.

/etc/init/mysql.conf

# respawn
# respawn limit 2 5

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

sudo initctl stop mysql
sudo initctl start mysql

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:

Outputmysql start/running, process 1274

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):

sudo kill -9 1274

Maintenant, vérifiez son statut:

sudo initctl status mysql
Outputmysql stop/waiting

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.

systemd Introduction

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.

Fichiers de configuration de systemd: Fichiers d'unités

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.

Structure du répertoire

Dans les systèmes basés sur Red Hat tels que CentOS, les fichiers d'unité sont situés à deux endroits. L'emplacement principal est/lib/systemd/system/.

Les fichiers d'unité créés sur mesure ou les fichiers d'unité existants modifiés par les administrateurs système vivront sous/etc/systemd/system.

Si un fichier d'unité portant le même nom existe aux deux emplacements, systemd utilisera celui sous/etc. Si un service est activé pour démarrer au moment du démarrage ou à tout autre niveau cible / d'exécution, un lien symbolique sera créé pour ce fichier d'unité de service dans les répertoires appropriés dans/etc/systemd/system. Les fichiers d'unité sous/etc/systemd/system sont en fait des liens symboliques vers les fichiers de même nom sous/lib/systemd/system.

Séquence d'initialisation systemd: unités cibles

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:

Niveau d'exécution (init système V) Unités cibles (Systemd)

niveau d'exécution 0

poweroff.target

niveau d'exécution 1

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

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.

Dépendances systemd: veut et requiert

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.

systemd Exemple

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

ssh [email protected]_server_ip

[[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:

sudo ls -l /etc/systemd/system/default.target

Cela montre la sortie comme suit:

Outputlrwxrwxrwx. 1 root root 37 Jul  8  2014 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

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:

sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service

Cela devrait montrer une sortie comme celle-ci:

Output. . .
lrwxrwxrwx. 1 root root  37 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/crond.service -> /usr/lib/systemd/system/crond.service
. . .
lrwxrwxrwx  1 root root  38 Jul 31 22:02 /etc/systemd/system/multi-user.target.wants/mysqld.service -> /usr/lib/systemd/system/mysqld.service
lrwxrwxrwx. 1 root root  46 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx. 1 root root  39 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/postfix.service -> /usr/lib/systemd/system/postfix.service
lrwxrwxrwx. 1 root root  39 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
lrwxrwxrwx. 1 root root  36 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service
. . .

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:

sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep mysql
Outputmysqld.service

À 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:

sudo systemctl show --property "Requires" multi-user.target | fmt -10
OutputRequires=basic.target

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:

sudo systemctl show --property "Requires" basic.target | fmt -10

La sortie sera:

OutputRequires=sysinit.target

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:

sudo systemctl show --property "Wants" sysinit.target | fmt -10

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

OutputWants=local-fs.target
swap.target
cryptsetup.target
systemd-udevd.service
systemd-update-utmp.service
systemd-journal-flush.service
plymouth-read-write.service
. . .

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:

sudo nano /etc/systemd/system/multi-user.target.wants/sshd.service

Cela ressemble à ceci:

Output[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

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:

sudo systemctl disable mysqld.service

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

sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep mysql

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

sudo ls -l /etc/systemd/system/multi-user.target.wants/mysql*

Le lien n'existe pas:

Outputls: cannot access /etc/systemd/system/multi-user.target.wants/mysql*: No such file or directory

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

Activez maintenant le service:

sudo systemctl enable mysqld.service

Le lien va revenir:

sudo ls -l /etc/systemd/system/multi-user.target.wants/mysql*
Outputlrwxrwxrwx 1 root root 38 Aug  1 04:43 /etc/systemd/system/multi-user.target.wants/mysqld.service -> /usr/lib/systemd/system/mysqld.service

(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:

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

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

[Unit]
Description=MySQL Community Server
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
User=mysql
Group=mysql

# Execute pre and post scripts as root
PermissionsStartOnly=true

# Needed to create system tables etc.
ExecStartPre=/usr/bin/mysql-systemd-start pre

# Start main service
ExecStart=/usr/bin/mysqld_safe

# Don't signal startup success before a ping works
ExecStartPost=/usr/bin/mysql-systemd-start post

# Give up if ping don't get an answer
TimeoutSec=600

Restart=always
PrivateTmp=false

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:

Paramètres de redémarrage / causes de sortie no toujours succès en cas de panne sur-anormal sur-abandon chien de garde

Nettoyer le code ou le signal de sortie

X

X

Code de sortie impur

X

X

Signal impur

X

X

X

X

Temps libre

X

X

X

Chien de garde

X

X

X

X

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

# Restart=always

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

sudo systemctl daemon-reload
sudo systemctl restart mysqld.service

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

sudo systemctl status mysqld.service
Output. . .
Main PID: 11217 (mysqld_safe)

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

sudo kill -9 11217

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

sudo systemctl status mysqld.service
Outputmysqld.service - MySQL Community Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
   Active: failed (Result: signal) since Sun 2015-06-21 02:28:17 EDT; 1min 33s ago
  Process: 2566 ExecStartPost=/usr/bin/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 2565 ExecStart=/usr/bin/mysqld_safe (code=killed, signal=KILL)
  Process: 2554 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 2565 (code=killed, signal=KILL)

Jun 21 02:20:09 test-centos7 systemd[1]: Starting MySQL Community Server...
Jun 21 02:20:09 test-centos7 mysqld_safe[2565]: 150621 02:20:09 mysqld_safe Logging to '/var/log/mysqld.log'.
Jun 21 02:20:09 test-centos7 mysqld_safe[2565]: 150621 02:20:09 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Jun 21 02:20:10 test-centos7 systemd[1]: Started MySQL Community Server.
Jun 21 02:28:16 test-centos7 systemd[1]: mysqld.service: main process exited, code=killed, status=9/KILL
Jun 21 02:28:17 test-centos7 systemd[1]: Unit mysqld.service entered failed state.

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.

Conclusion

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.

Related