J’ai quelques scripts qui se mettent à planter des fois, je sais que c’est parceque je les ai codé comme un gros porc mais ça m’emmerde de les refaires parceque après tout ils font ce que je leur dit de faire, c’est juste qu’ils plantent des fois.
Ceci dit j’ai aussi des applications qui ne sont pas mienne qui plantent (privoxy, tor, des fois même lighttpd) et là on est bien content que quelqu’un puisse le relancer pendant qu’on est en train de se cuiter au bar du coin.
Voici un petit script tout simple en python que je lance avec un crontab à intervalles réguliers.
Exemple pour nginx, on va rechercher le process à partir du mot clef “nginx”:
ps aux | grep nginx root 29231 0.0 0.0 22144 948 ? Ss 13:05 0:00 nginx: master process /usr/local/sbin/nginx -c /usr/local/nginx/conf/nginx.conf |
Dans le script ça donne:
#!/usr/bin/env python # -*- coding: utf-8 -*- # vim: ai ts=4 sts=4 et sw=4 """ check if script is running else relaunch """ import sys import os from subprocess import Popen, call, PIPE SUCCESS_EXIT_CODE=0 ERR_PS_SCRIPT_RUNNING=3 ERR_PID_SCRIPT_RUNNING=4 def check_ps_cmd(script_name): try: p1 = Popen(["ps", "aux"], stdout=PIPE) p2 = Popen(["grep", script_name], stdin=p1.stdout, stdout=PIPE) p3 = Popen(["grep", "-v", "grep"], stdin=p2.stdout, stdout=PIPE) output = p3.communicate()[0] return output except Exception, e: print >>sys.stderr, "Execution failed:", e return None # process to check if not check_ps_cmd('nginx'): print "Nginx dead, relaunch..." retcode = call("service nginx restart", shell=True) # add here new processes to check... |
On peut imaginer mettre un sendmail pour se voir notifier lors de la mort d’un process et ainsi briller en soirées mondaines lorsque votre téléphone vous bippe sous le nom de Jarvis vous avertissant de la mort prématurée de lighttpd suite à votre toute dernière super config que vous avez pris soins de mettre en prod un vendredi soir sans vous soucier de la tester et ce juste avant de partir du bureau dont la clef est dans la poche du boss qui vient de se tirer en long weekend avec sa secrétaire…
Intéressant, c’est vrai qu’un supervisord ne vaut que pour ses services.
Sinon une petite simplification pour vérifier que le processus existe est d’utiliser pgrep au lieu d’un ps|grep.
Ou pour redémarrer supervisord lui-même.
A noter que ce script sr plait dans une task celerybeat, lui-même lancé par supervisord.
Bref, toute la toolchain se recoupe.
Ça fait un peu secte qui va finir en suicide collectif :)
Sinon sur mes environnement de prod je n’ai jamais eu de plantage de supervisord. Du coup si ça m’arrive j’aurais une piste pour la solution.
Tu donnes tout à skipppppy
Pgrep est interressant mais pas dispo sur mon mac par exemple, avec ps on maximise la compatibilité.
Ah… étant sous Debian partout et la commande étant fourni dans le même paquet que ps j’ai cru que c’était standard.
OSX en même temps… :-p
Du coup il faudrait installer ça : http://sourceforge.net/projects/proctools/ , mais l’argument de la compatibilité est plus que valable.