Nginx config reload sin tiempo de inactividad

123

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

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?

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

Respuestas:

180

Correr service nginx reloado/etc/init.d/nginx reload

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

A veces es posible que desee anteponer sudo

Hengjie
fuente
10
Ambos deben hacer exactamente lo que dice la pregunta: enviar SIGHUPal proceso maestro 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
1
¿Sabes cuál es la diferencia entre service nginx reloady nginx -s reload? Si ejecuto el primero, obtengo este resultado: Reloading nginx configuration: nginx.pero mis cambios no se actualizan. Si ejecuto este último, no obtengo salida, pero mis cambios se reflejan.
Ryan Quinn el
Simplemente intenté esto después de agregar una log_not_founddirectiva, pero descubrí que tenía que reiniciar para que funcione. ¿Supongo que la recarga no funciona para todas las directivas?
mydoghasworms
81

correr /usr/sbin/nginx -s reload

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

Shiv Kumar Sah
fuente
Finalmente, un comando que funciona en Debian Jessie.
danger89
1
Esta es una mejor manera. Porque su servidor no se cae si sus configuraciones tienen errores (solo muestra errores en este caso).
Mir-Ismaili
si nginx default pid no está en la ubicación predeterminada, necesita '-p'. es decir: `/ opt / gitlab / embedded / sbin / nginx -s reload -p / var / opt / gitlab / nginx`
qxo
9

No, usted es incorrecto, se supone que no debe enfrentar ningún tiempo de inactividad con el procedimiento que describe. (Nginx no solo puede recargar la configuración sobre la marcha sin ningún tiempo de inactividad, sino 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 , enviar la HUPseñal a nginx asegura que se realice un reinicio correcto y, si los archivos de configuración son incorrectos, se abandona todo el procedimiento y usted " se queda con el nginx como antes de enviar la HUPseñ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.

cnst
fuente
2

Por lo general, la recarga del archivo de configuración de un servicio no debería afectar el servicio en ejecución. Sin embargo, esto depende de cómo SIGHUPse procese la señal.

Si un servicio específico está experimentando 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.

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