LFCS : Gestion du processus et des services de démarrage du système (SysVinit, Systemd et Upstart) - Partie 7

Il y a quelques mois, la Linux Foundation a annoncé la certification LFCS (Linux Foundation Certified Sysadmin), un nouveau programme passionnant dont le but est de permettre à des individus du monde entier de obtenez une certification pour effectuer des tâches d'administration système de base à intermédiaires sur les systèmes Linux. Cela inclut la prise en charge des systèmes et services déjà en cours d'exécution, ainsi que la recherche et l'analyse directe des problèmes, ainsi que la capacité de décider quand signaler les problèmes aux équipes d'ingénierie.

La vidéo suivante décrit une brève introduction au programme de certification de la Linux Foundation.

Cet article est la partie 7 d'une série de 10 didacticiels. Dans cette partie, nous expliquerons comment gérer le processus et les services de démarrage du système Linux, requis pour l'examen de certification LFCS.

Gestion du processus de démarrage Linux

Le processus de démarrage d'un système Linux se compose de plusieurs phases, chacune représentée par un composant différent. Le diagramme suivant résume brièvement le processus de démarrage et montre tous les principaux composants impliqués.

Lorsque vous appuyez sur le bouton Alimentation de votre ordinateur, le micrologiciel stocké dans une puce EEPROM de la carte mère initialise le POST ( Power-On Self Test) pour vérifier l'état des ressources matérielles du système. Lorsque le POST est terminé, le firmware recherche et charge alors le chargeur de démarrage 1ère étape, situé dans le MBR ou dans l'EFI du premier disque disponible, et en donne le contrôle.

Méthode MBR

Le MBR est situé dans le premier secteur du disque marqué comme amorçable dans les paramètres du BIOS et a une taille de 512 octets.

446 premiers octets : le chargeur de démarrage contient à la fois le code exécutable et le texte du message d'erreur.
64 octets suivants : la table de partition contient un enregistrement pour chacune des quatre partitions (primaire ou étendue). Entre autres choses, chaque enregistrement indique l'état (actif/non actif), la taille et les secteurs de début/fin de chaque partition.
2 derniers octets : le nombre magique sert de contrôle de validation du MBR.

La commande suivante effectue une sauvegarde du MBR (dans cet exemple, /dev/sda est le premier disque dur). Le fichier résultant, mbr.bkp peut s'avérer utile si la table de partition est corrompue, par exemple, rendant le système impossible à démarrer.

Bien entendu, afin de l'utiliser plus tard si le besoin s'en fait sentir, nous devrons le sauvegarder et le stocker ailleurs (comme une clé USB par exemple). Ce fichier nous aidera à restaurer le MBR et nous permettra de recommencer si et seulement si nous ne modifions pas la disposition du disque dur entre-temps.

MBR de sauvegarde

dd if=/dev/sda of=mbr.bkp bs=512 count=1

Restauration du MBR

dd if=mbr.bkp of=/dev/sda bs=512 count=1

Méthode EFI/UEFI

Pour les systèmes utilisant la méthode EFI/UEFI, le micrologiciel UEFI lit ses paramètres pour déterminer quelle application UEFI doit être lancée et d'où (c'est-à-dire, dans quel disque et quelle partition le La partition EFI est localisée).

Ensuite, le chargeur de démarrage 2ème étape (alias gestionnaire de démarrage) est chargé et exécuté. GRUB [GRand Unified Boot] est le gestionnaire de démarrage le plus fréquemment utilisé sous Linux. L'une des deux versions distinctes peut être trouvée sur la plupart des systèmes utilisés aujourd'hui.

Fichier de configuration hérité de GRUB : /boot/grub/menu.lst (anciennes distributions, non prises en charge par les firmwares EFI/UEFI).
Fichier de configuration GRUB2 : très probablement, /etc/default/grub.

Bien que les objectifs de l'examen LFCS ne demandent pas explicitement de connaissances sur les composants internes de GRUB, si vous êtes courageux et pouvez vous permettre de gâcher votre système (vous voudrez peut-être l'essayer) d'abord sur une machine virtuelle, juste au cas où), vous devez exécuter.

update-grub

En tant que root après avoir modifié la configuration de GRUB afin d'appliquer les modifications.

Fondamentalement, GRUB charge le noyau par défaut et l'image initrd ou initramfs. En quelques mots, initrd ou initramfs aident à effectuer la détection du matériel, le chargement du module noyau et la découverte de périphériques nécessaires pour monter le véritable système de fichiers racine.

