Nginx deixa o soquete antigo

Question

Estou executando o Nginx 1.6.2 (o pacote nginx-full do nginx/stable PPA). Estou usando a configuração não modificada /etc/nginx/nginx.conf :

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
    worker_connections 768;
}

http {
    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Se eu fizer a seguinte configuração do site e vinculá-la a sites-enabled :

# /etc/nginx/sites-available/serve-files
server {
    listen unix:/run/serve-files.socket;
    root /var/www/files;
    location / {
        try_files $uri =404;
    }
}

E reinicie o nginx (usando sudo service nginx restart ), o soquete /run/serve-files.socket é criado com as seguintes permissões:

srw-rw-rw- 1 root root 0 Oct 29 14:35 serve-files.socket

Se eu interromper o nginx (usando sudo service nginx stop ), o soquete permanecerá inesperadamente. E quando eu inicio o backup do nginx (usando sudo service nginx start ), recebo os seguintes erros relatados para /var/log/nginx/error.log :

2014/10/29 14:36:32 [emerg] 21680#0: bind() to unix:/run/serve-files.socket failed (98: Address already in use)
2014/10/29 14:36:32 [emerg] 21680#0: bind() to unix:/run/serve-files.socket failed (98: Address already in use)
2014/10/29 14:36:32 [emerg] 21680#0: bind() to unix:/run/serve-files.socket failed (98: Address already in use)
2014/10/29 14:36:32 [emerg] 21680#0: bind() to unix:/run/serve-files.socket failed (98: Address already in use)
2014/10/29 14:36:32 [emerg] 21680#0: bind() to unix:/run/serve-files.socket failed (98: Address already in use)
2014/10/29 14:36:32 [emerg] 21680#0: still could not bind()

Parece que o nginx não sobrescreve seu soquete que foi deixado de seu desligamento anterior. Por que é isso? Eu confiei algo errado? Existe uma maneira de contornar isso?

NOTA: Não existem outros sites rodando com o nginx, quando eu paro o nginx não há processos remanescentes, e eu reproduzi isso em um servidor e desktop Ubuntu ambos rodando o 14.04.1 LTS.

ATUALIZAÇÃO: Quando o nginx estiver em execução, netstat -lx | grep serve-files indicará que o soquete está sendo usado:

unix  2      [ ACC ]     STREAM     LISTENING     6543310  /run/serve-files.socket

Quando o nginx é interrompido, netstat -lx | grep serve-files indica que nenhum soquete está sendo usado (como esperado), mas o arquivo de soquete permanece em /run/serve-files.socket .

    

Answer 1

De acordo com a documentação do Nginx, o SIGQUIT executará um "desligamento normal", enquanto o SIGTERM executará um "desligamento rápido". Pelo menos a partir da versão 1.8.0, o Nginx deixará soquetes de domínio UNIX obsoletos quando for interrompido usando o sinal SIGQUIT . No entanto, os soquetes de domínio do UNIX são removidos corretamente quando se usa o sinal SIGTERM .

O script de serviço Nginx /etc/init.d/nginx fornecido pelo nginx/stable PPA envia SIGQUIT para o Nginx quando ele é interrompido com sudo service nginx stop ou restart . Para corrigir o script, modifique a linha:

STOP_SCHEDULE="${STOP_SCHEDULE:-QUIT/5/TERM/5/KILL/5}"

Para:

STOP_SCHEDULE="${STOP_SCHEDULE:-TERM/5/KILL/5}"

No entanto, o script de serviço Nginx do repo Ubuntu já usa SIGTERM em vez de SIGQUIT e não precisa ser modificado.

    

Answer 2

Eu não acho que isso tenha a ver com um desligamento rápido ou elegante, já que estou usando graciosa parada e também estou tendo esse problema.

No meu caso, notei o problema possivelmente relacionado / adicional que nginx continua tentando conectar a um soquete há muito extinto, mesmo depois que o soquete e todas as chamadas para ele terem sido excluídas (em menos até os arquivos que eu deliberadamente criei ou alterei).

Colocar o soquete em /tmp parece ser uma solução alternativa que evitará esse problema, mas ainda não consigo me livrar dos sockets fantasmas que foram criados anteriormente em outro lugar.

Então eu não entendo de onde o problema está vindo. Em que ponto nginx decidiu lembrar um soquete para sempre, e existe uma maneira de redefinir isso?

    

Answer 3

Como uma correção rápida no 16.04 Xenial, eu simplesmente consegui excluir o soquete incorreto:

sudo systemctl stop nginx
sudo rm /var/run/serve-files.socket
sudo systemctl start nginx