Comment démarrer automatiquement les services au démarrage dans RHEL / CentOS 7?

Vous vous demandez comment gérer les services en arrière-plan ou au démarrage?

Le mécanisme de gestion et de démarrage processes au démarrage a été modifié. Jusqu'à RHEL/CentOS 6.x, vous auriez crééateda script dans /etc/init.d/ et activé à l'aide de chkconfig mais les choses sont différentes sur RHEL 7.

Il est remplacé par systemd et comme c'est plus ou moins la valeur par défaut process gestionnaire sur les versions majeures de Linux, Administrateur système connaissant d'autres saveurs, vous vous sentirez comme chez vous. Dans cet article, nous explorerons ce systemd est, quelles étaient les raisons du changement et comment utiliser systemd pour configurer, exécuter et gérer l'arrière-plan processes avec ça.

Qu'est-ce que systemd?

Depuis chaque process sous Linux est visible de manière transparente, voyons où systemd se cache. Sur mon système, j'obtiens ce qui suit:

 ~$ps-ef | grep systemd root 1 0 0 11 novembre ? 00:01:02 /lib/systemd/systemd --system --deserialize 22 message+ 768 1 0 11 novembre ? 00:05:46 /usr/bin/dbus-daemon --system --address=systemd : --nofork --nopidfile --systemd-activation --syslog-only root 805 1 0 Nov11 ? 00:10:22 /lib/systemd/systemd-logind ankush 1132 1 0 11 novembre ? 00:00:00 /lib/systemd/systemd --user ankush 1176 1132 0 11 novembre ? 00:04:50 /usr/bin/dbus-daemon --session --address=systemd : --nofork --nopidfile --systemd-activation --syslog-only ankush 9772 20029 0 21:11 pts/6 00 : 00:00 grep --color=auto systemd systemd+ 17298 1 0 19 novembre ? 00:00:12 /lib/systemd/systemd-resolved systemd+ 17303 1 0 19 novembre ? 00:00:00 /lib/systemd/systemd-heuresyncd racine 17307 1 0 19 novembre ? 00:00:02 /lib/systemd/systemd-journald racine 18182 1 0 19 novembre ? 00:00:00 /lib/systemd/systemd-udevd

Je parie que vous l'avez remarqué instantanément. la première process dans la liste a été lancé en tant qu'utilisateur root, et a le pid 1.

Effectivement, c'était la première process que le système s'est lancé au démarrage. Dire bonjour à systemd.

Donc, tout simplement, systemd est la "mère" process qui lance, gère et termineatec'est autre processes dans le système, en plus de fournir des informations sur leur journalisation, l'état du système de fichiers, etc.

Une note sur le nom, cependant. Le nom est en effet systemd et pas le système D ou quoi que ce soit d'autre. Le « d » signifie démon, un Linux standard process qui fonctionne (se cache ?) en arrière-plan et n'est attaché à aucune session de terminal.

Pourquoi RHEL est passé à systemd?

Comme nous l'avons déjà discuté, systemd est un système et process manager, et dans RHEL 7, remplace le programme bien connu Upstart. Pourquoi RHEL a-t-il pris cette décision ? Eh bien, il y a de très bonnes raisons à cela, alors jetons-y un coup d'œil rapide.

Initialisation du service parallèle

N'aime pas le SysV init programme, systemd est capable de lancer des services en parallèle. le init programme, en revanche, les lance un par un. À une époque où même les appareils mobiles ont des processeurs multicœurs, le manque d'initialisation parallèle est un gros problème.

Gestion dynamique des services (chauds)

Si vous avez remarqué que les clés USB doivent être explicitement montées sur les systèmes Fedora antérieurs alors qu'elles le seraient automatiquement.ally s'ouvre sur Ubuntu et les distributions similaires, la raison est systemd. Il est capable de détecter les changements en direct dans le matériel et les terminaux.ate/lancer les services selon les besoins. Certains diront que c’est inutile, mais pour beaucoup, tout ce qui réduit la charge cognitive est le bienvenu.

