Fichier unitaire SystemD créant un service
Avec ses services, Systemd rend tout cela plus facile, vraiment plus facile. Dès que vous voulez quelque chose qui surveillait votre application et votre contrôle facile, Systemd est la voie à suivre, et c'est ce que je vais expliquer ici!
Où sont les services Systemd
Pour ajouter un nouveau service, eh bien, vous devez répondre à cette question. Comme toujours dans Systemd, cela dépend si le service est uniquement pour votre utilisateur ou l'ensemble du système. Nous nous concentrerons sur le fonctionnement de SystemD pour les services système entiers.
L'emplacement exact dépend pourquoi et comment le service a été installé. Si le service est installé par un gestionnaire de packages, il sera généralement dans / usr / lib / systemd / système. Pour les logiciels que vous développez ou ceux qui ne prennent pas en charge Systemd en soi, vous metterez le fichier de service dans / usr / local / lib / systemd / système. Veuillez garder à l'esprit que certaines distributions ne soutiennent pas ce dossier dans / usr / local. Enfin, si vous souhaitez configurer un service SystemD existant, / etc / systemd / System est la voie à suivre.
À l'intérieur de ces dossiers, vous pouvez trouver plusieurs extensions de fichier telles que *.prise, *.cible ou *.service. De toute évidence, nous allons nous concentrer sur le dernier. SystemD utilise le nom de fichier comme nom du service lors du démarrage ou de l'arrêt etc. Donc, généralement les noms de fichiers en service ne contient que des caractères alphanumériques ainsi que des traits de traits et des soulignements. Pendant le développement, je recommande de le créer dans vos documents, puis de le copier à l'emplacement Systemd une fois terminé, cela vous éviterait des problèmes si vous économisez au milieu de l'édition.
Ok alors veuillez créer votre fichier de service dans vos documents. Maintenant, nous sommes prêts à consulter comment rédiger ce fichier.
[Remarque: voir le rapport potentiel de bogues dans la section des commentaires de cet article de blog]
Description = Application Web Penguins HTTP Server (exécuté dans le port 8080)
Recherché = multi-utilisateurs.cible
[Service]
Type = simple
Execstart = / usr / bin / python3 / usr / local / bin / pinguin-web-app / main.py
Redémarrer = toujours
Le format de fichier est en fait proche d'Ini. Je sais que cela peut être bizarre étant donné que les fichiers ini se trouvent souvent dans Windows, mais c'est ainsi que ça fonctionne. Le fichier de service est d'abord divisé en 2 sections: [unité] et [service]. Chaque section configure un aspect spécifique de SystemD: [unité] contient des éléments partagés par tous les fichiers d'unité Systemd tandis que [Service] est uniquement pour la configuration spécifique à la configuration d'un nouveau service.
Alors la section est configurée avec des propriétés telles que description = ou execStart =. La valeur est séparée du nom de la propriété par le signe égal = sans aucun espace.
Revenons au fichier affiché ci-dessus. Il décrit un service conçu pour exécuter une application Web écrite en python sur les pingouins. Systemd le redémarrera chaque fois que le processus sortira et démarre le serveur lors du démarrage du serveur si vous l'activez avec SystemCTL Activer Commande. Cool hein?
Mais vous êtes peut-être votre prochaine application Web ne concerne pas les pingouins - Et c'est dommage - Et ce n'est pas écrit en python. Dans ce cas, vous voudrez en savoir plus sur les configurations possibles.
Propriétés des services Systemd
Concentrons-nous d'abord sur les propriétés de [unité]:
Description = consiste simplement à donner une description claire de ce que fait le service. Il s'affiche dans la liste des services, les journaux de service afin que vous souhaitiez qu'il soit descriptif, mais il devrait rester sur une seule ligne et une phrase.
WantedBy = permet de dire à Systemd: quand cette chose est démarrée, me démarre également. Vous metterez généralement le nom d'une cible. Exemples de cibles communes:
- multi-utilisateurs.cible: lorsque le serveur est OK et est prêt à exécuter les applications de ligne de commande
- graphique.cible: lorsque Gnome ou KDE est prêt
- réseau.cible: lorsque le serveur est correctement connecté à un réseau
Ok pour le début, ces propriétés de [unité] suffisent. Jetons un coup d'œil sur [service] maintenant.
Type = aide Systemd à savoir si un service est en cours d'exécution. Voici des types communs:
- Simple est probablement le plus couramment utilisé: SystemD considère le processus que vous lancez comme celui qui fait le service. Si le processus s'arrête, il considère que le service s'est également arrêté, etc.
- La fourniture est préférée pour les applications qui ont été écrites pour être un serveur mais sans l'aide d'un système de gestion de services. Fondamentalement, il s'attend à ce que le processus lancé fourche et que Fork est considéré comme le processus final pour le service. Afin d'être plus précis, vous pouvez également aider Systemd avec un fichier PID, où le PID du processus à suivre est écrit par l'application lancée.
Execstart = est probablement le plus important pour un service: il précise quelle application lance lors du démarrage du service. Comme vous pouvez le voir dans le service Penguin, j'ai utilisé / usr / bin / python3 et non python3 tout de suite. C'est parce que la documentation SystemD recommande explicitement d'utiliser des chemins absolus afin d'éviter les surprises.
Mais c'est aussi pour une autre raison. Le système de gestion des autres services a tendance à être basé sur des scripts shell. Cependant, SystemD, pour une raison de performance, n'exécute pas de shell par défaut. Vous ne pouvez donc pas fournir directement une commande shell dans execStart =. Vous pouvez cependant toujours utiliser un script shell en faisant:
ExecStart = / usr / bin / bash / usr / local / bin / lancement-penguin-server.shot
Pas si dur? Notez que si vous avez besoin d'exécuter un processus pour signaler votre service pour vous arrêter proprement, ExecStop = existe, ainsi que EDEDELOAD = pour le rechargement des services.
Redémarrer = vous permet de dire explicitement quand le service doit être redémarré. C'est l'une des caractéristiques importantes de SystemD: il garantit que votre service reste à la hauteur aussi longtemps que vous le souhaitez, alors faites une attention particulière à cette option.
| Redémarrer = | Signification |
| toujours | Systemd continuera de le redémarrer chaque fois qu'il se termine ou se bloque. Eh bien, jusqu'à ce que vous fassiez le nom de service SystemCTl Stop.service. Il est parfait pour les serveurs et les services en ligne car vous préférez quelques redémarrages inutiles à redémarrer manuellement le service sans aucune raison. |
| à la mode | Lorsque le processus de service se bloque, redémarrez le service. Cependant, si l'application sort proprement, ne le redémarrez pas. Il est plus utile pour les cron-emplois comme les services qui doivent faire une tâche de manière fiable mais n'ont pas besoin d'exécuter tout le temps. |
| en face | Un peu comme en borne, mais il redémarre également le service lorsque l'application sort proprement mais avec un code de sortie non nul. Les codes de sortie non nul signifie généralement qu'une erreur s'est produite. |
| Non | Systemd ne redémarrera pas le service automatiquement. Généralement utile pour accéder à d'autres fonctionnalités Systemd telles que la journalisation sans la fonction de redémarrage. |
WorkingDirectory = peut appliquer un répertoire de travail lors du lancement de votre application. La valeur doit être un chemin de répertoire absolu. Le répertoire de travail est utilisé lorsque vous utilisez des chemins relatifs dans le code de votre application. Pour notre service de pingouins, cela pourrait être:
WorkingDirectory = / srv / Penguin-web-app /
Ensuite, la sécurité est importante, vous souhaitez généralement ne pas lancer votre service avec des privilèges racine. User = et group = vous permet de définir le nom de l'utilisateur ou du groupe ou UID / GID sous lequel votre application sera lancée. Par exemple:
Utilisateur = pingouin-web
Groupe = pingouin-web
EnvironmentFile = est une option puissante. Les applications exécutées en tant que services ont souvent besoin de fichiers de configuration et d'environnement permet de définir cette configuration de deux manières:
- L'application peut lire directement la variable d'environnement.
- Mais vous pouvez également définir différents arguments de ligne de commande sur votre application sans modifier le fichier de service.
La syntaxe de ce fichier est simple: vous tapez le nom de la variable environnement, le signe égal = puis sa valeur. Ensuite, vous mettez le chemin absolu de votre fichier d'environnement dans la propriété EnvironmentFile.
Ainsi, exemple:
EnvironmentFile = / etc / Penguin-web-app / environnement
Et le fichier / etc / pinguin-web-app / environnement contient:
Écouter_port = 8080
Ensuite, notre application Web Penguins aura accès à la variable de l'environnement Listen_port et écouter le port attendu.
Enregistrer et démarrer le service Systemd nouvellement créé
Donc, si vous avez suivi mes conseils, vous avez édité votre fichier de service dans votre répertoire domestique. Une fois que vous êtes satisfait, copiez ce fichier vers / usr / local / lib / systemd / système, en supposant que votre distribution prend en charge ce chemin. Le nom de fichier de votre fichier de service sera son nom de service. Ce nom de fichier doit se terminer avec .service. Par exemple, pour notre serveur Penguins, ce serait Penguin-web-App.service.
Ensuite, vous devez dire à Systemd que vous avez ajouté un nouveau service, vous devez donc taper cette commande:
$ sudo Systemctl Daemon-Reload
Ok maintenant systemd est conscient de votre nouveau service, en supposant que votre fichier ne contient pas d'erreur de syntaxe. Après tout, c'est votre premier fichier, donc il est probable que vous ferez des erreurs. Vous devez exécuter cette commande ci-dessus à chaque mise à jour de votre fichier de service.
Maintenant, il est temps de démarrer le service:
$ sudo systemctl start Penguin-web-app.service
S'il échoue avec une unité non trouvée des erreurs comme celle-ci:
$ sudo systemctl start Penguin-web-app.service
Échec du démarrage de Penguin-web-App.Service: unité introuvable.
Cela signifie que votre distribution ne prend pas en charge le répertoire ou que vous n'avez pas nommé correctement votre fichier de service. Assurez-vous de vérifier.
Si vous configurez votre service avec WantedBy = et que vous voulez que votre service commence automatiquement, vous devez l'activer, avec cette commande:
$ sudo systemctl activer Penguin-web-app.service
Ce qui est cool avec un service, c'est qu'il fonctionne en arrière-plan. Le problème: comment savoir s'il fonctionne correctement et s'il fonctionne s'il s'exécute en arrière-plan? Ne vous inquiétez pas, l'équipe Systemd y réfléchit également et a fourni une commande pour voir si elle s'exécute correctement, depuis combien de temps, etc.:
$ systemctl status pingouin-web-app.service
Conclusion
Bravo! Vous pouvez maintenant faire gérer vos applications sans que vous vous souciiez de le redémarrer manuellement à chaque fois. Maintenant, je vous recommande de lire notre autre article sur les journaux SystemD: Master JournalCTL: Comprendre les journaux SystemD. Avec cela, vous pouvez utiliser le puissant système de journalisation de votre nouveau service et créer des serveurs plus fiables!