J'ai lu ce qu'est multi-user.target et la documentation systemd, qui indique que multi-user.target est une cible spéciale. De plus, beaucoup d'exemples systemd contiennent cette ligne.
- Pourquoi tant d'exemples de services contiennent-ils cette ligne ?
- Que se passerait-il s'ils ne contenaient pas WantedBy=multi-user.target ?
- Pourriez-vous me donner un exemple de cas où il serait en fait conseillé de ne pas inclure cette ligne dans une définition de fichier de service ?
- Dans le même ordre d'idées, quand est-il judicieux de conserver cette ligne ?
Réponse acceptée :
1.) multi-user.target est fondamentalement l'équivalent le plus proche du niveau d'exécution classique SysVinit 3 que systemd possède. Lorsqu'un systemd le système démarre, systemd essaie de faire correspondre l'état du système à l'état spécifié par default.target – qui est généralement un alias pour graphical.target ou multi-user.target .
multi-user.target définit normalement un état du système où tous les services réseau sont démarrés et le système acceptera les connexions, mais une interface graphique locale n'est pas démarrée. Il s'agit de l'état système par défaut typique pour les systèmes de serveurs, qui peuvent être des systèmes sans tête montés en rack dans une salle de serveurs distante.
graphical.target est un autre alias possible pour default.target . Normalement, il est défini comme un sur-ensemble de multi-user.target :il inclut tout le multi-user.target fait, plus l'activation d'une connexion GUI locale. Un peu comme le niveau d'exécution 5 dans SysVinit classique.
La ligne WantedBy=multi-user.target dans un service revient essentiellement à spécifier "ce service doit démarrer dans les niveaux d'exécution 3, 4 et 5" dans les systèmes SysVinit :il indique systemd que ce service doit être démarré dans le cadre du démarrage normal du système, qu'une interface graphique locale soit active ou non.
Cependant, WantedBy est distinct de l'état activé/désactivé :dans un autre sens, il s'agit en quelque sorte d'un "préréglage" :il détermine dans quelles conditions le démarrage automatique peut se produire, mais uniquement lorsque le service est activé en premier lieu.
2.) si vous omettez le WantedBy=multi-user.target ligne et aucun autre service activé n'inclut un Requires=your.service ou Wants=your.service dans sa définition de service, votre service ne sera pas démarré automatiquement.
systemd fonctionne sur les dépendances, et au démarrage, si rien ne Requires ou Wants votre service, il ne sera pas démarré même si le service est activé.
Bien sûr, vous pouvez modifier votre default.target pour ajouter ou supprimer Requires ou Wants lignes pour tous les services que vous souhaitez démarrer au démarrage - mais pour que vous puissiez simplement déposer un nouveau fichier de service dans le système et le faire fonctionner par défaut (ce qui rend les choses très faciles pour les gestionnaires de packages logiciels), systemd a le WantedBy et RequiredBy mots-clés qui peuvent être utilisés pour insérer Wants et Requires -dépendances de type (respectivement) de "l'autre extrémité".
3.) Vous devez omettre la ligne si vous ne le faites pas souhaitez que le service soit démarré automatiquement au démarrage, ou ce service fait partie d'une chaîne de dépendances que vous avez définie explicitement.
Par exemple, vous pouvez refactoriser l'application serveur A et, pour une raison ou une autre, décider de scinder certaines fonctionnalités facultatives en un service B distinct, pour permettre à l'utilisateur de choisir de ne pas l'installer si ce n'est pas nécessaire. Vous pouvez alors faire du service B un service-B.rpm séparé , et définissez B.service avec WantedBy=A.service faire systemd démarrer le service B automatiquement chaque fois que le service A est démarré - mais uniquement lorsque service-B.rpm est réellement installé.
Notez qu'un Wants ou WantedBy dit seulement que le système doit démarrer un service chaque fois qu'un autre service ou cible est également démarré, mais il ne spécifie rien du tout sur l'ordre de démarrage/arrêt. Si vous avez besoin que le service B soit déjà en cours d'exécution lorsque le service A démarre, vous devez ajouter Before=A.service dans le B.service fichier pour spécifier explicitement la dépendance de l'ordre de démarrage.
4.) Chaque fois que vous faites voulez que le service ait la capacité d'être démarré automatiquement au moment du démarrage, et qu'il n'y ait pas d'autres dépendances déjà définies.