Supervisor permet de surveiller un process et de le relancer si il plante.
Toute la doc officiel par ici ⇒ http://supervisord.org/
Avant de détailler plus en détail, lisez ce lien ⇒ https://serversforhackers.com/editions/2014/08/12/process-monitoring/
Les fichiers de config doivent être écrit dans /etc/supervisor/conf.d. Voici un exemple basic
[program:my_app] command=/path/to/my/script autostart=true autorestart=true user=toto stdout_logfile=/var/log/supervisor/apicarine_worker.log stderr_logfile=/var/log/supervisor/apicarine_error.log
Si vous souhaitez lancer plusieurs instances, vous devez spécifier le nom des process avec obligatoirement la variable %(process_num)s
[program:my_app] command=/path/to/my/script process_name=worker_%(process_num)02d numprocs=4 autostart=true autorestart=true user=toto stdout_logfile=/var/log/supervisor/apicarine_worker.log stderr_logfile=/var/log/supervisor/apicarine_error.log
Si vous souhaitez que supervisor se place dans un répertoire avant de lancer la commande, ajoutez
directory=/tmp
Pour se mettre dans le shell de supervisor
supervisorctl
supervisor> help default commands (type help <topic>): ===================================== add clear fg open quit remove restart start stop update avail exit maintail pid reload reread shutdown status tail version
Pour lire les fichiers de config
> reread
Pour appliquer les fichiers de config
> update
Lister les process dispo
> avail
Pour désactiver un process
> remove nom_du_process
Activer un process
> add
Voir ce qui se passe dans un process
> fg nom_du_process
En cas de crash on aimerait bien recevoir un mail, pour cela il faut utiliser un script python
https://github.com/Supervisor/superlance/blob/master/docs/index.rst
apt install python-pip pip install superlance ou easy_install superlance
si il manque des dépendances python, installez-les
Ensuite, créer une config pour supervisor ( https://github.com/Supervisor/superlance/blob/master/docs/crashmail.rst )
[eventlistener:crashmail] command=crashmail -p program1 -p group1:program2 -m dev@example.com events=PROCESS_STATE_EXITED
puis
supervisorctl reread supervisorctl update
On peut aussi spécifier le mail de l’expéditeur, mettre l’option -a pour recevoir un mail peut importe le programme qui crash et mettre l’event PROCESS_STATE pour recevoir un mail sur chaque changement d’état.
[eventlistener:crashmail] command=crashmail -a -m dev@example.com -s '/usr/sbin/sendmail -t -i -F Supervisor -f supervisor@example.com' events=PROCESS_STATE
Plus d’info sur les events ⇒ http://supervisord.org/events.html
Supervisord rotate lui même ses logs (si > 50Mo, rotate sur 10 fichiers par défaut) mais si vous voulez utiliser logrotate, il est important de mettre l’option copytruncate dans votre fichier de config sinon les logs continuent à s’écrire dans l’ancien fichier de log
copytruncate
Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place.
/var/log/supervisor/my_app_*.log {
daily
rotate 60
copytruncate
compress
missingok
notifempty
}
Puis de désactivez aussi la taille max des logs et la rotation automatique
[program:my_app] directory=/opt/%(program_name)s command=/opt/%(program_name)s/run stderr_logfile=/var/log/supervisor/%(program_name)s_stderr.log stdout_logfile=/var/log/supervisor/%(program_name)s_stdout.log stdout_logfile_maxbytes=0 stderr_logfile_maxbytes=0 stdout_logfile_backups=0 stderr_logfile_backups=0
Vous pouvez aussi rediriger les logs d’erreurs dans les logs de la sortie standard avec
redirect_stderr=true