Lancement de service différé

systemd rend les temps de démarrage plus courts car il est capable de différer le lancement du service au moment où il est actifally nécessaire. Un exemple simple est le système de fichiers réseau.related services. S'il n'y a pas de disque réseau disponible, cela n'a aucun sens d'avoir un service opérationnel.

Plus rapide process communication

Les capacités parallèles de systemd report à l'inter-process communication. systemd est capable d'offrir un accès parallèle aux prises et au bus système, réduisant considérablement process temps d'attente pour les ressources de communication.

Redémarrage automatique

Si un service plante, systemd peut le détecter et tenter de le redémarrer. La plupart du temps, un simple redémarrage suffit pour qu'une application recommence à fonctionner, sauf en cas de problèmes plus fondamentaux.

Quoi qu'il en soit, systemd facilite ici la vie d'un administrateur système.

systemd dans RHEL7 - Quels changements pour les administrateurs système?

Si vous avez un sentiment tenace systemd ne sera pas que des cloches et des sifflets, vous avez raison. Il existe quelques incompatibilités importantes qui peuvent surprendre l'administrateur système RHEL par surprise. Jetons un coup d'oeil rapide.

Support de niveau d'exécution limité

systemd a une reconnaissance et un support assez minables pour les niveaux d'exécution. Tous les niveaux d'exécution ne sont pas pris en charge, et pour certaines cibles, il peut même n'y en avoir aucun. Dans ces cas, systemd renvoie «N» en réponse au runlevel commandes, signifiant qu'il n'a pas de niveau d'exécution correspondant à cette cible. Dans l'ensemble, Red Hat nous conseille de ne pas utiliser (!) Le runlevel les commandes.

Aucune commande personnalisée

Celui-ci va faire mal. Un gros avantage de SysV était la possibilité de définir des commandes personnalisées pour fournir de meilleures fonctionnalités de gestion. processes. Avec systemd, il n'y a pas une telle option et vous êtes coincé avec start, stop, status, restart, etc.

Famille uniquement et non interactif

systemd (bien sûr) garde une trace de processes, il a lancé et stocke leurs PID. Le défi, cependant, est que systemd ne peut pas gérer processn'est pas lancé par celui-ci. De plus, il n'est pas possible pour un utilisateur d'interagir avec un process commencé par systemd. Toute la sortie va à /dev/null, mettant effectivement un terme à tout espoir que vous auriez pu avoir de capturer la sortie.

Pas de contexte

contrairement à init services, ceux lancés par systemd n'héritez d'aucun environnement des utilisateurs du système. En d'autres termes, des informations comme PATH et d'autres variables système ne sont pas disponibles, et chaque nouvelle process est lancé dans un contexte vide.

Si cette liste de limitations vous fait pleurer, encore une fois, vous n'êtes pas seul. systemd a été une force polarisante dans le monde Linux, et une recherche sur Google sur « systemd est nul » dénichera de nombreuses lectures sur material. 😉

Comment démarrer le service automatiquementally Quand est-il en panne ?

Voici un cas d'utilisation assez courant dans les déploiements. Nous devons démoniser un programme dans un langage qui n'a pas de durée de vie longue processoui : PHP ! Supposons que j'écrive un script PHP pour gérer les connexions Websocket entrantes (nous avons construit une application de discussion, après tout !) et que le script soit placé à l'emplacement /home/ankush/chat_server/index.php.

Étant donné que les connexions Websocket peuvent atteindre le serveur à tout moment, cela process doit être debout à tout moment et monitor connexions entrantes. Nous ne pouvons pas avoir le cycle de vie PHP traditionnel ici car les WebSockets sont stateconnexions complètes, et si le script meurt, la connexion est une liste. Quoi qu'il en soit, assez sur les websockets ; voyons comment nous allons procéder pour démoniser ce script via systemd.

Tous systemd les services résident dans /etc/systemd/system, alors créonsate un fichier pour décrire notre script de serveur websocket. En supposant que vous soyez connecté en tant qu'utilisateur root.

