Pregunta Configuración de Nginx recargar sin tiempo de inactividad


Yo uso nginx como un proxy inverso. Cada vez que actualizo la configuración para ello usando

sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/nginx.pid`"

Me enfrento a un breve tiempo de inactividad. ¿Cómo puedo evitar eso?


93
2018-04-11 17:13


origen


¿Están destinados a ser comandos de línea de comandos? Nunca he visto a nadie envolver un comando sudo completo entre comillas como esa, puede que no sea necesario. - brianmearns
Solo un comentario general: creo que la práctica estándar / recomendada es crear un enlace simbólico / simbólico para la configuración de su sitio en sites-enabled, no copiarlo. No está relacionado con su problema particular, pero es posible que desee analizarlo. - brianmearns
Usted no debe estar enfrentando un tiempo de inactividad. kill HUP Es la manera de hacer una recarga elegante en nginx. - Jonathan Vanasco


Respuestas:


correr service nginx reload o /etc/init.d/nginx reload

Hará una recarga en caliente de la configuración sin tiempo de inactividad. Si tiene solicitudes pendientes, entonces habrá procesos nginx persistentes que manejarán esas conexiones antes de que mueran, por lo que es una forma extremadamente elegante de volver a cargar las configuraciones.

A veces es posible que desee anteponer con sudo 


153
2018-04-11 17:24



Ambos deben hacer exactamente lo que dice la pregunta: enviar SIGHUP al proceso maestro de nginx. No debería haber una diferencia. nginx.org/en/docs/control.html - Gnarfoz
Cuando emito el comando en CentOS, sigue diciendo "Uso /etc/init.d/nginx (start..stop ... restart..reload)" .. y así es exactamente como lo usé. Dentro del archivo /init.d/nginx encontré kill -HUP cat $PIDFILE || echo -n "no se puede recargar" - mashup
¿Sabes cuál es la diferencia entre service nginx reloady nginx -s reload? Si ejecuto el primero, obtengo esta salida: Reloading nginx configuration: nginx., pero mis cambios no están actualizados. Si ejecuto este último, no obtengo salida, pero mis cambios se reflejan. - Ryan Quinn
Acabo de intentar esto después de agregar un log_not_found pero encontré que tenía que hacer un reinicio para que funcionara. ¿Supongo que la recarga no funciona para todas las directivas? - mydoghasworms


correr /usr/sbin/nginx -s reload

Ver http://wiki.nginx.org/CommandLine para más opciones de línea de comandos.


55
2017-07-27 13:46



Finalmente, un comando que funciona en Debian Jessie. - danger89
Esta es una manera mejor Porque tu servidor no abajo Si sus configuraciones tienen errores (solo muestra errores en este caso). - Mir-Ismaili


No, usted es incorrecto, se supone que no debe enfrentar ningún tiempo de inactividad con el procedimiento que describe. (Nginx no solo puede hacer recargas de configuración sobre la marcha sin ningún tiempo de inactividad, sino que incluso la actualización del ejecutable sobre la marcha, aún sin ningún tiempo de inactividad).

Según http://nginx.org/docs/control.html#reconfiguration, enviando el HUP la señal a nginx se asegura de que se realice un reinicio correcto y, si los archivos de configuración son incorrectos, se abandona todo el procedimiento, y queda con el nginx como antes de enviar el HUP señal. En ningún momento debe ser posible ningún tiempo de inactividad.

Para que nginx vuelva a leer el archivo de configuración, se debe enviar una señal HUP al proceso maestro. El proceso maestro primero verifica la validez de la sintaxis, luego intenta aplicar una nueva configuración, es decir, abrir archivos de registro y nuevos sockets de escucha. Si esto falla, revierte los cambios y continúa trabajando con la configuración anterior.


8
2018-06-22 16:58





Normalmente, la carga del archivo de configuración de un servicio no debería afectar al servicio en ejecución. Sin embargo, esto depende de cómo el SIGHUP se procesa la señal.

Si un servicio específico experimenta un tiempo de inactividad durante la recarga, esto puede evitarse ejecutando el mismo servicio en varios servidores, preferiblemente utilizando un equilibrador de carga. En este caso, puede sacar un servidor a la vez y volver a cargarlo / reiniciarlo. Luego, se puede volver a agregar después de confirmar que está bien.


2
2018-04-11 17:24



Si bien esto no responde directamente a la pregunta, este es definitivamente un escenario de mejor práctica que el OP debería seguir para evitar el tiempo de inactividad en general. - Andrew M.
Detalles sobre cómo nginx maneja diferentes señales: nginx.org/en/docs/control.html - Gnarfoz