SysInit V | UpStart | SystemD

I► Dans cet article nous allons étudier les fameux niveaux de démarrage d’une machine Linux … Nous aborderons également les futurs successeurs de SysInit …

SystemD (System Daemon) (initié par Lennart Poettering en 2010) ou Upstart développé par Ubuntu depuis 2006 vont-ils remplacer SysInit V (System Init V Unix) standard sur la plupart des distributions Linux ?

=> Comment se fait le démarrage et l’initialisation d’une machine Linux :

I- L’initialisation et le démarrage de UNIX SYSTEM V :

Le gestionnaire de démarrage du MBR charge le noyau Linux (et un éventuel initrd), ensuite le noyau monte le système de fichier racine /, il lance la toute première console et enfin éxécute la première tâche : « init » basée sur les primitives fork et exec.

SysInit gère le démarrage du système par priorité et séquentiellement. Les liens de personnalisation des RunLevels ( les niveaux de démarrage ) sont placés dans chaque /etc/RCx.D et pointent vers /etc/init.d ( ou l’on trouve les scripts de démarrage des services ).
Les commandes service et chkconfig permettent de gérer ces fameux Runlevels.
Init en tant que commande permet de passer d’un runlevel à l’autre.
Init en tant que processus est le tout premier PID N°1 !

Pour rappel : les runlevels sont :
0 : Halt – le système s’arrête
1 ou Single – le système passe en mode single (mode de débugage)
2 : Runlevel par défaut sous debian – personnalisable
3 : personnalisable
4 : personnalisable
5 : X sous RedHat (Runlevel par défaut) – personnalisable
6 : Reboot

Commandes :

• chkconfig -l NomService : liste les  niveaux de démarrage du service
• chkconfig – – level 2345 NomService on
• chkconfig – -level 016 Nomservice off
• update-rc.d NomService remove : supprimme tous les liens des RCx.d
• update-rc.d Nomservice defaults : remet les liens par défaut tel que définis dans les entêtes LSB des scripts sous /etc/init.d
• update-rc.d NomService start NumBoot 2 3 4 5 . stop NumBoot 0 1 6 .

Attention : les entêtes LSB des scripts sous init.d imposent les runlevels de start ou de stop !

• update-rc.d NomService enable 2
• update-rc.d NomService disable 3 4 5
  sera préférable pour outrepasser les entêtes LSB

 

II- L’initialisation et le démarrage de UpStart :

UpStart a été développé par Scott James Remnant de Canonical (Ubuntu). UpStart a été implémenté la première fois dans Ubuntu 6 en 2006.

UpStart repose sur le principe des événements et fonctionne de manière asynchrone. Il gère le lancement et l’arrêt des services au démarrage et à l’arrêt de la machine et les supervise pendant que le système fonctionne. UpStart est censé remplacer cron, anacron, atd et inetd | xinetd.

NB : La plupart des services réagissent encore aux mots clés start et stop et sont gérés par les scripts RCx.D (pour des raisons de compatibilité …). La  notion de niveaux (runlevels) d’init est toujours présente bien qu’elle soit gérée par la notions d’évènements.

=> Principe de fonctionnement : 

Le service est démarré ou arrêté suite à la réception d’un évènement. Cette même action enclenche elle même un évènement qui avertira les autres services | programmes ou processus.

=> Les commandes d’UpStart :

• initctl list | sort
• initctl start | stop | restart | status NomDuService

Voici un exemple avec une Ubuntu 12, on peut toujours intialiser un service avec le script placé sous init.d mais celui ci lance automatiquement un job et les comandes initctl  fonctionnent très bien …

Le fichier de conf se trouve sous /etc/init/gdm.conf mais pour des raisons de compatibilité et de normalisation, il existe bien un script shell sous /etc/init.d/gdm …. Observez les lignes du script …

=> Les fichiers de conf :

• /etc/inittab n’est plus nécessaire
• /etc/init/ contient tous les fichiers de conf des services concernés et gérés par UpStart

Autre exemple, le runlevel du X par défaut sous RH/Centos 6 est 5, mais il est impossible de trouver un script gdm sous /etc/init.d ou dans les rcx.d … le job est géré par UpStart sous :

III- L’initialisation et le démarrage de SYSTEM DAEMON :

Dans SystemD, la notion de runlevels (niveaux) disparaît (elle peut être utilisée pour une raison de compatibilité) .
les commandes service et chkconfig sont remplacées par systemctl.

SystemD est asynchrone et basé sur la notion d’évènements.
Les évènements dans SustemD vont favoriser le démarrage, l’arrêt des services.
Pour rappel : les évènements sont signalés et gérés par le noyau. Les programmes peuvent s’enregistrer auprès de D-Bus* qui offre leurs services aux autres programmes et leur permet de savoir quels services sont disponibles et d’être informés des évènements signalés ! (ex: le branchement d’une clé..)
* D-Bus permet aux applications ou aux programmes de communiquer entre eux.

SystemD rend le démarrage plus rapide, les dépendances entre les services sont établies et le lancement en parallélisation de ces services est possible !

systemd est le tout premier processus PID N°1

Les évènements de SystemD sont :

• le démarrage du système
• le montage d’un volume
• la connexion à un port ou un socket (Un socket symbolise une prise par laquelle une application peut envoyer et recevoir des données, lancé par Berkeley Software Distribution au début des années 80) 
• la connexion/déconnexion d’un utilisateur
• l’ajout ou le retrait d’un device

En conclusion : System Daemon offre un framework optimisé pour la gestion des dépendances entre les services, et permet  le chargement en parallèle des services au démarrage, et de réduire la surcharge du shell

IV- Cas particulier RedHat | CentOs :

Sous RH, il existe un script /etc/rc.sysinit qui regroupe des fonctions importantes qui est lu une fois au démarrage de la machine et qui gère chronologiquement une liste d’actions importantes :
Il est activé par sysinit sous RH5 (/etc/inittab) et en tant que job (upStart)  sous RH6 (/etc/init/rcS.conf)

• Le nom du système est donné
• La sécurité SELinux se met en place
• Les fs /proc et /sys sont montés
• Initialise le matériel (modules chargés avec modprobe)
• configure les paramètres du noyau
• etc …

Michel BOCCIOLESI