Page précédente Page suivante Table des matières

3. L'init de la Red Hat.

3.1 Niveaux d'exécution System V

À tout moment, votre système Linux se trouve à un niveau d'exécution donné. La distribution Red Hat en définit 7 :

Comme on peut le voir, un niveau d'exécution est donc un état d'init et du système qui définissent quels sont les services qui s'exécutent.

Lors de la phase de démarrage, init doit savoir à quel niveau placer le système. Pour cela, il recherche dans le fichier /etc/inittab la ligne qui configure ce niveau par défaut :

id:3:initdefault:

signifie que le système démarrera en Mode multi-utilisateurs complet. (ce serait une grosse bêtise de choisir les niveaux 0 ou 6 comme niveaux par défaut !!!).

Vous remarquerez que la sortie de la commande ps ci-dessus indiquait qu'init avait démarré le système en niveau 3. Toutefois, cette fonctionnalité n'est pas disponible par défaut dans toutes les distributions : la même ligne pour une Debian aurait donné :

USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
root         1  0.1  0.4   740   384  ?  S    17:12   0:04 init 

Mis nous verrons ci-dessous qu'il existe une commande permettant de connaître à la fois le niveau d'exécution courant et celui qui l'a précédé.

3.2 La commande telinit

On peut changer de niveau d'exécution grâce à la commande telinit (qui n'est qu'un lien sur init) :

# telinit 2

placera le système en Mode multi-utilisateurs sans réseau. Bien entendu, seul l'administrateur système (root) peut exécuter cette commande...

Si l'on consulte la page man de telinit (c'est la même que celle d'init, on note que la première possède des options supplémentaires. Une lecture attentive nous apprend ainsi que telinit permet de demander à init de passer dans un niveau n (avec n compris entre 0 et 6) : c'est ce que nous écrivions plus haut.

Mais telinit dispose de fonctionnalités supplémentaires : il permet de demander à init effectuer une relecture de /etc/inittab, ce qui est pratique après une modification de ce fichier grâce à la commande

# telinit q

alors, qu'on ne me parle plus de la nécessité de redémarrer sa machine après une modification des scripts de démarrage !

Il dispose aussi de plusieurs autres optionsé : toutes ont pour but d'indiquer à init de réaliser une certaine tâche. Nous ne les traiterons pas ici et laissons le soin au lecteur curieux de lire la page de manuel.

3.3 Connaître le niveau d'exécution courant

En réalité, il existe plus que 7 niveaux d'exécution : la commande man init nous apprend en effet qu'il existe aussi les niveaux 7, 8 et 9 (non documentés) et S (ou s) qui correspond au mode mono-utilisateur.

La plupart des Unix utilisent une version de la commande who qui permet d'indiquer le niveau d'exécution courant :

# who -r
. run level 3   Oct 17 18:00  3  0  S

Cette sortie indique que le 17 Octobre, le système est passé du niveau de fonctionnement S au niveau 3. Le 0 indique que ce passage s'est effectué du premier coup.

Malheureusement, l'option -r n'est pas disponible sous linux... Aussi, il faut utiliser une autre commande pour avoir cette information :

# runlevel
runlevel
N 2

Indique que le système est au niveau 2 et qu'il n'y a pas de niveau précédent.

# telinit 3
# runlevel
2 3

Ici, on est passé au niveau 3, le niveau précédent était le niveau 2.

Comme nous l'avons vu plus haut, la ligne de la commande ps aux concernant init renseigne aussi sur le niveau courant, mais pas dans toutes les distributions.

3.4 Le fichier /etc/inittab

Lorsqu'il démarre, init lit le fichier /etc/inittab ligne par ligne (si on modifie ce dernier, ce n'est pas la peine de rebooter comme sous MS-DOS après toute modification de CONFIG.SYS et/ou AUTOEXEC.BAT, il suffit d'envoyer un signal HUP à init pour le forcer à le relire avec la commande 

# kill -HUP 1 

ou

kill -s HUP 1

