El supervisor no carga nuevos archivos de configuración

Tengo un problema al implementar la aplicación Django con Gunicorn y Supervisor. Si bien puedo hacer que Gunicorn sirva mi aplicación (configurando el PYTHONPATH adecuado y ejecutando el comando apropiado, el de la configuración del supervisor) no puedo hacer que el supervisor lo ejecute. Simplemente no verá mi aplicación. No sé cómo asegurarme de que el archivo de configuración esté bien.

Esto es lo que dice supervisorctl:

# supervisorctl start myapp_live
myapp_live: ERROR (no such process)

Lo estoy ejecutando en Ubuntu 10.04 con la siguiente configuración:

Archivo /home/myapp/live/deploy/supervisord_live.ini:

[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true

En /etc/supervisor/supervisord.conf, al final del archivo, hay:

[include]
files = /etc/supervisor/conf.d/*.conf

y aquí hay un enlace simbólico a mi archivo de configuración:

# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root   48 Dec  4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini

todo me parece bien, pero supervisorctl sigue diciendo myapp_live: ERROR (no such process). ¿Alguna solución para esto?

Tuve el mismo problema, un

sudo service supervisord reload

hizo el truco, aunque no sé si esa es la respuesta a tu pregunta.

La respuesta correcta es que el supervisor requiere que vuelva a leer y actualizar cuando coloca un nuevo archivo de configuración. Reiniciar no es la respuesta, ya que eso afectará a otros servicios. Tratar:

supervisorctl reread
supervisorctl update

Asegúrese de que los archivos conf de su supervisor terminen en .conf

Me tomó un tiempo entender eso. Esperemos que ayude a la próxima persona.

Recargar el proceso del supervisor maestro puede funcionar, pero tendrá efectos secundarios no deseados si el supervisor supervisa más de un proceso.

La forma correcta de hacerlo es emitir, lo supervisorctl rereadque hace que escanee los archivos de configuración en busca de cambios:

root@debian:~# supervisorctl reread
gunicorn: changed

Luego, simplemente vuelva a cargar esa aplicación:

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started

Encontré este problema usando el paquete supervisor, versión 3.0a8-1.1 de Ubuntu Server 12.10. Terminé resolviendo el problema leyendo la ayuda integrada:

$ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

En particular, desea utilizar la sintaxis:

sudo supervisorctl restart myapp_live:*

Como lo indica la documentación en http://supervisord.org/configuration.html#programx-section - "Una sección [program: x] en realidad representa un" grupo de proceso homogéneo "para el supervisor (a partir de 3.0)". Entonces, tal vez el problema surgió por primera vez en la versión 3.0.

PD: soy nuevo en supervisor; Estoy usando https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor como un ejemplo de cómo debería ser una configuración mínima.

Tuve un problema similar ( myapp_live: ERROR (no such process)) y fue porque la definición de mi proceso era

[program: myapp_live]

cuando debería haber sido

[program:myapp_live]

Si bien esto no responde a la pregunta que se me hizo, fui conducido aquí por la Búsqueda que estaré buscando una solución a mi problema, por lo que espero que otras personas también la encuentren aquí.

Encontré que esta solución es la más conveniente:

EDITAR: antes de hacer esto, verifique su ruta de supervisorctl which supervisorctlpara asegurarse de que está agregando la ruta correcta a los sudoers.

Agregue esta línea al archivo sudoers usando visudo(donde: myappuser- el usuario que necesita reiniciar su aplicación, myapp- nombre de la aplicación):

myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

Y luego simplemente:

sudo supervisorctl restart myapp

No está vinculado a los scripts de inicio de la distribución y le otorga privilegios bastante limitados al usuario que reinicia su aplicación gunicorn. Además, no necesita preocuparse por pid. El comando no solicitará contraseña, por lo que es adecuado para scripts de bash / fabric de implementación automática. Por otro lado, debe tener en cuenta que si supervisorctl es vulnerable a algún error que causa la ejecución del código, un usuario malintencionado podría usar este privilegio sudo para ejecutar el código como root (pero que yo sepa, no se descubrió dicho error para el supervisor y es una gran cosa encontrar tal vulnerabilidad).

Leyendo el código de supervisorctl.py aquí: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Puede ver que la actualización supervisorctl (función do_update) está llamando a reloadConfig () exactamente como lo hace supervisorctl reread (función do_reread).

Así que creo que no es necesario volver a llamar si se llama a actualizar después de eso.

Según el resultado de git blame, ha sido así desde al menos desde julio de 2009.

Aquí hay una lista de verificación:

1. El nuevo archivo de configuración debe nombrarse de acuerdo con el patrón de inclusión configurado en /etc/supervisord.conf:

   [include]
   files=supervisord.d/*.ini
   

   Como vemos en mi caso, se incluiría spam.ini, pero no se enviaría spam.conf.

2. Si creó el nuevo archivo copiando uno antiguo, asegúrese de cambiar realmente la [program:]línea. Porque si eres tan estúpido como tener dos archivos para el mismo programa, supervisorctl rereadte dejará con este mensaje de error sin remedio como castigo:

   No config updates to processes
   

3. Si se detecta su archivo, supervisorctl rereaddebería decir algo como:

   spam: available
   

4. Entonces, supervisorctl update spamambos deberían iniciarlo y hacer que aparezca supervisorctl status.

He encontrado que los scripts init.d no son confiables en una variedad de diferentes versiones de Ubuntu / Debian. La forma de hacerlo es esta:

sudo supervisorctl reload

Tenga cuidado con los enlaces simbólicos e incluya archivos en Supervisor. Permitiría a cualquier persona con privilegio w en /home/myapp/live/deploy/supervisord_live.ini cambiar el archivo ini e iniciar cualquier código malicioso. Estos archivos ini deben estar dentro del directorio conf de su supervisor o en cualquier subdirectorio debajo de él.

Instalé supervisrod con yum install, que instaló el supervisor de la versión v2. *. Supervisor solo incluye versiones externas de la versión 3. En su lugar, tuve que usar easy_install para instalar el supervisor v3.