Une fois que le véritable système de fichiers racine est opérationnel, le noyau exécute le gestionnaire de système et de services (init ou systemd, dont l'identification de processus ou le PID est toujours 1) pour commencer le processus utilisateur normal. processus de démarrage spatial afin de présenter une interface utilisateur.

init et systemd sont des démons (processus en arrière-plan) qui gèrent d'autres démons, en tant que premier service à démarrer (lors du démarrage) et dernier service à terminer (lors de l'arrêt).

Démarrage des services (SysVinit)

Le concept de niveaux d'exécution sous Linux spécifie différentes manières d'utiliser un système en contrôlant les services en cours d'exécution. En d’autres termes, un niveau d’exécution contrôle quelles tâches peuvent être accomplies dans l’état d’exécution actuel=niveau d’exécution (et lesquelles ne le peuvent pas).

Traditionnellement, ce processus de démarrage était effectué sur la base de conventions issues du System V UNIX, le système transmettant des collections de scripts exécutant qui démarrent et arrêtent les services lorsque la machine entre dans un niveau d'exécution spécifique (qui, en d'autres termes , est un mode différent de fonctionnement du système).

Au sein de chaque niveau d'exécution, des services individuels peuvent être configurés pour s'exécuter ou être arrêtés s'ils sont en cours d'exécution. Les dernières versions de certaines distributions majeures s'éloignent du standard System V au profit d'un gestionnaire de service et de système plutôt nouveau appelé systemd (qui signifie démon système), mais généralement prend en charge les commandes sysv à des fins de compatibilité. Cela signifie que vous pouvez exécuter la plupart des outils d'initialisation sysv bien connus dans une distribution basée sur systemd.

Lire aussi : Pourquoi « systemd » remplace « init » sous Linux

En plus de démarrer le processus système, init consulte le fichier /etc/inittab pour décider quel niveau d'exécution doit être saisi.

Runlevel: Description
0: Arrêtez le système. Le niveau d'exécution 0 est un état de transition spécial utilisé pour arrêter rapidement le système.
1: Également appelé s, ou S, ce niveau d'exécution est parfois appelé mode maintenance. Les services, le cas échéant, démarrés à ce niveau d'exécution varient selon la distribution. Il est généralement utilisé pour la maintenance de bas niveau du système qui peut être altérée par le fonctionnement normal du système.
2: Multi-utilisateur. Sur les systèmes Debian et dérivés, il s'agit du niveau d'exécution par défaut et inclut -si disponible- une connexion graphique. Sur les systèmes basés sur Red-Hat, il s'agit du mode multi-utilisateur sans réseau.
3: Sur les systèmes basés sur Red-Hat, il s'agit du mode multi-utilisateur par défaut, qui exécute tout sauf l'environnement graphique. Ce niveau d'exécution ainsi que les niveaux 4 et 5 ne sont généralement pas utilisés sur les systèmes basés sur Debian.
4: Généralement inutilisé par défaut et donc disponible pour la personnalisation.
5: Sur les systèmes basés sur Red-Hat, mode multi-utilisateur complet avec connexion GUI. Ce niveau d'exécution est comme le niveau 3, mais avec une connexion GUI disponible.
6: Redémarrez le système.

Pour basculer entre les niveaux d'exécution, nous pouvons simplement émettre un changement de niveau d'exécution à l'aide de la commande init : init N (où N est l'un des niveaux d'exécution répertoriés ci-dessus). Veuillez noter que ce n'est pas la méthode recommandée pour amener un système en cours d'exécution à un niveau d'exécution différent, car elle ne donne aucun avertissement aux utilisateurs connectés existants (ce qui leur fait perdre du travail et les processus se terminent anormalement).

Au lieu de cela, la commande shutdown doit être utilisée pour redémarrer le système (qui envoie d'abord un message d'avertissement à tous les utilisateurs connectés et bloque toute connexion ultérieure ; elle signale ensuite à init de changer de niveau d'exécution) ; cependant, le niveau d'exécution par défaut (celui sur lequel le système démarrera) doit d'abord être modifié dans le fichier /etc/inittab.

Pour cette raison, suivez ces étapes pour basculer correctement entre les niveaux d'exécution. En tant qu'utilisateur root, recherchez la ligne suivante dans /etc/inittab.

id:2:initdefault:

et modifiez le numéro 2 pour le niveau d'exécution souhaité avec votre éditeur de texte préféré, tel que vim (décrit dans Comment utiliser l'éditeur vi/vim sous Linux – Partie 2 de cette série).

Ensuite, exécutez en tant que root.

shutdown -r now

Cette dernière commande redémarrera le système, le faisant démarrer dans le niveau d'exécution spécifié lors du prochain démarrage, et exécutera les scripts situés dans le /etc/rc[runlevel].d répertoire afin de décider quels services doivent être démarrés et lesquels ne doivent pas être démarrés. Par exemple, pour le niveau d'exécution 2 dans le système suivant.

