El supervisor no carga nuevos archivos de configuración

68

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?

grucha
fuente
Me estaba rascando la cabeza con el mismo problema; mis archivos de configuración no se estaban cargando cuando ejecuté rereado update. Resultó que había ahorrado mis archivos de configuración como foo.conf.pylugar de foo.conflo que no se están identificando.
Timmy O'Mahony

Respuestas:

31

Tuve el mismo problema, un

sudo service supervisord reload

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

Hixi
fuente
2
Paré y luego comencé a supervisar hace algún tiempo y funcionó. No sé si funcionaría recarga (como el reinicio del corazón que no lo hace), pero supongo que podría
grucha
Yo también lo hice y funcionó. Me pregunto por qué /etc/init.d/supervisor restartno funciona cuando la parada manual y el inicio lo hacen.
Kirill
1
Funcionó para mí, aunque el servicio no funcionó, así que simplemente corrí ps aux | grep supervisory luegosudo kill -HUP pid
Wayne Werner
2
Esto es peligroso ya que reiniciará todo el demonio supervisor.
Mark Theunissen
77
supervisorctl reread puede arreglar esto también sin reiniciar el servicio.
Jonathan Liuti
199

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
Mark Theunissen
fuente
13
Esta debería ser la respuesta correcta. "supervisor releído" por sí solo no es suficiente.
Miebster
3
+1 Esta es una mejor respuesta porque no depende de los gestores de procesos.
tidwall
8
"supervisorctl reread" por sí solo no es suficiente, pero ¿no sería suficiente "supervisorctl update"? De acuerdo con la documentación, "actualización" hace una nueva lectura seguida de un reinicio de cualquier programa cuya configuración haya sido modificada por la nueva lectura.
BlueBomber
Funciona para mi. He reiniciado después.
user1012513
15

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.

nym
fuente
1
Perdimos una hora en el mismo problema, no puedo creer que fuera así de simple.
Zane Hooper
1
Gracias por enumerar esta respuesta. Por mi vida, no pude resolver esto.
Phillip Martin
14

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
Burhan Khalid
fuente
Esta es la mejor solución si solo desea leer un archivo de configuración nuevo / modificado y dejar intactos el resto de los procesos en ejecución. Supervisorctl mostrará que la nueva aplicación es avail. Agréguelo a los procesos (re) iniciables mediante la emisión supervisorctl update. Ver también la respuesta de Mark serverfault.com/a/479754/125887
Sjaak Trekhaak
44
Esto no fue suficiente para mí. supervisorctl updatefue necesario.
Yaroslav Nikitenko
5

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.

picomancer
fuente
4

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í.

Conrad.Dean
fuente
¡Igual que aquí! Lo había dejado [program]solo, siguiendo los documentos, pero hacerlo lo [program:redis]hizo funcionar para mí. ¡Las cosas se ponen raras a veces!
ankush981
2

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).

pielgrzym
fuente
2

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.

Sebastien Estienne
fuente
2

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.

usuario2394284
fuente
1

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
mafrosis
fuente
Esta no es la forma correcta de hacerlo, aunque funcionará en muchas circunstancias. La respuesta de @ burhan-khalid es la correcta y proporciona una explicación.
glarrain
1

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.

Leo Pepe
fuente
0

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.

Aidas
fuente
Este también fue mi problema, probablemente ocurrirá en todas las instalaciones de Centos 6.5 o menos.
bearrito