Linux : Les services système

Lancer les services avec systemd

Testez gratuitement nos 1271 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Initiez-vous aux formats des fichiers qui permettent à systemd de lancer un service lors du démarrage. Vous verrez également à quel moment le service sera lancé.
08:44

Transcription

Mon systemd gère les services. On a vu ça tout à l’heure. On était capable de démarrer, d’arrêter des services, systemd s’occupe de ça. Et la commande qui permet de demander à systemd de faire ces opérations-là, c’est la commande « systemctl ». Là je vais creuser un petit peu plus la gestion des services avec systemd, en utilisant « systemctl ». Pour commencer ça, je vais rappeler ce qu’on a vu tout à l’heure déjà le statut, l’état de rsyslog. Donc « systemctl status rsyslog » et là il m’affiche l’état du service rsyslog, je vois qu’il est actif, etc. J’ai déjà présenté ça. Je ne vais pas revenir dessus mais c'est quelque chose qu’on a déjà vue. Par contre, je vais m’intéresser à ce fichier-là. Ce fichier-là, qu’est-ce que ça va être ? Ce fichier-là, son rôle ça va être de décrire pour systemd comment démarrer rsyslog, qu’est-ce que c’est comme service, quand est-ce qu’il doit être démarré, etc. En réalité ce fichier-là, c’est vraiment le cœur de la configuration de rsyslog pour systemd. Je peux aller le regarder à la main ce fichier-là. Je peux me passer d’aller le regarder à la main, je peux demander à systemd de me l’afficher. Pour ça, je vais utiliser la commande « systemctl », « systemctl cat rsyslog.service ». Dans ce cas-là, mon « systemctl » va m’afficher le contenu du fichier. Alors là je sais où il est. Si je ne savais pas où il était, il m’aurait trouvé quand même puisque c’est lui qui le gère tout seul. Attention, quand la machine démarre, ces fichiers-là ils sont vus, ils sont chargés en mémoire. Pour le moment, il les prend en mémoire. J’ai plusieurs parties dans ce fichier-là. J’ai une partie « unit » qui va me décrire l’unité en question. C’est un service, une unité de type service. Comment est-ce qu’on va gérer ce service-là ? Ça va être décrit ici et dans quel cas l’installer là. Il ne faut pas l'avoir installé comme copie des fichiers, il faut voir l’installer sur à quel moment le lancer, l’installer dans le fonctionnement du système. Si je regarde ça en détail, « unit », je vais avoir une description qui va être donnée. La description, c’est ce qui va être marquée quand je demande le statut à cet endroit-là, c'est-à-dire que si jamais je change les mots « System Login Service » en autre chose, j’aurais autre chose qui sera affichée là quand le système aura remis à jour sa configuration. Ensuite ici, vous voyez qu’il y a un paramètre point-virgule qui commente la ligne d’après. Et j’ai un « after » qui va me définir quand est-ce que cette unité-là devra être appelée ou pourra être appelée. Ça sera après la « target network ». Cette partie unit, elle est présente dans toutes les configurations de toutes les unités de systemd et elle va donner en quelque sorte les métadonnées. Quand est-ce que ça s’exécute ou quand est-ce que c’est appelé ? Et puis la description de cet élément-là. Je passe au suivant, qui est « service ». Cette partie « service », cette ligne « service » ici, elle ne concerne que les unités de type « service », comme leur nom l’indique, que les unités de type « service » et là-dedans, on va dire ce qu’on doit faire au niveau des unités de type « service ». Les différentes options de service vont être les suivantes : le « type=notify », ici, va me préciser que le service, quand il aura démarré, il va prévenir, enfin il faudra prévenir systemd qu’on a démarré. Et quand il va être lancé, pendant que je vais demander à ce que rsyslog se lance, systemd n’attendra que rsyslog soit lancé avant de passer à la suite. Ensuite, j’ai quoi ? J’ai « EnvironmentFile » avec le nom d’un fichier. Et en plus le nom du fichier, il est précédé d’un tiré. Ici ça veut dire que je vais avoir un fichier texte qui va contenir l’environnement dans lequel le service va démarrer. Alors l’environnement dans lequel le service va démarrer, ça veut dire qu’on va décrire les variables d’environnement qui seront initialisés pour le démarrage du service. Le fait qu’il y a un petit tiré devant, il signifie que si jamais ça échoue, là en l’occurrence si jamais le fichier n’existe pas, on ne fait pas échouer le lancement du service, l’unité ne va pas échouer à ce moment-là. Le « ExecStart », qui est la ligne d’après correspond à la ligne de commande à exécuter pour lancer ce service-là. Ici, donc c’est « /usr/sbin/rsyslogd » en passant l’option « -n » puis en passant le contenu de la variable « SYSLOGD_OPTIONS ». cette variable-là pourrait tout à fait être initialisée à partir du contenu du fichier précédent puisqu’on va d’abord charger l’environnement avant d’exécuter cette commande-là. Puis après, on a quelques autres informations, comme le « Restart=on-failure ». Ça veut dire que si jamais il y a un échec, que le programme plante, à ce moment-là on le redémarrera. Le « Umask », ça lui permet de définir les droits des fichiers par défaut quand il va créer des fichiers. Et puis le « StandardOutput=null », ça veut tout simplement dire qu’il n’affichera rien sur le terminal qui le lancerait, il coupe sa sortie standard. Donc là, voilà c’est la deuxième partie et au final cette dernière partie, cette partie « Install », va me préciser également comment ce service-là va être démarré. C’est une section qui est facultative. Ça permet juste de savoir dans quel ordre je vais la démarrer, à quel moment, etc. Ici, on le voit, on a comme directive « WantedBy », qui veut dire « Voulu par », « multi-user.target ». Ça veut dire que si jamais je vais dans le « multi-user.target », il sera nécessaire d’avoir déjà lancé ce service-là. Ça permet de savoir les dépendances de qui correspond à quoi avec ce fichier-là. C’est un fichier qui est relativement simple. Il y en a qui sont un petit peu complexes et il y en a qu’on va pouvoir personnaliser, notamment on va permettre de voir dans les plus complexes et dans la personnalisation qu’on pourra faire, comment aller plus loin au niveau de ces services. Pour ça, je vais effacer la page, donc Ctrl + L et pour ça je vais faire un « systemctl status ssh ». « Ssh.service » ne peut pas être trouvé, ça doit être « sshd », voilà. « Sshd », c’est le « daemon ssh ». Donc là mon « sshd », il est décrit ici et on voit évidemment que j’ai également un fichier qui est là. L’intérêt de voir ce fichier « sshd », c’est qu’il a plus de dépendance que le fichier rsyslog, donc on va un peu plus loin avec. Je vais faire mon « systemctl cat sshd », je ne vais pas l’oublier cette fois, « .service ». Et ici je vois mon fichier, donc j’ai pareil, une description qui est donnée ici. Les pages de documentation sont mentionnées ici. J’ai du « after » et du « want ». Ça veut dire quoi ? Le « after » veut dire qu’il ne démarrera que quand on aura déjà atteint la « target network » et quand le « sshd keygen » aura été exécuté. Et on le rajoute ici, on a besoin que celui-là soit exécuté. C’est vraiment un point qui est important, parce que ça veut dire que « sshd » ne démarrera pas si « sshd keygen » n’a pas démarré. On a une dépendance forte ici. Pour information, le « sshd keygen » va regarder si les clés du serveur pour le service « ssh » ont déjà été créées ou pas. Si elles n’ont pas été créées, il va les créer avant de démarrer le service, sinon le service ne démarrerait pas. Et si elles ont été créées, il laissera le service démarrer. Si elles ne sont pas démarrées, ils les créent. Si elles ne sont pas créées, il va les créer. Si elles sont déjà créées, il va démarrer le service normalement. Le service est de type « forking ». Le type « forking », ça veut dire quoi ? Ça veut dire que le processus, il va être lancé, puis il va être autonome. Si jamais le processus lanceur s’arrête, le processus lancé va continuer à fonctionner, c'est-à-dire qu’il va fonctionner en tâche de fond, il n’a pas besoin de son père. En gros systemd va lancer « sshd » et puis va passer à la suite. Le « PIDFile » ici, c’est le numéro du processus qui aura été créé quand on lance ce service, qui va être enregistré dans ce fichier-là, de la même manière, on a un fichier d’environnement, de la même manière que pour rsyslog. Le « ExecStart », ça me donne la ligne de commande à lancer pour exécuter ce service et ici j’ai un « ExecReload ». Le « ExecReload » qu’est-ce qu’il va faire ? Le « ExecReload », c’est la commande qu’on va lancer dans le cas où on va faire un « systemctl reload sshd ». Le « reload » n’est pas un « restart ». Dans le cas où on fait « restart », on fait « stop » et un « start ». Ici le « reload » qu’est-ce qu’il va faire ? Il va lancer cette commande-là qui aura pour effet de demander à sshd de relire sa configuration et de prendre en compte cette nouvelle configuration. Le « killmode=process », ça veut dire que si jamais on veut « killer » le service, si on veut le détruire de la mémoire, il faudra tout simplement tuer le processus. Le « restart=on-failure », ça on l’a vu précédemment, ça fonctionne pareil. Et le « RestartSec », il va préciser le temps à attendre avant de redémarrer le service, c'est-à-dire que si jamais le service redémarre après un « failure », il va faire une pause de 42 secondes avant de le redémarrer. Et puis dans le « Install », on le voit qu’il sera à mettre en place dans la cible « multi-user.target ». Ça nous permet de comprendre un petit peu les services, comment ils fonctionnent, comment ils sont configurés. On ne passe pas par des scripts, c’est vraiment systemd qui à partir de ces informations-là, va activer ou désactiver ces services. Ce qui va être intéressant de voir, c'est maintenant, comment est-ce qu’on va pouvoir personnaliser tout ça.

Linux : Les services système

Découvrez les services qui tournent en permanence sur votre système et adaptez-les en fonction de vos besoins. Abordez la gestion des logs, la synchronisation horaire, etc.

2h16 (22 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Thématiques :
IT
Systèmes d'exploitation
Spécial abonnés
Date de parution :25 avr. 2017

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !