Handbook:SPARC/Working/Initscripts/fr

Runlevels

Démarrer le système

Pendant que le système démarre, beaucoup de texte va défiler. En regardant attentivement, vous pourriez apercevoir ce texte (généralement), le même à chaque fois que le système est redémarrer. L’enchaînement de toutes ces actions est appelée la séquence de démarrage et est (plus ou moins) statique.

D’abord, le programme d’amorçage va charger l’image du noyau définie dans sa configuration. Ensuite, il demandera aux CPU de lancer le noyau. Pendant que le noyau est chargé et lancé, il initialise toutes les structures spécifiques au noyaux, lance les tâches et démarre le processus init.

Le processus init s’assure que toutes les partitions (définies dans /etc/fstab) soient montées et prêtes à l’emploi. Ensuite, il lance de nombreux scripts localisés dans /etc/init.d/, lesquels vont lancer les services nécessaires pour un démarrage réussi du système.

Dernièrement, une fois tous les scripts exécutés, init active les consoles virtuelles accessibles via Ctrl+Alt+ F1, Ctrl+Alt + F2, etc. Attachant chacun à un processus spécial appelé agetty. Ce processus s’assure que les utilisateurs peuvent se connecter avec login.

Scripts d’initialisation

Les scripts dans /etc/init.d/ ne sont pas exécutés aléatoirement. init ne lance pas tous les scripts, seulement ceux dont il a été demandé de les lancer via /etc/runlevels/.

D’abord, init lance tous les scripts de /etc/init.d/ qui ont un lien symbolique dans /etc/runlevels/boot/. Généralement, il lancera les scripts dans l’ordre alphabétique, mais certains ont des informations de dépendance qui informeront le système que d’autres scripts doivent être lancés avant leur démarrage.

Une fois tous les scripts référencés dans /etc/runlevels/boot/ sont lancés, init va lancer ceux de /etc/runlevels/default/. À nouveau, l’ordre alphabétique sera utilisé pour décider lesquels lancer en premier, sauf si une information de dépendance vient modifier l’ordre valide de la séquence de démarrage. C’est pour cela que les commandes lors de l’installation de Gentoo Linux utilisent le runlevel default (i.e. rc-update add sshd default).

Fonctionnement d’init

Évidemment, init ne décide pas tout tout seul. Il a besoin d’un fichier de configuration qui lui indique les actions à mener. Le fichier /etc/inittab est utilisé par init pour déterminer cela.

Comme décrit ci-dessus, la 1re action d’init est de monter tous les systèmes de fichiers. Cela est défini par la ligne suivante de /etc/inittab :

si::sysinit:/sbin/openrc sysinit

Cette ligne demande à init de lancer obligatoirement /sbin/openrc sysinit pour initialiser le système. Le script /sbin/openrc s’occupe de l’initialisation, donc il pourrait être tentant de dire qu’init ne fait pas grand-chose – il délègue la tâche d’initialisation à un autre processus.

Dans un deuxième temps, init lance tous les scripts qui ont un lien symbolique dans /etc/runlevels/boot/. C’est défini avec la ligne suivante :

rc::bootwait:/sbin/openrc boot

À nouveau, le script OpenRC lance les tâches nécessaires. Notez que l’option donnée à OpenRC (« boot ») est la même que le sous-répertoire de /etc/runlevels/.

Maintenant, init vérifie son fichier de configuration pour analyser quel niveau de lancement (runlevel) il devrait lancer. Pour décider cela, il lit les lignes de /etc/inittab :

id:3:initdefault:

Dans cette situation (qui est celle de la majorité des utilisateurs de Gentoo), l’identifiant du niveau de lancement est 3. À partir de cette information, init identifie ce qu’il doit lancer pour démarrer au niveau 3 :

l0:0:wait:/sbin/openrc shutdown
l1:S1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6:6:wait:/sbin/openrc reboot

