Comment est responsable d'afficher `Démarrage… [ok]`

Lorsque je lance un service tel que:

root@foo [~]# service foobar stop
Stopping Foobar:                                       [  OK  ]

Je peux voir un indicateur de statut: [ OK ]différent de celui visible sur /var/log/boot.log:

[  OK  ] Started LSB: disk temperature monitoring daemon.
...

Ou même différent de:

* /proc is already mounted
* Caching service dependencies ...        [ ok ]

Dans ces trois exemples, quel processus est responsable de l'affichage et du démarrage des démons? Dit autrement, quelle bibliothèque est utilisée pour afficher [ OK ], [FAILED]?

Lorsqu'un appel manuel de serviceexécute un script de style SysV à partir de /etc/init.d ou /etc/rc.d, toutes les sorties de statut dépendent entièrement de ce script.

Les scripts init.d correctement écrits utiliseront une bibliothèque de fonctions shell fournies par la distribution. Par exemple, dans Debian, la plupart des scripts chargent (source) le fichier /lib/lsb/init-functionset appellent simplement les fonctions fournies de la manière suivante:

case "$ 1" dans
  début)
    log_daemon_msg "À partir de $ DESC" "$ NAME"
    do_start
    case "$?" dans
        0 | 1) log_end_msg 0 ;;
        2) log_end_msg 1 ;;
    esac
    ;;
  [...]
esac

Voici la liste des fonctions standard définies par LSB. (Notez que les distributions peuvent fournir des fonctions supplémentaires allant au-delà de la norme, comme dans l'exemple ci-dessus. Notez également que, par exemple, OpenRC ou Arch Linux ne sont pas compatibles LSB et utilisent des styles totalement différents.)

En fait, certaines distributions fourniront ce code standard de manière centralisée, et tout ce qui reste au script init.d est à mettre en œuvre do_start. (Voir les /lib/init/init-d-scriptexemples OpenRC et Debian de Gentoo ). Cependant, ce n'est pas une fonctionnalité LSB "standard" - les scripts essayant d'être compatibles avec LSB doivent toujours le faire manuellement.

Note: Je souligne « correctement écrit » parce que vraiment il n'y a rien qui forcera un script init.d d'utiliser ces fonctions, autres que la surveillance humaine. Si le script veut signaler le statut via plain echo(ou via cowsayd'ailleurs), il est toujours en mesure de le faire. Ceci est particulièrement un problème avec les logiciels commerciaux distribués en dehors des canaux normaux: leur sortie d'état n'a jamais l' air tout à fait juste (et franchement, le script init.d dans son ensemble ne se comporte jamais tout à fait bien).

Pendant ce temps, lorsque les scripts SysV sont appelés au cours du processus de démarrage , le résultat dépend encore plus de la distribution - vous verrez parfois les résultats directement à partir des scripts eux-mêmes, mais parfois, le système init "principal" fournira son propre statut pour tous les services. il commence. ( Exemple: les anciens scripts d'initialisation de Linux, lors du démarrage d'un service en arrière-plan.)

Mais votre 2ème exemple n'est en réalité pas un init de style SysV - c'est systemd (il se trouve que c'est le début d'un script init.d 'hérité' dans votre exemple). Systemd est un gestionnaire de service complet qui utilise des configurations de service (et non des scripts). Par conséquent, toutes les sorties d'état de démarrage / arrêt sont fournies par Systemd lui-même. Cela s'applique également à la plupart des autres "gestionnaires de services", y compris init-ng, SMF ou Upstart.

Cela provient de scripts d'initialisation dépendants de la distro. Vérifiez le contenu du serviceprogramme, il s'agit probablement d'un script shell appelant des scripts de gestion sous-jacents (SysV sont considérés comme obsolètes maintenant) ou des fichiers binaires (systemd est la voie à suivre). C'est l'un des pros de systemd - vous n'obtiendrez pas de réponses "ça dépend".