Lorsqu'il démarre, init lit le fichier de configuration /etc/inittab. Pendant que le système tourne, il le relit si le signal HUP lui est envoyé6.2 ; ceci évite d'avoir à relancer le système pour que les modifications de configuration d'init prennent effet.
Le fichier /etc/inittab est un peu compliqué. Les lignes de /etc/inittab comprennent quatre champs délimités par des `:' :
id:runlevels:action:processusCes champs sont décrits ci-dessous. De plus,/etc/inittab peut contenir des lignes vides ou commençant par un dièse (`
#') ; dans
les deux cas, elles sont ignorées.
![\begin{dispitems}
\par\item[id]
Identifie la ligne dans le fichier. Pour les li...
...lancer qu'une fois.
\par\item[processus] La commande à exécuter.
\end{dispitems}](img45.gif)
Prenons un cas simple consistant à configurer les lignes concernant
getty. Pour lancer un getty sur le premier terminal virtuel
(/dev/tty1), et dans tous les niveaux d'exécution multi-utilisateurs
(2 - 5), on devra écrire la ligne suivante :
Le premier champ indique qu'il s'agit de la ligne pour /dev/tty1. Le
deuxième indique qu'elle s'applique aux niveaux d'exécution (runlevels) 2,
3, 4 et 5. Le troisième que la commande devra être relancée lorsqu'elle se
terminera (ainsi on peut se logger, se délogger et se relogger). Le dernier
champ est la commande qui lance getty sur le premier terminal
virtuel6.3.
Si l'on veut ajouter des terminaux ou un modem << dial-in >> à un système, on doit ajouter des lignes à /etc/inittab, une par terminal ou modem. Pour plus de détails, consultez les pages init(8), inittab(5), et getty(8).
Si une commande échoue lorsqu'elle est lancée, et qu'init est configuré pour la relancer, il utilisera beaucoup des ressources système : init la lance, elle échoue, init la lance, elle échoue, init la lance, elle échoue, et ainsi de suite, à l'infini. Pour empêcher cela, init garde la trace du nombre de tentatives et, si la fréquence augmente trop dans un court laps de temps, il attend cinq minutes avant de la relancer.