La ligne qui définit le niveau 3, à nouveau utilise le script OpenRC pour démarrer les services (maintenant avec l’argument default). Notez que l’option donnée à OpenRC (« boot ») est la même que le sous-répertoire de /etc/runlevels/.

Lorsqu’OpenRC a terminé, init décide quelles consoles virtuelles il doit activer et quelles commandes doivent être lancées dans chacune :

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Niveaux de lancement (runlevels) disponibles

Dans la section précédente, nous avons vu qu’init utilise un chiffre pour décider le niveau de lancement qu’il doit activer. Un niveau de lancement est un état dans lequel le système est démarré et contient un ensemble de scripts (unlevel scripts ou initscripts) qui doivent être lancés ou arrêtés pour un niveau de lancement.

Dans Gentoo, il y a sept niveaux de lancement définis : trois internes et quatre définis par l’utilisateur. Ceux internes sont sysinit, shutdown and reboot et font exactement ce que dit leur nom : initialiser, arrêter ou redémarrer le système.

Les niveaux de lancement définis par l’utilisateur sont ceux qui sont dans le sous-répertoire /etc/runlevels/ : boot, default, nonetwork et single. boot démarre tous les services systèmes nécessaires utilisés par les autres niveaux de lancement. Les trois autres diffèrent dans les services qui sont lancés. : default est pour l’usage quotidien, nonetwork est utilisable lorsqu’aucune connexion réseau n’est requise et single est usité lorsque le système doit être réparé.

Utiliser des scripts d’initialisation (initscripts)

Les scripts que le processus openrc lance sont appelés scripts d’initialisation (initscripts). Chaque script dans /etc/init.d/ peut être lancé avec le paramètre start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme ou wantsme.

Pour démarrer, arrêter ou relancer un service (et toutes ses dépendances), le paramètre start, stop ou restart doivent être utilisés :

Pour arrêter un service, mais pas ceux qui dépendent de lui, utilisez l’option --nodeps en même temps que stop :

Pour connaître le statut d’un service (démarré, arrêté...), utilisez le paramètre « status » :

Si le statut indique que le service est démarré alors qu’il ne l’est pas, il est possible de réinitialiser l’information du statut à « arrêté » avec le paramètre zap :

Pour savoir également quelles dépendances le service a, utilisez iwant, iuse ou ineed. Avec ineed, il est possible d’identifier les services qui ont vraiment besoin du service pour un fonctionnement correct. iwant ou iuse, dans un autre sens, montrent les services qui peuvent être utilisés par le service, mais ne sont pas nécessaires au fonctionnement correct dudit service.

Similairement, il est possible de demander quels services sont nécessaires pour un service (needsme) ou ceux qui l’utilisent (usesme ou wantsme) :

Mettre à jour les niveaux de lancement

rc-update

Le système d’initialisation Gentoo utilise un arbre de dépendances pour déterminer quel service doit être démarré en premier. Comme c’est une tâche rébarbative et que nous ne voulons pas que les utilisateurs aient à le faire manuellement, nous avons créé des outils qui simplifient l’administration des niveaux de lancement et des scripts init.

Avec rc-update, il est possible d’ajouter ou supprimer un script init d’un niveau de lancement. L’outil rc-update va automatiquement appeler le script depscan.sh pour reconstruire l’arbre de dépendances.

Ajouter et supprimer des services

Dans les instructions précédentes, les scripts init ont déjà été ajoutée au niveau de lancement default. Ce que default signifie est expliqué plus tôt dans cette page. Après le niveau de lancement, le script rc-update a besoin d’une deuxième paramètre qui définit une action : add, del ou show.

En plus du niveau de lancement, le script rc-update a besoin d’une deuxième paramètre qui définit une action : add, del ou show. Par exemple :

La commande rc-update -v show va montrer tous les scripts init et tous les niveaux de lancement dans lesquels il va s’exécuter :

Il est également possible de lancer rc-update show (sans -v) pour simplement voir les scripts init activé et leurs niveaux de lancement.

Configurer des services

Pourquoi une configuration supplémentaire est nécessaire

