nginx 1.7.9: Sockets Web do Proxy Reverso: trava na reinicialização do serviço / parada de serviço, nunca sai

Question

Usamos nginx para balanceamento de carga em um par de servidores de websocket e atingimos um problema.

Ele não sairá ou encerrará normalmente quando tiver conectado o tráfego a um servidor de soquete da web. Por exemplo. service nginx stop, ou nginx -s quit ou nginx -s reload faz com que um ou mais processos de trabalho informem que "processo de trabalho está sendo encerrado" para sempre.

O fluxo é:

1. Inicie o nginx com a configuração abaixo.
2. Transmitir tráfego para o terminal nginx (mesmo usando o navegador da web para bater a porta 443 e obter erro 404 é o suficiente)
3. Use o controle de serviço ou envie o comando quit
4. o nginx está agora suspenso.

Nós rodamos nginx no centos v6

Detalhes das nossas opções de compilação e configuração de alto nível:

    [root@nginx1 nginx]# nginx -V
    nginx version: nginx/1.7.9
    built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
    TLS SNI support enabled
    configure arguments: --user=nginx --group=nginx --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --with-http_gzip_static_module 
--with-http_ssl_module --add-module=/opt/nginx_upstream_check_module-master/

Nossa configuração está abaixo. Como vamos perseguir isso? Neste momento somos forçados a fazer hard kill / restart do nginx para atualizar a configuração.

worker_processes  2;

error_log  logs/error.log;

events {
    worker_connections  20000;
}

worker_rlimit_nofile    40000;

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    upstream websocketserver {
        server 192.168.2.16:3842 max_fails=1 fail_timeout=60s;
        server 192.168.2.19:3842 max_fails=1 fail_timeout=60s;
    }

    server {
        listen 192.168.2.28:80;

    location / {

        proxy_pass http://websocketserver;

        proxy_next_upstream    error timeout invalid_header http_500;
        proxy_connect_timeout  2;
        proxy_read_timeout      86400;

        # WebSocket support (nginx 1.4)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        }

        location / {
            deny all;
            return 404;
        }       

    }
}

    

Answer 1

Possivelmente netstat e tcpdump são úteis para depuração, bem como lsof - o processo do operador ainda está conectado e está trocando dados? Percebo que seu proxy_read_timeout é um dia, e não o padrão de 60s, e imagino se isso é significativo. Soa como um erro nginx, e apenas possivelmente este post sobre compactação e keepalive do ZLIB está relacionado: link

    

Answer 2

O que eu faria é anexar ao processo nginx usando strace , depois tentar desligá-lo e verificar seu strace para ver em qual descritor de arquivo ele está pendurado. Com essas informações, use lsof para rastrear qual descritor de arquivo está aguardando e a partir daí. Meu palpite é que pode ser um dos seus servidores a montante causando isso.

    

Answer 3

Se for um servidor websocket como o protocolo websocket do navegador, ele precisa enviar o encerramento do websocket para os navegadores conectados e fechar o soquete. A aplicação em 192.168.2. *: 3842 seria capaz de fazer isso. Então, você precisaria enviar um sinal para esse aplicativo para dizer a ele para enviar o desligamento para seus websockets conectados.