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

Le truc, c'est que je ne comprends tout simplement pas comment cela fonctionne. Évidemment mon /etc/init.d/wdm le script est appelé, car lorsque je mets une exit précoce là-dedans, wdm n'est pas démarré. Mais quand je renomme alternativement le /etc/rc3.d répertoire (mon niveau d'exécution par défaut était 3), alors wdm est toujours démarré.

Je n'ai pas pu savoir 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 les scripts init.d ?
• À long terme, dois-je me débarrasser de tous les scripts init.d ?

Réponse acceptée :

la réponse du chaos est ce que disent certains documents. Mais ce n'est pas ce que systemd fait réellement. (Ce n'est pas ce que van Smoorenburg rc a fait non plus. Le van Smoorenburg rc très certainement pas ignorer les en-têtes LSB, qui insserv utilisé pour calculer les commandes statiques, pour commencer.) La documentation Freedesktop, telle que cette page "Incompatibilités", est en fait erronée, sur ces points et sur d'autres. (Le HOME variable d'environnement en fait est souvent fixé, par exemple. Cela est resté totalement sans papiers pendant longtemps. C'est maintenant documenté dans le manuel, au moins, mais cette page WWW de 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'il lit à partir de 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 van Smoorenburg rc scripts est réalisé avec un programme de conversion, nommé systemd-sysv-generator . Ce programme est listé dans le /usr/lib/systemd/system-generators/ répertoire et est donc exécuté automatiquement par systemd au début du processus d'amorçage à chaque démarrage, et à nouveau chaque fois que systemd reçoit l'instruction de recharger sa configuration ultérieurement.

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ù se trouvent trois autres de ces neuf répertoires (qui sont destinés à être utilisés uniquement par les générateurs). systemd-sysv-generator génère les unités de service qui exécutent le van Smoorenburg rc scripts de /etc/init.d , s'il ne trouve pas d'unité de service systemd native de ce nom existant déjà dans les six autres emplacements.

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

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

Connexe :Ubuntu – Comment exécuter des scripts .sh ?

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

En fait, ils n'ont pas besoin d'avoir un en-tête LSB, et s'ils n'en ont 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'en-tête LSB, il reviendra au contenu de /etc/rc?.d fermes de liens symboliques, lisant les priorités encodées dans les noms de liens et construisant un ordre avant/après à partir d'eux, sérialisant les services. Non seulement les en-têtes LSB ne sont pas une exigence, et non seulement ils encodent eux-mêmes les commandes avant/après qui sérialisent les choses dans une certaine mesure, mais le comportement de repli en leur absence totale est en fait une opération significativement non parallélisée.

La raison pour laquelle /etc/rc3.d n'a pas semblé important, c'est que vous avez probablement activé ce script via un autre /etc/rc?.d/ annuaire. systemd-sysv-generator se traduit par être répertorié dans l'un des /etc/rc2.d/ , /etc/rc3.d/ , et /etc/rc4.d/ dans un Wanted-By natif relation avec multi-user.target de systemd . Les niveaux d'exécution sont "obsolètes" dans le monde systemd, et vous pouvez les oublier.

Autres lectures

• systemd-sysv-generator . pages de manuel systemd. Freedesktop.org.
• "Variables d'environnement dans les processus engendrés". systemd.exec . pages de manuel systemd. Freedesktop.org.
• https://unix.stackexchange.com/a/394191/5132
• https://unix.stackexchange.com/a/204075/5132
• https://unix.stackexchange.com/a/196014/5132
• https://unix.stackexchange.com/a/332797/5132