En fait, je ne suis pas sûr de devoir utiliser des scripts Shell ou s'il existe déjà des solutions. Mais quelle que soit l'approche que nous utilisons, je souhaite que le service continue de fonctionner en permanence.
Disons iptables
à titre d'exemple. Ensuite ..
iptables
est stopped
ou (en d'autres termes) ne fonctionne pas, je veux qu'il soit started
(ou restarted
) .. automatiquement à chaque fois qu'il s'est arrêté (ou ne fonctionne pas).(Peut-être que je pourrais donner une assez bonne fréquence pour vérifier si faire la vérification en temps réel est le problème. Alors disons toutes les 5 minutes)
Le seul moyen auquel je puisse penser est d'utiliser des scripts Shell avec Cron Tab.
Merci!
Mise à jour de mars 2018
Cette réponse est maintenant assez ancienne et, depuis sa rédaction, systemd a remporté la guerre contre Linux. Ainsi, vous devriez probablement créer une unité systemd , si systemd est intégré à votre distribution (la plupart d’entre elles).
La réponse ci-dessous est préservée pour la postérité.
La réponse ci-dessus est valable, mais je pensais mentionner quelques alternatives:
Il convient de garder à l'esprit que votre système d'exploitation a déjà résolu le problème de gestion des processus. Traditionnellement, Linux utilisait sysvinit, qui est essentiellement la collection de scripts que vous voyez dans init.d. Cependant, c'est assez stupide et ne peut pas surveiller les processus, les scripts init.d sont compliqués et ils sont remplacés pour une bonne raison.
Des systèmes d’exploitation plus modernes commencent à remplacer sysvinit, et les principaux sont Upstart et Systemd. Debian se penche vers systemd, Ubuntu s'est développée et a pratiquement déjà migré vers Upstart et, à l'instar de Debian Redhat/CentOS/Fedora, se dirige vers systemd. Ainsi, si vous utilisez un système d'exploitation qui a déjà remplacé sysvinit, je vous recommanderais d'utiliser ce qui est intégré. Les scripts sont beaucoup plus faciles à écrire que les scripts init.
J'ai utilisé runit et je l'aime bien, mais le plus simple à utiliser est supervisor. Il est également très bien documenté, fonctionne presque partout et est inclus dans toutes les distributions majeures.
Mais quoi que vous fassiez, s'il vous plait, SVP, n'utilisez pas de script Shell. Il y a tellement de problèmes avec cette approche!
iptables
est un mauvais exemple, car ce n'est pas vraiment un service ou un démon en cours d'exécution, mais une partie du noyau. Vous ne pouvez pas vraiment "arrêter" iptables
, vous pouvez seulement lui donner une configuration et "arrêter" cela implique de lui donner une configuration vierge. En effet, des systèmes Linux sont tombés en panne, mais la configuration de la redirection de port utilisant iptables
continue de fonctionner.
Quoi qu'il en soit, un utilitaire appelé monit
fera ce que vous voulez. Si vous utilisez Debian, c'est un apt-get install monit
. C'est un peu compliqué d'apprendre mais très flexible.
Nous utilisons ce script simple pour créer une alerte et démarrer le service s'il n'est pas en cours d'exécution. Vous pouvez également ajouter d'autres services.
file name: uptime.sh
#!/bin/bash
#service monitoring
/bin/netstat -tulpn | awk '{print $4}' | awk -F: '{print $4}' | grep ^80$ > /dev/null 2>/dev/null
a=$(echo $?)
if test $a -ne 0
then
echo "http service down" | mail -s "HTTP Service DOWN and restarted now" root@localhost
/etc/init.d/httpd start > /dev/null 2>/dev/null
else
sleep 0
fi
/bin/netstat -tulpn | awk '{print $4}' | awk -F: '{print $4}' | grep ^53$ > /dev/null 2>/dev/null
b=$(echo $?)
if test $b -ne 0
then
echo "named service down" | mail -s "DNS Service DOWN and restarted now" root@localhost
/etc/init.d/named start > /dev/null 2>/dev/null
else
sleep 0
fi
Cron setup:
*/5 * * * * /root/uptime.sh > /dev/null 2>/dev/null
Solution alternative pour le bureau (KDE):
Nous pouvons regarder un service avec l'Applet/Widget Etat du serveur ... après l'avoir installé, il suffit d'ajouter une commande dans le widget pour surveiller votre service.
Exemple: systemctl status httpd.service
Version KDE 4: https://store.kde.org/content/show.php?content=101336
Version KDE 5: https://store.kde.org/p/1190292/
Je sais que cela fait plusieurs années que la question a été posée. mais avec le systemd (principalement disponible avec centos et REHL), vous pouvez exécuter cette commande bash avec cron pour vérifier et redémarrer si le service est en panne.
#!/bin/bash
service=$@
/bin/systemctl -q is-active "$service.service"
status=$?
if [ "$status" == 0 ]; then
echo "OK"
else
/bin/systemctl start "$service.service"
fi
enregistrez-le dans votre répertoire bin et nommez-le comme moniteur. Donnez-lui l'autorisation de fichier appropriée. puis lancez-le comme
Sudo monitor redis
si vous voulez vérifier le service Redis et redémarrer/démarrer si nécessaire.
enfin, ajoutez ceci à votre travail cron.
espérons que cela aidera
Pour ajouter à la longue liste de supervision init/svc, en tant que sous-répertoire de S6, un nouvel enfant, 66 ans, gère la gestion du service S6 et la journalisation de manière rapide, légère et conviviale. Ceci est le lien vers la documentation officielle d’Obarun-Linux https://web.obarun.org/software
Ceci est un FAQ expliquant comment utiliser ce logiciel et donner un sens à s6 http://sysdfree.wordpress.com/266
Depuis sa version stable, un seul bogue a été trouvé concernant les modifications du noyau de 4.20 -> 5.0. Tous les autres problèmes signalés concernaient des personnes qui apprenaient quelque chose de nouveau. Si la gestion des services devait devenir plus simple, il serait peut-être préférable de passer à ms-windows (Linus interdire). Pour voir dans la vie réelle comment cela peut fonctionner, il suffit de télécharger un Obarun live.iso et de jouer avec. Installez les services et leurs 66 scripts pour les activer, les tuer, consulter leurs journaux, les arrêter et les démarrer (tout en les activant), regrouper les services dans une arborescence et faire en sorte que les arborescences de services démarrent et s'arrêtent toutes ensemble du système. Il fait ce que s6 fait bien et il est plus simple pour l'utilisateur d'exploiter le système pare-balles sous s6.
Vous pouvez télécharger les images ici: https://web.obarun.org/index.php?id=74 Fichiers de vérification md5 https://repo.obarun.org/iso/
Hormis Init et la gestion des services, les S6/66 n’ont aucune dépendance vis-à-vis du système. C’est une couche du système de base qui laisse le reste du logiciel fonctionner seul, init/svc-mgmt blind. Tous les s6 et 66 sont écrits en C et ce n'est pas spécifique à Linux ni à la glibc. Les serveurs de Skarnet (auteurs S6) fonctionnent depuis presque dix ans sans beaucoup de pauses sur le système personnalisé Musl. Actuellement, Alpine, Void et Adelie ont également le logiciel s6 dans leurs référentiels. Adelie l'utilise par défaut pour la supervision des services. Void porte maintenant 66 aussi. Je ne sais pas si et dans quelle mesure quelqu'un a porté s6 à xxBSD ou à d'autres systèmes xxIX.