Le fichier /etc/inittab est un fichier texte composé de lignes de commentaires (commençant par #) et d'entrées constituées de 4 champs délimités par des deux-points, elles sont de la forme :

code:niveaux:action:processus

Un examen de votre /etc/inittab vous montrera que celui-ci est divisé en un certain nombre de sections délimitées par des commentaires.

Notez, qu'à part modifier le niveau d'exécution par défaut et la commande associée à CTRL-ALT-SUPPR, il y a peu de raisons pour lesquelles vous serez amené à modifier ce fichier.

3.5 Les scripts d'initialisation de /etc/rc.d

L'étude de /etc/inittab nous a montré qu'init lançait des programmes se trouvant dans le répertoire /etc/rc.d. Ce sont les fameux scripts d'initialisation dont nous parlions dans l'introduction. Par exemple, la ligne :

l2:2:wait:/etc/rc.d/rc 2

signifie qu'init doit lancer le script /etc/rc.d/rc en lui passant 2 en paramètre à chaque fois qu'on entre dans le niveau 2 et qu'il doit attendre la terminaison de ce script avant de poursuivre.

La ligne :

si::sysinit:/etc/rc.d/rc.sysinit

signifie qu'init doit lancer le script /etc/rc.d/rc.sysinit lors de l'initialisation du système, quel que soit le niveau d'exécution.

Un examen de ce répertoire nous donne quelque chose comme :

# ls -l /etc/rc.d
drwxr-xr-x   2 root     root         1024 jui 31 19:30 init.d
-rwxr-xr-x   1 root     root         1593 jun  2 19:59 rc
-rwxr-xr-x   1 root     root          690 jun  2 19:59 rc.local
-rwxrwx---   1 news     news         2083 jun 13 15:28 rc.news
-rwxr-xr-x   1 root     root         6697 jun  2 19:59 rc.sysinit
drwxr-xr-x   2 root     root         1024 jui 31 19:30 rc0.d
drwxr-xr-x   2 root     root         1024 jui 31 19:30 rc1.d
drwxr-xr-x   2 root     root         1024 jui 31 19:30 rc2.d
drwxr-xr-x   2 root     root         1024 jui 31 19:30 rc3.d
drwxr-xr-x   2 root     root         1024 jui 31 19:30 rc4.d
drwxr-xr-x   2 root     root         1024 jui 31 19:30 rc5.d
drwxr-xr-x   2 root     root         1024 jui 31 19:30 rc6.d

ce qui nous enseigne que ce répertoire ne contient que 4 fichiers exécutables : rc, rc.local, rc.news et rc.sysinit (le rc.news n'existera peut être pas sur votre système si vous ne l'avez pas configuré comme serveur Usenet).

rc.local, comme son nom l'indique est « local » à votre machine : c'est là que vous ajouterez les commandes d'initialisation propres à votre système. rc.local est appelé en dernier, c'est-à dire après tous les autres scripts. Par défaut, sur mon système, il se contente de laisser un message indiquant la version Red Hat et celle du noyau dans le fichier /etc/issue, à partir des informations qu'il tire du système. Ce fichier, s'il existe, est affiché automatiquement avant l'invite de login.

rc.news, s'il existe, lance les démons nécessaires au serveur de news.

rc.sysinit, on l'a vu, est le script qui est lancé lors de l'initialisation du système, il sert à configurer la variable d'environnement PATH au niveau du système, à activer le swap, à configurer le nom de la machine avec la commande hostname, à lancer les commandes de vérification des systèmes de fichiers, à les monter, à activer les modules si ceux-ci sont utilisés, etc. Parcourez-le, cela vous donnera envie de connaître la syntaxe du shell...

rc, on l'a vu aussi, est appelé par init avec un paramètre correspondant au niveau d'exécution dans lequel on entre. Ce paramètre est récupéré par le script rc pour former un nom de répertoire. Par exemple, l'appel /etc/rc.d/rc 2 fera que rc ira examiner le répertoire /etc/rc.d/rc2.d. Un examen du code de rc montre qu'il exécute alors d'abord les scripts de ce répertoire dont le nom commence par K, puis ceux dont le nom commence par S. Le rôle de rc est donc surtout un rôle d'aiguillage et d'exécution d'autres scripts.

3.6 Les scripts d'initialisation de /etc/rc.d/rcn.d

Examinons, par exemple, le contenu du répertoire /etc/rc.d/rc2.d, examiné par le script /etc/rc.d/rc lorsqu'il est appelé par init lorsque le système entre dans le niveau d'exécution 2 :

$ ls -l /etc/rc.d/rc2.d
total 0
lrwxrwxrwx   1 root     root           18 jun 12 12:02 K10pnserver -> ../init.d/pnserver
lrwxrwxrwx   1 root     root           15 jun 12 12:02 K15sound -> ../init.d/sound
lrwxrwxrwx   1 root     root           17 jun 12 12:02 K20rusersd -> ../init.d/rusersd
lrwxrwxrwx   1 root     root           15 jun 12 12:02 K20rwhod -> ../init.d/rwhod
lrwxrwxrwx   1 root     root           14 jun 12 12:00 K25innd -> ../init.d/innd
lrwxrwxrwx   1 root     root           14 jun 12 12:01 K50inet -> ../init.d/inet
lrwxrwxrwx   1 root     root           16 jun 12 12:02 K55routed -> ../init.d/routed
lrwxrwxrwx   1 root     root           13 jun 12 11:58 K60atd -> ../init.d/atd
lrwxrwxrwx   1 root     root           15 jun 12 12:00 K95nfsfs -> ../init.d/nfsfs
lrwxrwxrwx   1 root     root           17 jun 12 12:01 S01kerneld -> ../init.d/kerneld
lrwxrwxrwx   1 root     root           17 jun 12 12:00 S10network -> ../init.d/network
lrwxrwxrwx   1 root     root           16 jun 12 12:00 S20random -> ../init.d/random
lrwxrwxrwx   1 root     root           16 jun 12 12:02 S30syslog -> ../init.d/syslog
lrwxrwxrwx   1 root     root           15 jun 12 12:04 S40crond -> ../init.d/crond
lrwxrwxrwx   1 root     root           13 jun 12 12:01 S60lpd -> ../init.d/lpd
lrwxrwxrwx   1 root     root           18 jun 12 12:00 S75keytable -> ../init.d/keytable
lrwxrwxrwx   1 root     root           18 jun 12 12:02 S80sendmail -> ../init.d/sendmail
lrwxrwxrwx   1 root     root           13 jun 12 11:59 S85gpm -> ../init.d/gpm
lrwxrwxrwx   1 root     root           11 jun 12 12:00 S99local -> ../rc.local

Comme on le voit, il ne contient que des liens vers des fichiers du répertoire /etc/rc.d/init.d/ (sauf S99local, qui pointe vers /etc/rc.d/rc.local).

Ces liens sont de deux types, ceux dont le nom commence par K (comme Kill : arrêter), ceux dont le nom commence par S (Start : démarrer). Comme nous l'avons vu, /etc/rc.d/rc exécute en premier ceux dont le nom commence par K (en fait, il les exécute dans l'ordre dans lequel ils apparaissent avec la commande ls...). L'ordre est réglé entre les liens par le biais d'une numérotation : ainsi, pour assurer que /etc/rc.d/rc.local soit lancé en dernier, on met 99 derrière le S (ce qui suit ces 3 caractères a peu d'importance, ce lien aurait pu se nommer S99toto : tout ce qui compte, c'est l'ordre d'apparition).

