Configuração da configuração do Nginx sem tempo de inatividade


123

Eu uso o nginx como um proxy reverso. Sempre que eu atualizo a configuração usando

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

Enfrento um breve período de inatividade. Como posso evitar isso?


1
São para serem comandos de linha de comando? Eu nunca vi alguém envolver um comando sudo inteiro em aspas como essa, pode não ser necessário.
Brianmearns

4
Apenas um comentário geral: acho que a prática padrão / recomendada é criar um link simbólico / flexível para a configuração do seu site sites-enabled, e não copiá-lo. Não está relacionado ao seu problema específico, mas você pode querer analisar isso.
Brianmearns

1
Você não deve estar enfrentando um tempo de inatividade. kill HUPé a maneira de fazer uma recarga normal no nginx.
Jonathan Vanasco 6/16

Respostas:


180

Executar service nginx reloadou/etc/init.d/nginx reload

Ele fará um recarregamento quente da configuração sem tempo de inatividade. Se você tiver solicitações pendentes, haverá processos nginx remanescentes que manipularão essas conexões antes que elas morram, por isso é uma maneira extremamente elegante de recarregar as configurações.

Às vezes, você pode querer anexar com sudo


10
Ambos devem fazer exatamente o que a pergunta indica: enviar SIGHUPpara o processo principal do nginx. Não deve haver diferença. nginx.org/en/docs/control.html
Gnarfoz

Quando emito o comando no CentOS, ele continua dizendo "Uso /etc/init.d/nginx (start..stop ... restart..reload)" ... e foi exatamente assim que o usei. No arquivo /init.d/nginx, encontrei kill -HUP cat $PIDFILE|| echo -n "não é possível recarregar"
mashup

1
você sabe qual é a diferença entre service nginx reloade nginx -s reload? Se eu rodar o primeiro, recebo esta saída:, Reloading nginx configuration: nginx.mas minhas alterações não são atualizadas. Se eu executar o último, não recebo saída, mas minhas alterações são refletidas.
Ryan Quinn

Eu apenas tentei isso depois de adicionar uma log_not_founddiretiva, mas achei que realmente precisava reiniciar para que funcionasse. Eu acho que recarregar não funciona para todas as diretivas?
mydoghasworms

81

Corre /usr/sbin/nginx -s reload

Consulte http://wiki.nginx.org/CommandLine para obter mais opções de linha de comando.


Finalmente, um comando que funciona no Debian Jessie.
danger89

1
Esta é uma maneira melhor. Como o servidor não fica inativo se suas configurações apresentarem erros (apenas mostra erros neste caso).
21718 Mir-Ismaili

se o pid padrão do nginx não estiver no local padrão, será necessário '-p'. ou seja: `/ opt / gitlab / embedded / sbin / nginx -s reload -p / var / opt / gitlab / nginx`
qxo

9

Não, você está incorreto, não deveria estar enfrentando nenhum tempo de inatividade com o procedimento descrito. (O Nginx pode não apenas recarregar a configuração em tempo real sem tempo de inatividade, mas também a atualização do executável em tempo real, ainda sem tempo de inatividade.)

Conforme http://nginx.org/docs/control.html#reconfiguration , enviar o HUPsinal para o nginx garante que ele execute uma reinicialização normal e, se os arquivos de configuração estiverem incorretos, todo o procedimento será abandonado e você ' é deixado com o nginx como antes de enviar o HUPsinal. Em nenhum momento deve ser possível qualquer tempo de inatividade.

Para que o nginx leia novamente o arquivo de configuração, um sinal HUP deve ser enviado ao processo mestre. O processo mestre primeiro verifica a validade da sintaxe e tenta aplicar uma nova configuração, ou seja, para abrir arquivos de log e novos soquetes de escuta. Se isso falhar, ele reverte as alterações e continua a trabalhar com a configuração antiga.


2

Geralmente, recarregar o arquivo de configuração de um serviço não deve afetar o serviço em execução. No entanto, isso depende de como o SIGHUPsinal é processado.

Se um serviço específico estiver com um tempo de inatividade durante a recarga, isso poderá ser contornado executando o mesmo serviço em vários servidores, de preferência usando um balanceador de carga. Nesse caso, você pode remover um servidor de cada vez e recarregar / reiniciar. Em seguida, ele pode ser adicionado novamente após confirmar que está OK.


Embora isso não responda diretamente à pergunta, esse é definitivamente um cenário de práticas recomendadas que o OP deve seguir para evitar o tempo de inatividade em geral.
Andrew M.

1
Detalhes sobre como nginx lida com sinais diferentes: nginx.org/en/docs/control.html
Gnarfoz
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.