Les scripts init peuvent être complexes. Il n’est pas souhaitable que les utilisateurs les modifient directement, car cela pourrait les rendre plus sensibles aux erreurs. Cependant, il est important de configurer les services : par exemple, les utilisateurs pourraient vouloir lancer le service avec des options supplémentaires.

Une autre raison d’externaliser le configuration en dehors du script init est pour permettre de mettre à jour ce dernier sans écraser la configuration de l’utilisateur.

Le répertoire conf.d

Gentoo fournit une façon facile pour configurer un tel service : chaque script init peut être configuré avec un fichier dans /etc/conf.d/. Par exemple, le script init apache2 (appelé /etc/init.d/apache2) a un fichier de configuration appelé /etc/conf.d/apache2, lequel peut contenir les options pour le démarrage du serveur Apache 2.

APACHE2_OPTS="-D PHP5"

Un tel fichier de configuration contient seulement des variables (comme /etc/portage/make.conf le fait), rendant très simple le paramétrage des services. Il fournit aussi des informations sur les variables (en commentaire).

Écrire des scripts d’initialisation

Une autre ressource est le guide OpenRC des scripts de service.

Est-ce nécessaire ?

Non, écrire un script d’initialisation n’est généralement pas utile car Gentoo en fournit des prêts à l’emploi pour tous les services inclus. Cependant, certains utilisateurs pourraient souhaiter installer un service en dehors de Portage, dans ce cas, ils devront probablement créer un script d’initialisation.

N’utilisez pas de script d’initialisation s’il n’a pas explicitement été écrit pour Gentoo : les scripts d’initialisation Gentoo ne sont pas compatibles avec ceux d’autres distributions, sauf si cette dernière utilise OpenRC.

Structure

La structure basique pour un script d’initialisation est indique ci-dessous.

#!/sbin/openrc-run

depend(){
# (Information de dépendances)
}

start(){
# (Commandes nécessaires pour démarrer le service)
}

stop(){
# (Commandes nécessaires pour arrêter le service)
}

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="Démon MachinTruc"

description="MachinTruc est un démon qui boit"
extra_started_commands="boire"
description_boire="Ouvre la bouche et avale par réflexe"

depend(){
# (Information de dépendances)
}

start_pre(){
# (Commands necessary to prepare to start the service)
# Vérifier que le répertoire de sorti est bien configuré
checkpath--directory--ownermachin:machin--mode0775\
/var/run/machin/var/cache/machin
}

stop_post(){
# (Commandes nécessaires pour arrêter le service)
# Nettoyer ce qui est tombé à côté
rm-rf/var/cache/machin.*
}

boire(){
ebegin"Commencer à boire"
${command}--boirebière
eend$?"Échec à boire une bière :("
}

Chaque script d’initialisation nécessite une fonction start() or une variable commande command définie. Toutes les autres sections sont optionnelles.

depend(){
neednet
useloggerdns
providemta
}

depend(){
neednet
beforeinetd
beforexinetd
}

depend(){
before*
}

depend(){
needlocalmount
afterbootmisc
}

start(){
if["${RC_CMD}"="restart"];
then
# Do something in case a restart requires more than stop, start
fi

ebegin"Starting my_service"
start-stop-daemon--start--exec/path/to/my_service\
--pidfile/path/to/my_pidfile
eend$?
}

stop(){
ebegin"Stopping my_service"
start-stop-daemon--stop--exec/path/to/my_service\
--pidfile/path/to/my_pidfile
eend$?
}

start(){
ebegin"Starting my_script"
start-stop-daemon--start--exec/path/to/my_script\
--pidfile/path/to/my_pidfile--namefoo
eend$?
}

extra_started_commands="restartdelay"

restartdelay(){
stop
sleep3# Wait 3 seconds before starting again
start
}

(Partial sample Output)
 acpid | offline
 domainname | offline
 local | offline
 net.eth0 |

rc_hotplug="net.wlan !net.*"

• Handbook