Gérer les services à l'aide de chkconfig

Pour activer ou désactiver les services système au démarrage, nous utiliserons la commande chkconfig dans CentOS/openSUSE et sysv-rc-conf dans Debian et dérivés. Cet outil peut également nous montrer quel est l'état préconfiguré d'un service pour un niveau d'exécution particulier.

Lire aussi : Comment arrêter et désactiver les services indésirables sous Linux

Répertorier la configuration du niveau d'exécution pour un service.

chkconfig --list [service name]
chkconfig --list postfix
chkconfig --list mysqld

Dans l'image ci-dessus, nous pouvons voir que postfix est configuré pour démarrer lorsque le système entre dans les niveaux d'exécution 2 à 5, alors que mysqld sera exécuté par défaut pour les niveaux d'exécution 2 à 4. Supposons maintenant que ce ne soit pas le comportement attendu.

Par exemple, nous devons également activer mysqld pour le niveau d'exécution 5 et désactiver Postfix pour les niveaux d'exécution 4 et 5. Voici ce que nous ferions dans chaque cas (exécuter le commandes suivantes en tant que root).

Activation d'un service pour un niveau d'exécution particulier

chkconfig --level [level(s)] service on
chkconfig --level 5 mysqld on

Désactivation d'un service pour des niveaux d'exécution particuliers

chkconfig --level [level(s)] service off
chkconfig --level 45 postfix off

Nous allons maintenant effectuer des tâches similaires dans un système basé sur Debian en utilisant sysv-rc-conf.

Gérer les services à l'aide de sysv-rc-conf

Configuration d'un service pour qu'il démarre automatiquement sur un niveau d'exécution spécifique et l'empêche de démarrer sur tous les autres.

1. Utilisons la commande suivante pour voir quels sont les niveaux d'exécution où mdadm est configuré pour démarrer.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

2. Nous utiliserons sysv-rc-conf pour empêcher mdadm de démarrer à tous les niveaux d'exécution sauf 2. Cochez ou décochez simplement (avec la barre d'espace) comme vous le souhaitez (vous pouvez vous déplacer vers le haut, le bas, la gauche et la droite avec les touches fléchées).

sysv-rc-conf

Appuyez ensuite sur q pour quitter.

3. Nous allons redémarrer le système et exécuter à nouveau la commande de l'ÉTAPE 1.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

Dans l'image ci-dessus, nous pouvons voir que mdadm est configuré pour démarrer uniquement au niveau d'exécution 2.

Et systemd ?

systemd est un autre service et gestionnaire système adopté par plusieurs distributions Linux majeures. Il vise à permettre d'effectuer davantage de traitements en parallèle lors du démarrage du système (contrairement à sysvinit, qui a toujours tendance à être plus lent car il démarre les processus un par un, vérifie si l'un dépend de l'autre et attend démons à lancer pour que davantage de services puissent démarrer) et pour servir de gestion dynamique des ressources à un système en cours d'exécution.

Ainsi, les services sont démarrés en cas de besoin (pour éviter de consommer les ressources système) au lieu d'être lancés sans raison solide lors du démarrage.

En affichant l'état de tous les processus en cours d'exécution sur votre système, à la fois les services natifs systemd et SysV, exécutez la commande suivante.

systemctl

La colonne LOAD indique si la définition de l'unité (reportez-vous à la colonne UNIT, qui montre le service ou tout ce qui est géré par systemd) a été correctement chargée, tandis que la colonne ACTIVE< Les colonnes et SUB indiquent l'état actuel de cette unité.

Affichage d'informations sur l'état actuel d'un service

Lorsque la colonne ACTIVE indique que l'état d'une unité est autre qu'actif, nous pouvons vérifier ce qui s'est passé en utilisant.

systemctl status [unit]

Par exemple, dans l'image ci-dessus, media-samba.mount est en état d'échec. Courons.

systemctl status media-samba.mount

Nous pouvons voir que media-samba.mount a échoué car le processus de montage sur l'hôte dev1 n'a pas pu trouver le partage réseau sur //192.168.0.10/gacanepa.

Démarrage ou arrêt des services

Une fois le partage réseau //192.168.0.10/gacanepa disponible, essayons de démarrer, puis d'arrêter et enfin de redémarrer l'unité media-samba.mount. Après avoir effectué chaque action, exécutons systemctl status media-samba.mount pour vérifier son état.

systemctl start media-samba.mount
systemctl status media-samba.mount
systemctl stop media-samba.mount
systemctl restart media-samba.mount
systemctl status media-samba.mount

Activation ou désactivation d'un service pour qu'il démarre pendant le démarrage

