Déjà update-rc.d, je suppose que c'est celui de Debian, je me rappelle que quand je l'avais testé, je l'avais trouvé pas pratique au possible. Par exemple on est obligé de fournir un ordre d'execution pour ajouter un service à un runlevel. Quand on a pas idée de ce à quoi ça correspond ou de ce qu'il faut mettre, c'est lourd; le chkconfig de RedHat gérait ça tout seul depuis longtemps et était bien plus pratique.
En ce qui concerne gentoo, ils ont eu l'audace de casser le système habituel (type Système V il me semble) et d'en faire un mieux. Les runlevels normaux (0 à 6 + S etc) existent toujours mais ne sont pas utilisés tels quels. On a à la place des runlevels virtuels qui ont un nom explicite que l'on peut choisir : boot, default, nonet, single; et chacun a une liste de services associée.
Là où c'est fort, c'est que les dépendances sont explicitement définies entre les services, ce qui fait qu'ils démarrent automatiquement dans l'ordre requis. Et en cas de changement de runlevel, les services qui ne font plus partie du nouveau runlevel sont automatiquement arrêtés. Fini les SXXservice et KXXservice, ça marche tout seul.
En pratique les anciens runlevels sont associés aux nouveaux, par exemple le 3 correspont à default, le 2 à nonet, etc, ce qui permet de choisir un runlevel au boot en passant à init un numéro (via les paramètres du noyau) comme avant, et d'avoir par la suite plus que les 6 runlevels habituels.
[^] # Re: runlevels
Posté par Sixtiz . En réponse au journal Ubuntu : peut mieux faire. Évalué à 7.
En ce qui concerne gentoo, ils ont eu l'audace de casser le système habituel (type Système V il me semble) et d'en faire un mieux. Les runlevels normaux (0 à 6 + S etc) existent toujours mais ne sont pas utilisés tels quels. On a à la place des runlevels virtuels qui ont un nom explicite que l'on peut choisir : boot, default, nonet, single; et chacun a une liste de services associée.
Là où c'est fort, c'est que les dépendances sont explicitement définies entre les services, ce qui fait qu'ils démarrent automatiquement dans l'ordre requis. Et en cas de changement de runlevel, les services qui ne font plus partie du nouveau runlevel sont automatiquement arrêtés. Fini les SXXservice et KXXservice, ça marche tout seul.
En pratique les anciens runlevels sont associés aux nouveaux, par exemple le 3 correspont à default, le 2 à nonet, etc, ce qui permet de choisir un runlevel au boot en passant à init un numéro (via les paramètres du noyau) comme avant, et d'avoir par la suite plus que les 6 runlevels habituels.