web-dev-qa-db-fra.com

Comment systemd utilise-t-il les scripts /etc/init.d?

Je viens de passer à Debian Jessie, et la plupart des choses fonctionnent bien, y compris mon gestionnaire d'affichage graphique wdm.

Le fait est que je ne comprends tout simplement pas comment cela fonctionne. Évidemment, mon /etc/init.d/wdm le script est appelé, car lorsque j'y mets un exit précoce, wdm n'est pas démarré. Mais lorsque je renomme le répertoire /etc/rc3.d (mon niveau d'exécution par défaut était 3), wdm est toujours démarré.

Je n'ai pas pu découvrir comment systemd trouve ce script et je ne comprends pas ce qu'il fait à tous les autres scripts init.d.

  • Quand et comment systemd exécute-t-il des scripts init.d?
  • À long terme, dois-je me débarrasser de tous les scripts init.d?
systemdinit-scriptinitsysvinit
131
Martin Drautzburg

la réponse du chaos est ce que la documentation dit. Mais ce n'est pas ce que fait réellement systemd. (Ce n'est pas non plus ce que van Smoorenburg rc a fait. Le van Smoorenburg rc très certainement n'a pas ignorer les en-têtes LSB, que insserv utilisait pour calculer les ordres statiques, pour les démarreurs.) La documentation Freedesktop, telle que cette page "Incompatibilités", est en fait fausse, sur ces points et sur d'autres. (La variable d'environnement HOME en fait est souvent définie, par exemple. Cela est resté complètement sans documentation n'importe où pendant longtemps. Il est maintenant documenté dans le manuel, au moins, mais cette page WWW Freedesktop n'a toujours pas été corrigée.)

Le format de service natif pour systemd est l'unité de service . La gestion des services de systemd proprement dite fonctionne uniquement en termes de ceux qu'elle lit dans l'un des neuf répertoires où (à l'échelle du système) .service les fichiers peuvent vivre. /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system et /usr/lib/systemd/system sont quatre de ces répertoires.

La compatibilité avec les scripts van Smoorenburg rc est obtenue avec un programme de conversion nommé systemd-sysv-generator. Ce programme est répertorié dans le répertoire /usr/lib/systemd/system-generators/ et est donc exécuté automatiquement par systemd au début du processus bootstrap à chaque démarrage, et à chaque fois que systemd est chargé de charger sa configuration plus tard.

Ce programme est un générateur , un type d'utilitaire auxiliaire dont le travail consiste à créer des fichiers d'unité de service à la volée, dans un tmpfs où trois autres de ces neuf les répertoires (qui sont destinés à être utilisés uniquement par les générateurs) sont localisés. systemd-sysv-generator génère les unités de service qui exécutent les scripts van Smoorenburg rc à partir de /etc/init.d, s'il ne trouve pas une unité de service systemd native de ce nom qui existe déjà dans le six autres emplacements.

la gestion des services systemd ne connaît que les unités de service. Ces unités de service (re) générées automatiquement sont écrites pour appeler les scripts van Smoorenburg rc. Ils ont entre autres:

[Unité] 
 SourcePath =/etc/init.d/wibble 
 [Service] 
 ExecStart =/etc/init.d/wibble start 
 ExecStop =/etc/init.d/wibble stop

La sagesse reçue est que les scripts de van Smoorenburg rc doivent avoir un en-tête LSB et sont exécutés en parallèle sans respecter les priorités imposées par le système /etc/rc?.d/. C'est incorrect sur tous les points.

En fait, ils n'ont pas besoin d'avoir un en-tête LSB, et s'ils ne le font pas systemd-sysv-generator peut reconnaître les anciens en-têtes de commentaires RedHat plus limités (description:, pidfile:, et ainsi de suite). De plus, en l'absence d'un en-tête LSB, il reviendra au contenu des fermes de liens symboliques /etc/rc?.d, en lisant les priorités encodées dans les noms de liens et en construisant une commande avant/après, en sérialisant les services . Non seulement les en-têtes LSB ne sont pas une exigence, et non seulement ils codent eux-mêmes avant/après les commandes qui sérialisent les choses dans une certaine mesure, le comportement de secours en leur absence complète est en fait un fonctionnement considérablement non parallélisé.

La raison pour laquelle /etc/rc3.d ne semble pas avoir d'importance est que ce script a probablement été activé via un autre répertoire /etc/rc?.d/. systemd-sysv-generator traduit être répertorié dans l'un des /etc/rc2.d/, /etc/rc3.d/ et /etc/rc4.d/ en une relation native Wanted-By à systemd multi-user.target. Les niveaux d'exécution sont "obsolètes" dans le monde systemd, et vous pouvez les oublier.

Lectures complémentaires

176
JdeBP

Systemd est rétrocompatible avec les scripts d'initialisation SysV. Selon LSB 3.1, le script d'initialisation doit avoir des informations Conventions de commentaire , définissant quand le script doit démarrer/arrêter et ce qui est nécessaire pour que le script démarre/s'arrête. Ceci est un exemple:

### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop service my-service
# Description: my-service blah blah ...
### END INIT INFO

Il s'agit d'une section commentée qui est ignorée par SysV. D'un autre côté, systemd lit ces informations de dépendance et exécute ces scripts en fonction de cela.

Mais il y a un point, où systemd et SysV diffèrent en termes de scripts d'initialisation. SysV exécute les scripts dans un ordre séquentiel en fonction de leur numéro dans le nom de fichier. Systemd ne le fait pas. Si les dépendances sont respectées, systemd exécute les scripts immédiatement, sans respecter la numérotation des noms de script. Certains d'entre eux échoueront très probablement à cause de la commande. Il y a beaucoup d'autres incompatibilités à considérer.

S'il existe des scripts d'initialisation et des fichiers .service pour le même service, systemd exécutera les deux, dès que les dépendances seront satisfaites (dans le cas du script d'initialisation, celles définies dans l'en-tête LSB).

19
chaos