Sous systemd, vous pouvez activer ou désactiver un service lors de son démarrage.

systemctl enable [service] 		# enable a service 
systemctl disable [service] 		# prevent a service from starting at boot

Le processus d'activation ou de désactivation d'un service pour qu'il démarre automatiquement au démarrage consiste à ajouter ou supprimer des liens symboliques dans le répertoire /etc/systemd/system/multi-user.target.wants.

Alternativement, vous pouvez connaître l’état actuel d’un service (activé ou désactivé) avec la commande.

systemctl is-enabled [service]

Par exemple,

systemctl is-enabled postfix.service

De plus, vous pouvez redémarrer ou arrêter le système avec.

systemctl reboot
systemctl shutdown

Parvenu

Upstart est un remplacement basé sur les événements du démon /sbin/init et est né de la nécessité de démarrer les services uniquement, lorsqu'ils sont nécessaires (et de les superviser pendant qu'ils sont en cours d'exécution) et gèrent les événements au fur et à mesure qu'ils se produisent, surpassant ainsi le système sysvinit classique basé sur les dépendances.

Il a été initialement développé pour la distribution Ubuntu, mais est utilisé dans Red Hat Enterprise Linux 6.0. Même s'il était destiné à être déployé dans toutes les distributions Linux en remplacement de sysvinit, il a finalement été éclipsé par systemd. Le 14 février 2014, Mark Shuttleworth (fondateur de Canonical Ltd.) a annoncé que les futures versions d'Ubuntu utiliseraient systemd comme démon d'initialisation par défaut.

Étant donné que le script de démarrage SysV pour le système est si courant depuis si longtemps, un grand nombre de progiciels incluent des scripts de démarrage SysV. Pour prendre en charge de tels packages, Upstart propose un mode de compatibilité : il exécute les scripts de démarrage SysV aux emplacements habituels (/etc/rc.d/rc?.d, /etc/init.d/ rc?.d, /etc/rc?.d ou un emplacement similaire). Ainsi, si nous installons un package qui n’inclut pas encore de script de configuration Upstart, il devrait quand même se lancer de la manière habituelle.

De plus, si nous avons installé des utilitaires tels que chkconfig, vous devriez pouvoir les utiliser pour gérer vos services basés sur SysV comme nous le ferions sur des systèmes basés sur sysvinit.

Les scripts Upstart prennent également en charge le démarrage ou l'arrêt des services en fonction d'une plus grande variété d'actions que les scripts de démarrage SysV ; par exemple, Upstart peut lancer un service chaque fois qu'un périphérique matériel particulier est connecté.

Un système qui utilise Upstart et ses scripts natifs remplace exclusivement le fichier /etc/inittab et les répertoires de script de démarrage SysV spécifiques au niveau d'exécution par .conf scripts dans le répertoire /etc/init.

Ces scripts *.conf (également appelés définitions de tâches) se composent généralement des éléments suivants :

Description du processus.
Niveaux d'exécution où le processus doit s'exécuter ou événements qui doivent le déclencher.
Niveaux d'exécution où le processus doit être arrêté ou événements qui doivent l'arrêter.
Possibilités.
Commande pour lancer le processus.

Par exemple,

My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email >"
Stanzas

#
Stanzas define when and how a process is started and stopped
See a list of stanzas here: http://upstart.ubuntu.com/wiki/Stanzas#respawn
When to start the service
start on runlevel [2345]
When to stop the service
stop on runlevel [016]
Automatically restart process in case of crash
respawn
Specify working directory
chdir /home/dave/myfiles
Specify the process/command (add arguments if needed) to run
exec bash backup.sh arg1 arg2

Pour appliquer les modifications, vous devrez demander à Upstart de recharger sa configuration.

initctl reload-configuration

Ensuite, démarrez votre travail en tapant la commande suivante.

sudo start yourjobname

Où yourjobname est le nom du travail qui a été ajouté précédemment avec le script yourjobname.conf.

Un guide de référence plus complet et détaillé pour Upstart est disponible sur le site Web du projet sous le menu « Cookbook ».

Résumé

Une connaissance du processus de démarrage Linux est nécessaire pour vous aider dans les tâches de dépannage ainsi que pour adapter les performances de l'ordinateur et l'exécution des services à vos besoins.

Dans cet article, nous avons analysé ce qui se passe à partir du moment où vous appuyez sur l'interrupteur Alimentation pour allumer la machine jusqu'à ce que vous obteniez une interface utilisateur entièrement opérationnelle. J'espère que vous avez appris à le lire autant que moi en le préparant. N'hésitez pas à laisser vos commentaires ou questions ci-dessous. Nous avons toujours hâte d’entendre nos lecteurs !