Assurez-vous qu'un processus est toujours en cours d'exécution

J'ai commencé à héberger des sites il y a quelque temps en utilisant Cherokee. Pour les sources externes (FastCGI, etc.), il a une option pour lancer le processus s'il ne peut pas en trouver un en cours d'exécution sur le socket ou le port désigné. C'est génial car cela signifie que si PHP ou un site Django tombe (comme ils le font parfois), il le redémarre automatiquement.

Sur un nouveau serveur utilisant PHP-FPM, je ne pouvais pas utiliser Cherokee (il y a un bug avec PHP) donc je suis passé à NGINX. J'aime vraiment NGINX (pour son style de configuration) mais j'ai de sérieux problèmes avec les processus qui tombent et ne réapparaissent jamais. PHP le fait parfois mais les sites Django posent plus de problèmes. J'ai créé des scripts d'initialisation pour eux et ils apparaissent au démarrage, mais cela ne m'aide pas s'ils se dérobent entre les redémarrages.

Je suppose que je recherche un proxy FastCGI. Quelque chose qui, comme Cherokee, sait quels processus doivent être exécutés sur quels sockets / ports et les réapparaît à la demande. Une telle chose existe-t-elle? Existe-t-il un moyen d'intégrer cela dans NGINX (pour faciliter la configuration)?

Que diriez-vous de daemontools et en particulier de l'outil de supervision

superviser surveille un service. Il démarre le service et redémarre le service s'il meurt. La configuration d'un nouveau service est simple: tous les besoins de supervision sont un répertoire avec un script d'exécution qui exécute le service.

réapparaître dans inittab

J'appuie la daemontoolssuggestion, mais si vous n'aimez pas le fonctionnement du logiciel DJB (pour une raison quelconque), il y en a aussi supervisord.

J'ai mis en place une image FreeBSD il y a quelque temps qui servait supervisordà gérer nginxet gunicorn, que j'utilisais pour héberger des applications WSGI simples, et l'ensemble du processus était assez simple.

Si vous faites cela pour Django, Gunicorn facilite vraiment le déploiement des applications Django, btw. Voir cet article de blog pour plus de détails.

Une autre option pourrait être d'utiliser monit , qui est généralement celle que j'utilise.

Avez-vous réfléchi god?

Dieu est un cadre de surveillance facile à configurer et à étendre, écrit en Ruby.

Garder vos processus et tâches serveur en cours d'exécution devrait être une partie simple de votre processus de déploiement. Dieu vise à être l'application de surveillance la plus simple et la plus puissante disponible.

Je l'utilise pour m'assurer que si les instances Rails / nginx tombent, elles sont relancées, et bien que je ne vois pas de support intégré pour vérifier s'il utilise le bon port ou non, mais si le problème est que le processus échoue ou ne fonctionne plus, vous ne pouvez pas vous tromper god.

En plus de daemontools et de supervisord, il y a daemonize .

Une solution hackée serait de lancer périodiquement un script (via cron) qui détecte si le processus est en panne, et dans ce cas le relancer.

Il existe différentes façons de redémarrer un démon défaillant, la recommandation habituelle est de "réapparaître dans inittab" mais avec une certaine considération de limite si la machine est vraiment vissée.

Le démon de surveillance peut également surveiller un processus via son fichier PID. Cependant, cela ne doit être considéré que comme une ligne de défense secondaire pour redémarrer une machine trop malade pour fonctionner correctement (par exemple, manque de mémoire, bombardement à la fourche, etc.), et non pas comme un moyen principal ou de surveiller et de redémarrer un démon.

Enfin, vous pouvez envisager de surveiller des systèmes complexes à l'aide de nagios pour fournir aux administrateurs une vue globale. Il peut exécuter des plug-ins pour sonder le fonctionnement du démon en externe, ce qui est un test plus complet de son fonctionnement que le PID en direct.

Réponse simple - commencez, écrivez votre pid quelque part, et toutes les x fois (secondes, minutes, votre pari) vérifiez si le processus est en cours.

Réponse longue - toutes ces réponses sont de bonnes méthodes. Mais un peu compliqué.

Gardez également à l'esprit qu'être en vie et répondre aux demandes sont des choses différentes.