Quand le système entre dans le niveau d'exécution 2, init, par le biais de la commande /etc/rc.d/rc 2, exécute la commande /etc/rc.d/rc2.d/K10pnserver stop. Cela est réalisé par les lignes suivantes :

# Lancer d'abord les scripts KILL
  for i in /etc/rc.d/rc$runlevel.d/K*; do
      # Verifie si le script existe
      [ ! -f $i ] && continue

      # Verifie si le sous-systeme est deja lance
      subsys=${i#/etc/rc.d/rc$runlevel.d/K??}
      [ ! -f /var/lock/subsys/$subsys ] && \
         [ ! -f /var/lock/subsys/${subsys}.init ] && continue

      # Arrete le sous-systeme
      $i stop
  done

Avec notre exemple, la variable i prendra successivement tous les noms des fichiers /etc/rc.d/rc2.d/K*, après avoir testé que le sous-système a bien été lancé, la commande $i stop lancera le script en lui passant l'argument stop. On pourra vérifier que le traitement des liens dont le nom commence par S suit la même démarche sauf qu'il vérifie que le service n'est pas déjà lancé et que c'est l'argument start qui est passé au script.

Le but du répertoire /etc/rc.d/rc2.d/ est donc simplement d'indiquer quels sont les scripts à stopper et à lancer lorsqu'on entre dans le niveau 2. Pour stopper un service supplémentaire, il suffit de créer un lien dont le nom commence par K dans ce répertoire. Après le K, on choisi un numéro pour qu'il soit placé en bonne place, et généralement le nom du service concerné. Ce lien doit alors pointer vers le véritable script se trouvant dans /etc/rc.d/init.d.

Par exemple, ln -s /etc/rc.d/init.d/toto /etc/rc.d/rc2.d/K12toto fera qu'à la prochaine entrée en niveau 2, init arrêtera le service toto après avoir arrêté le service pnserver et avant d'arrêter le service sound. La même démarche s'applique pour le lancement de services supplémentaires.

On notera que Linux dispose d'interfaces graphiques permettant de « faciliter » ces ajouts/suppressions : l'outil tksysv de Red Hat, les outils graphiques de KDE et Gnome, Linuxconf.

Les répertoires /etc/rc.d/rc0.d et /etc/rc.d/rc6.d sont particuliers puisqu'ils correspondent respectivement à l'entrée dans le niveau de mise hors service et dans le niveau de redémarrage. L'examen du premier vous montrera qu'il ne comporte que de liens K et un seul lien S : S00halt. C'est logique, car la mise hors service doit commencer par arrêter tous les services en cours, puis lancer la routine d'arrêt du système. De même, rc6.d contient des liens K et un lien vers le script de redémarrage (S00reboot).

En fait, cette méthode peut sembler lourde alors qu'elle est finalement d'une simplicité à toute épreuve : à part rc.local, tous les scripts sont regroupés dans le répertoire /etc/rc.d/init.d et on décide dans le répertoire associé au niveau n (/etc/rc.d/rcn.d) des scripts qu'il faut lancer et de ceux qu'il faut arrêter...

3.7 Les scripts d'initialisation de /etc/rc.d/init.d

Examinons le contenu de ce répertoire :

$ ls -l /etc/rc.d/init.d
total 38
-rwxr-xr-x   1 root     root          884 mai  5 18:19 atd
-rwxr-xr-x   1 root     root          883 mai  6 01:29 crond
-rwxr-xr-x   1 root     root         3375 jun  2 19:59 functions
-rwxr-xr-x   1 root     root         1073 mai  8 05:59 gpm
-rwxr-xr-x   1 root     root         1351 jun  2 19:59 halt
-rwxr-xr-x   1 root     root         1509 mai  6 01:25 inet
-rwxr-x---   1 root     root         1510 jun 10 12:33 innd
-rwxr-xr-x   1 root     root          780 mai  2 00:21 kerneld
-rwxr-xr-x   1 root     root          903 mai  7 16:39 keytable
-rwxr-xr-x   1 root     root          447 jun  2 19:59 killall
-rwxr-xr-x   1 root     root         1015 mai  6 01:24 lpd
-rwxr-xr-x   1 root     root         4398 jun  2 19:59 network
-rwxr-xr-x   1 root     root         1299 jun  2 19:59 nfsfs
-rwxr-xr-x   1 root     root         1036 avr  6 00:15 pnserver
-rwxr-xr-x   1 root     root         1535 jun  2 19:59 random
-rwxr-xr-x   1 root     root         1138 mai 11 01:58 routed
-rwxr-xr-x   1 root     root          773 mai  6 05:18 rusersd
-rwxr-xr-x   1 root     root          780 mai  6 01:27 rwhod
-rwxr-xr-x   1 root     root          921 dec 31  1997 sendmail
-rwxr-xr-x   1 root     root          906 jun  2 19:59 single
-rwxr-xr-x   1 root     root         1372 mai  6 01:26 sound
-rwxr-xr-x   1 root     root          799 avr 30 07:53 syslog

Les voici, nos fameux scripts ! Le contenu de ce répertoire varie en fonction des paquetages installés.

Examinons, par exemple, le script inet :

$ less inet

#! /bin/sh
#
# inet          Start TCP/IP networking services. This script
#               sets the hostname, creates the routes and
#               starts the Internet Network Daemon & RPC portmapper.

Le début de chaque script commence par indiquer les services qu'il assure : ici, celui des services TCP/IP, la configuration du nom de la machine, etc.

# See how we were called.
case "$1" in
  start)
        echo -n "Starting INET services: "
        daemon inetd

        echo
        touch /var/lock/subsys/inet
        ;;
  stop)
        # bringing down NFS filesystems isn't inet's problem I don't know 
        # why this script used to do that -- ewt

        echo -n "Stopping INET services: "
        killproc inetd