# vi /etc/systemd/system/chat_server.service

puis ce qui suit est nécessaire.

 [Unité]
Description=Service du serveur de chat After=network.target [Service] Type=simple User=ankush ExecStart=php /home/ankush/chat_server/index.php Restart=on-abort [Install] WantedBy=multi-user.target

Enregistrez le fichier et l'étape suivante consiste à recharger le démon systemd

 # systemctl daemon-reload

et pour démarrer le service, nous venons de créerated:

 # systemctl démarrer chat_server

Si vous ne voyez aucune erreur, c'est tout!

Voyons aussi rapidement ce que signifient les différentes directives du fichier:

• La [Unit] part définit une nouvelle unité de service pour systemd. Dans le systemd jargon, tous les services sont appelés unités de service.
• La After directive (prévisible) dit systemd de lancer ce service uniquement après le lancement des services réseau (autreswise, qui effectuera la gestion de niveau inférieur des connexions socket ?!).
• La Type=simple raconte systemd que ce service n'est pas censé le créerself. En d’autres termes, une seule instance sera exécutée à un moment donné.
• User=ankush signifie que ce service fonctionnera en tant que l'utilisateur «ankush». Nous pourrions changer cela en «root», mais c'est fortement déconseillé du point de vue de la sécurité.
• ExecStart, comme vous pouvez le voir, est la commande à exécuter.
• Restart=on-abort signifie que le service doit être redémarré lorsqu'il est abandonné. En PHP, de longue durée processes fuite de mémoire et événementally exploser, donc c'est nécessaire.
• La WantedBy= directive dit systemd à quelle cible (pensez aux groupes) ce service fait partie. Cela se traduit par la création de liens symboliques.ated à l'intérieur de cette cible pour pointer vers le service.

Générerally, c'est suffisant pour exécuter l'arrière-plan processes utilisant systemd dans RHEL 7.

Plus d'options pour la logique de redémarrage

Dans l'exemple ci-dessus, j'ai configuré Restart=on-abort mais ce n'est pas la seule option. Il y en a plus et choisissez en fonction de l'exigence.

• en cas de panne - sera redémarré en cas de code ou de signal de sortie impur
• toujours - redémarrer lorsqu'il est trouvé vers le bas, signal propre ou sale
• sur-anormal - signal, chien de garde ou timeout impur
• succès - uniquement lorsqu'il a été arrêté par un signal propre ou un code de sortie

Configuration du service pour démarrer au démarrage

Une fois que vous êtes satisfait du script et que vous vous êtes assuré qu'il fonctionne, vous devez ensuite le configurer pour qu'il se déclenche au démarrage et au démarrage.

Cliquez sur / etc / systemd / system et exécutez la commande enable ci-dessous (n'oubliez pas de changer le nom du fichier .service avec celui que vous avez)

 # systemctl activer chat_server.service

Vous verrez une confirmation qu'il a crééateun lien symbolique.

 Created lien symbolique de /etc/systemd/system/multi-user.target.wants/chat_server.service vers /etc/systemd/system/chat_server.service.

Redémarrez votre serveur et vous devriez voir le service démarre au démarrage.

C'était facile! N'est-ce pas?

Aide! Je suis massivement investi dans Upstart. 🙁

Je comprends que vous me faites confiance, votre cas est la norme plutôt que l'exception. RHEL utilise Upstart depuis si longtemps que le changement ressemble presque à une trahison. Mais bon, les systèmes changent constamment et nous ne devrions pas nous chamailler pour des bagatelles. Red Hat reconnaît que de nombreuses personnes sont coincées avec des versions plus anciennes et ont des problèmes de création.ateda guide de migration auquel vous devez absolument vous référer.

Une grâce salvatrice dans tout cela est que systemd est compatible avec le SysV init scripts, donc pour la plupart, vous devrez simplement déplacer vos fichiers et faire fonctionner les mêmes services.

Vous souhaitez en savoir plus sur l'administration et le dépannage Linux? Regarde ça Cours en ligne.