Pourquoi la plupart des exemples de systemd contiennent WantedBy = multi-user.target?
J'ai lu qu'est-ce que multi-user.target et documentation systemd , qui déclare que le multi-user.target est une cible spéciale. De plus, beaucoup de exemples systemd contiennent cette ligne.
- Pourquoi tant de services d'exemple contiennent cette ligne?
- Que se passerait-il s'ils ne contenaient pas WantedBy = multi-user.target?
- Pourriez-vous me donner un exemple de moment où il serait effectivement conseillé de ne pas inclure cette ligne dans une définition de fichier de service?
- Dans le même esprit, quand est-ce une bonne idée de conserver cette ligne?
1.) multi-user.target Est essentiellement l'équivalent le plus proche du niveau d'exécution SysVinit 3 classique que possède systemd. Lorsqu'un système systemd 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 dans lequel tous les services réseau sont démarrés et le système accepte les connexions, mais une interface graphique locale n'est pas démarrée. Il s'agit de l'état système par défaut type pour les systèmes 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 surensemble de multi-user.target: Il comprend tout ce que fait multi-user.target, 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 est essentiellement la même que celle spécifiant "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é: donc dans un autre sens, c'est une sorte de "préréglage": il détermine dans quelles conditions le démarrage automatique peut se produire, mais uniquement lorsque le service est activé dans le première place.
2.) si vous omettez la ligne WantedBy=multi-user.target Et qu'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 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 des lignes Requires ou Wants pour tous les services que vous souhaitez démarrer au démarrage - mais pour pouvoir simplement supprimer un nouveau service fichier dans le système et le faire fonctionner par défaut (ce qui rend les choses très faciles pour les gestionnaires de progiciels), systemd a les mots-clés WantedBy et RequiredBy 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 pas voulez que le service soit lancé automatiquement au démarrage, o ce service fait partie d'une chaîne de dépendances vous avez défini explicitement.
Par exemple, vous pourriez refactoriser l'application serveur A et, pour une raison ou une autre, décider de diviser certaines fonctionnalités facultatives en un service distinct B, pour permettre à l'utilisateur de ne pas l'installer s'il n'est pas nécessaire. Vous pouvez ensuite faire du service B un service-B.rpm Distinct et définir B.service Avec WantedBy=A.service Pour que systemd démarre automatiquement le service B à chaque démarrage du service A - mais uniquement lorsque service-B.rpm est réellement installé.
Notez qu'un Wants ou WantedBy indique uniquement que le système doit démarrer un service chaque fois qu'un autre service ou une 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 au démarrage du service A, vous devez ajouter Before=A.service Dans le fichier B.service Pour spécifier explicitement la dépendance de l'ordre de démarrage.
4.) Chaque fois que vous faites voulez que le service puisse être démarré automatiquement au démarrage, et qu'il n'y a pas d'autres dépendances déjà définies.
Si vous supprimez WantedBy=multi-user.target, puis systemctl enable your-example-here ne fera (bruyamment) rien.
graphical.target
Si vous installez pure systemd à partir de la source, la "cible par défaut" vers laquelle il démarre est graphical.target.
Démarrage graphical.target départs multi-user.target, plus les unités nécessaires pour fournir une interface utilisateur graphique. Cette complexité supplémentaire a été organisée dans le but d'imiter les "niveaux d'exécution" hérités.
Vous vraiment devez ignorer/ignorer l'émulation "runlevel"; cela ne fonctionne pas correctement de toute façon. Désolé! Je suppose que la raison de mettre l'accent sur les vs "graphiques". "multi-utilisateur" est historiquement que le logiciel graphique n'est 1) pas aussi robuste et mature que le reste du système et 2) nécessite beaucoup de ressources.
En règle générale, seules quelques unités sont spécifiques à graphical.target. Il existe un seul service pour l'interface graphique comme gdm.target. Il y a quelques services de support qui sont principalement utilisés par l'interface graphique ici également.
Edit: Google recherche que si vous n'avez pas une interface graphique installée, mais la "cible par défaut" a été laissée comme graphical.target, alors systemd peut enregistrer un avertissement. "Impossible d'ajouter le travail de dépendance pour l'unité display-manager.service, en ignorant: l'unité display-manager.service n'a pas pu se charger: aucun fichier ou répertoire de ce type." Nous voulons éviter de salir nos journaux avec des avertissements inutiles. Donc, si vous n'avez pas installé d'interface graphique, il est bon d'utiliser systemctl set-default multi-user. Bien que le système d'installation de votre système d'exploitation ait déjà pris soin de cela pour vous. A part cela, je suis fortement en faveur de l'apathie à ce sujet :-).
sysinit.target
Certains services et autres types d'unités sont "impliqués dans un démarrage précoce". Ils sont définis pour démarrer Before=sysinit.target - directement ou indirectement. La plupart des services ne démarrent que After=sysinit.target - c'est automatiquement le cas, sauf si le service définit DefaultDependencies=no.
multi-user.target
La plupart des exemples de services n'entrent dans aucune des catégories ci-dessus, nous les attachons donc à multi-user.target. Cela comprend la plupart des services réseau (par exemple, un serveur Web), qui sont le service système archétypal.
services activés dynamiquement
Une autre possibilité que vous pourriez voir est une unité de service qui est pas démarrée automatiquement au démarrage. Il n'aurait donc pas besoin de WantedBy=multi-user.target. Le service peut à la place être déclenché ou "activé" par autre chose.
Un exemple de ceci est un service activé par dbus. Dbus peut être configuré pour démarrer votre service à la demande, lorsqu'un appel dbus est effectué vers le service.
Pour les services réseau, vous pouvez utiliser des services activés par socket. Cela pourrait être plus facile de trouver des détails, car toute la configuration est en unités systemd. Par exemple sshd.socket ou ssh.socket est généralement disponible pour activer [email protected] ou [email protected]. Cependant, je pense qu'il est plus courant de démarrer le service sshd au démarrage.
Comme toujours, ce qui précède simplifie et omet des détails qui ne semblaient pas nécessaires.