Reiniciar Unicornio con USR2 no parece volver a cargar las configuraciones de production.rb

Estoy ejecutando unicornio y estoy tratando de obtener cero reinicios de tiempo de inactividad trabajando.Reiniciar Unicornio con USR2 no parece volver a cargar las configuraciones de production.rb

Hasta ahora, es una salsa increíble, el proceso maestro se divide e inicia a 4 nuevos trabajadores, luego mata al anterior, todos están contentos.

Nuestros guiones de enviar el siguiente comando para reiniciar unicornio:

kill -s USR2 `cat /www/app/shared/pids/unicorn.pid`

En la superficie todo lo que se ve muy bien, pero resulta que el unicornio no está recargando production.rb. (Cada vez que implementamos, cambiamos el valor config.action_controller.asset_host a un nuevo punto final de contenedor CDN con nuestros recursos precompilados).

Después de reiniciar unicornio de esta manera, el host de recursos sigue apuntando a la versión anterior. Al hacer un reinicio real (es decir, detener el proceso maestro, luego iniciar el unicornio nuevamente desde cero) se recogen los nuevos cambios de configuración.

preload_app se establece en true en nuestro archivo de configuración de unicornio.

¿Alguna idea?

Fuente

2012-02-22 Michael Shimmins

¿Su configuración de unicorn.rb intenta matar el proceso en .oldbin? Ver solución: http: // jessewolgamott.com/blog/2012/01/02/the-one-where-unicorn-does-not-update/ –

Definitivamente está matando a un viejo maestro: una vez que se completa el reinicio y los trabajadores están listos, 'ps -ef | grep unicorn' muestra solo el maestro y 4 procesos de trabajo. El pid del maestro es diferente al pid del antiguo maestro antes de emitir el USR2. –

Supongo que sus unicornios se reinician en el antiguo directorio de producción en lugar del nuevo directorio de producción; en otras palabras, si su directorio de trabajo en unicorn.rb es <capistrano_directory>/current, debe asegurarse de que el enlace simbólico ocurra antes intenta reiniciar los unicornios.

Esto explicaría por qué la detención y puesta en marcha manual de las mismas funciona: se está haciendo ese post-despliegue, presumiblemente, lo que hace que comiencen en el directorio correcto.

¿Cuándo en su proceso de implementación está reiniciando los unicornios? Debe asegurarse de que la señal USR2 se envíe después de que el nuevo directorio de publicación esté enlazado como actual.

Si esto no ayuda, por favor gire su unicorn.rb y deploy.rb; será mucho más fácil depurar este problema.

Fuente

2012-02-26 01:25:15 Veraticus

Respondió indirectamente a la pregunta, ¡gracias! El reinicio fue emitido después de que se completó el enlace simbólico, pero me hiciste buscar en el lugar correcto. La configuración de unicornio tenía el directorio de trabajo configurado en una declaración 'File.expand' que se estaba resolviendo en el destino del enlace simbólico, no en el enlace simbólico en sí. Lo cambié a la ruta absoluta del enlace simbólico y funciona perfectamente. –

(PD: otorgaré la recompensa mañana cuando el reloj se haya agotado). –

¡Me alegro de que funcionó! ¡Yay, gracias! = D – Veraticus

Tenga en cuenta que: su directorio de trabajo en unicorn.rb debería ser: /tu/cap/directorio/corriente

NO ser: File.expand_path (" ../. . ", ARCHIVO)

Debido a que el unicornio y el enlace suave de Linux bifurcan el error: el enlace suave no puede funcionar bien.

por ejemplo:

cd #current actual es un enlace simbólico a otro directorio

... ...

cuando tenemos nuestro directorio de trabajo, que tiene la ruta absoluta no es el ruta en "actual"

Fuente

2013-10-15 17:09:05 fantaxy025025

Reiniciar Unicornio con USR2 no parece volver a cargar las configuraciones de production.rb

Respuesta

Cuestiones relacionadas