puis, le script regarde avec quel paramètre il a été appelé : start, auquel cas il lance le programme assurant le service pour lequel il a été conçu (ici, avec la commande daemon inetd), ou stop auquel cas, il stoppe ce service (avec la commande killproc inetd).

Certains scripts acceptent d'autres paramètres : restart par exemple, combine un appel avec stop et un appel avec start.

3.8 Conclusion sur l'init System V

Voilà, vous connaissez l'essentiel du mécanisme de démarrage/arrêt des services avec l'init de System V. Si vous vous rendez compte qu'un service ne fonctionne pas : cron, par exemple, assurez-vous qu'un lien S vers le script cron existe bien dans le répertoire correspondant au niveau d'exécution dans lequel vous travaillez. Si ce n'est pas le cas, créez-le. Pour son arrêt, ajoutez un lien K dans rc6.d et rc0.d afin que le service cron ne soit stoppé qu'au moment de l'arrêt/redémarrage du système. Bien entendu, le script cron doit exister dans /etc/rc.d/init.d... si ce n'est pas le cas, c'est probablement que vous n'avez pas installé le paquetage correspondant à ce service (vixie-cron-3.0.1-*, dans le cas de cron et d'un Red Hat).

Après tout ajout, pensez à relancer init, ou faites-le à la main avec une commande comme ./etc/rc.d/init.d/crond start. Vérifiez avec une commande comme ps aux | egrep [c]rond que le service est bien lancé.

Passons maintenant à l'init de la distribution Slackware.


Page précédente Page suivante Table des matières