Question Un moyen simple de redémarrer les processus bloqués?


Je dois surveiller plusieurs processus en cours d'exécution sur mon serveur Web. Pour une raison quelconque, le vernis se bloque actuellement une ou deux fois par jour. J'utilise monit pour prétendument redémarrer le vernis automatiquement, mais cela ne fonctionne pas. Voici mon entrée monit.conf pour Varnish.

check process varnish with pidfile /var/run/varnish.pid
    start program = "/etc/init.d/varnish start" with timeout 60 seconds
    stop program = "/etc/init.d/varnish stop"
    if failed host <my server ip> port 80 protocol http
        and request "/blank.html" then restart
    if 3 restarts within 5 cycles then timeout
    group server

Le fichier journal indique qu'après l’arrêt du vernissage, les tentatives de redémarrage ont ensuite échoué. Puis finalement, monit cesse de surveiller le vernis.

Quelqu'un a des suggestions sur la façon dont je peux résoudre ce problème? Ou, mieux encore, pouvez-vous suggérer d'autres moyens simples de surveiller et de redémarrer automatiquement les processus bloqués? Merci!


10
2017-08-11 22:09


origine




Réponses:


Je regarderais dans daemontools (http://cr.yp.to/daemontools.html).

Supervise a été conçu dans ce but précis: démarrer les processus et les surveiller, les redémarrer immédiatement s'ils se terminent.

Vous pouvez toujours utiliser monit si vous devez effectuer quelque chose de plus compliqué qu'une simple vérification "est-il toujours en cours d'exécution", et si le processus doit être redémarré, faites-le par le biais de la supervision.


17
2017-08-11 22:41



J'utilise aussi daemontools pour surveiller les processus de services instables. Très pratique si je devais le dire. :-) - edomaur
C'est très utile. Merci! - Lin


Vous pouvez aussi utiliser / etc / inittab pour redémarrer des processus inactifs à l'aide du renaître action.

Voir la section inittab sur http://aplawrence.com/Unixart/startup.html


4
2017-08-12 16:20





Vous pouvez utiliser scripts de gestionnaire d'événement avec Nagios si vous avez cela en place pour redémarrer les services.

Si le vernis nécessite une autorisation root pour démarrer (les scripts init.d le font habituellement), remplacez "/etc/init.d/varnish start" par "sudo /etc/init.d/varnish start". Mais ce ne sera probablement pas assez, étant donné que vous ne voulez probablement pas donner à l’utilisateur quel qu’il soit exécuté en tant que privilèges total sudo nopasswd pour toutes les commandes, et donner un script shell à sudo serait fondamentalement tout aussi mauvais. Vous devrez donc déterminer quelles commandes de ce script init ont besoin de sudo, attribuez à l'utilisateur monit les privilèges sudo figurant dans le fichier / etc / sudoers, puis modifiez ce script init en conséquence. Ou peut-être au lieu de tout ce vernis peut être exécuté en tant qu'utilisateur non root?

Enfin, je suis sûr que vous le savez, mais je vais le dire quand même. Vous mettez clairement beaucoup d'efforts dans ce domaine, j'espère que vous faites autant d'efforts pour comprendre pourquoi le vernis se bloque et pour le réparer (ou pourchasser les développeurs pour comprendre pourquoi) :-)

Mettre à jour:
Cela peut ne pas être aussi simple, mais un moyen facile de le faire en tant que root peut être de configurer un script qui vérifie si le processus est bon et, sinon, le démarre. Ensuite, exécutez ce script toutes les deux minutes en tant que tâche cron.


2
2017-08-12 00:42



Au début, je pensais à Nagios, mais je voulais quelque chose de petit et simple pour moi. Et oui, je me penche sur la question du vernis. Un de mes serveurs fonctionne de manière stable depuis très longtemps, donc cela a certainement à voir avec moi. :( - Lin


Une autre bonne méthode tiré de StackOverflow:

until myserver; do
    echo "Server 'myserver' crashed with exit code $?.  Respawning.." >&2
    sleep 1
done

Cela pourrait être ajouté à la crontab:

crontab -e

Ajoutez ensuite une règle pour démarrer votre script de moniteur:

@reboot /usr/local/bin/myservermonitor

Ou ajouté en tant que script dans /etc/init.d

Voir le Réponse StackOverflow pour une explication détaillée sur les raisons pour lesquelles il s’agit d’une bonne approche.


1
2017-11-05 22:51





Je recherchais également le moyen le plus simple de gérer ce problème. Le moyen le plus simple que je puisse trouver est simplement d'ajouter Restart=allwaysau concernant .service déposer dans /etc/systemd/system/multi-user.target.wants/ comme dernière ligne du [service] étiquette.

Après cela sudo systemctl daemon-reload suivi par sudo systemctl restart service.service pour recharger les modifications.

Vous pouvez tester en vérifiant si le service est en cours d'exécution: systemctl status processname, vérifiez l’horodatage de début. Après cela ps -ef | grep servicename, ad tuer le processus avec l'identifiant trouvé kill 1234. après cela systemctl status processname à nouveau et vérifiez si l'horodatage de démarrage est mis à jour.

Cela devrait fonctionner sur:

  • Debian 7 et Debian 8
  • Ubuntu 15.04 et plus récent
  • CentOS 7 et futured

0
2017-12-19 13:34