Lua-resty-auto-ssl: Problema de travamento

Owch, lamento saber que isso levou a uma interrupção!

Infelizmente, não vi nada parecido em nossa instalação que tenha um tráfego decente (desde o incidente de março passado a que você se referiu). No entanto, havia outro problema um tanto semelhante como este relatado no nº 29, onde corrigimos um problema que pode estar relacionado, mas pode não ter explicado totalmente o problema. Mas esse problema também pode não estar relacionado (era específico para quando ocorreram os registros).

Obrigado pela oferta de ajudar a depurar isso, no entanto, seria definitivamente bom chegar ao fundo disso. Eu tenho algumas perguntas iniciais:

• Qual versão de lua-resty-auto-ssl você está executando?
• Você está executando o OpenResty ou nginx com o módulo lua instalado manualmente?
• Quais versões do OpenResty ou nginx + lua você está executando?
• Que mecanismo de armazenamento você está usando com lua-resty-auto-ssl (Redis, sistema de arquivos, outra coisa)?
• Com que frequência as coisas travam? Parece acontecer apenas quando novos certificados estão sendo registrados ou renovações estão ocorrendo, ou é aparentemente aleatório?
• Você está recarregando o nginx (enviando um SIGHUP para o processo mestre e gerando novos trabalhadores em vez de reiniciar totalmente o processo mestre)?
• Quantos workers nginx você está executando (configuração worker_processes na configuração do nginx)?
• Você tem algum outro plug-in nginx instalado (além dos que vêm com o OpenResty por padrão, se você estiver no OpenResty)?

lua-resty-auto-ssl é 0.10.3-1 de luarocks
Estamos usando o OpenResty 1.11.2.2.

nginx version: openresty/1.11.2.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.2h  3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/local/openresty/nginx --with-cc-opt=-O2 --add-module=../ngx_devel_kit-0.3.0 --add-module=../echo-nginx-module-0.60 --add-module=../xss-nginx-module-0.05 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.31 --add-module=../form-input-nginx-module-0.12 --add-module=../encrypted-session-nginx-module-0.06 --add-module=../srcache-nginx-module-0.31 --add-module=../ngx_lua-0.10.7 --add-module=../ngx_lua_upstream-0.06 --add-module=../headers-more-nginx-module-0.32 --add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.17 --add-module=../redis2-nginx-module-0.13 --add-module=../redis-nginx-module-0.3.7 --add-module=../rds-json-nginx-module-0.14 --add-module=../rds-csv-nginx-module-0.07 --with-ld-opt=-Wl,-rpath,/usr/local/openresty/luajit/lib --with-http_ssl_module --with-http_perl_module --with-http_v2_module --with-http_secure_link_module --add-module=/nginx-build/openresty-1.11.2.2/../testcookie-nginx-module --add-module=/nginx-build/openresty-1.11.2.2/../lua-upstream-cache-nginx-module --add-module=/nginx-build/openresty-1.11.2.2/../nginx-module-vts --with-openssl=/openssl

Sistema de arquivos por enquanto, já que os subdomínios com os quais cada servidor lida são separados.
Parece ser completamente aleatório quando ocorre um travamento, algo entre 3 horas e bons 3 dias.
Não recarregando o nginx atm, apenas reiniciando, mas vou tentar fazer isso e ver se funciona também.
Inicialmente eu estava usando 1 trabalhador, mas tentei aumentar para 2 quando os problemas ocorreram para ver se faria alguma diferença.
Usando os seguintes módulos não OpenResty:

• nginx-module-vts https://github.com/vozlt/nginx-module-vts
• lua-upstream-cache-nginx-module https://github.com/cloudflare/lua-upstream-cache-nginx-module
• testcookie-nginx-module https://github.com/kyprizel/testcookie-nginx-module
  e --with-http_v2_module --with-http_secure_link_module

Não estou usando nenhuma outra Lua no código de configuração além deste projeto.

Desculpe pelo atraso no seguimento! Depois de pesquisar mais um pouco, tenho algumas teorias sobre o que pode estar acontecendo:

• O fato de você estar vendo erros de "saída no sinal 9" pode indicar que você está obtendo erros de falta de memória e que o sistema está eliminando processos agressivamente: http://raspberrypi.stackexchange.com/questions/40883 / nginx-out-of-memory-kill-process
• Quando um processo falha ou é eliminado à força assim, pode fazer com que o nginx pense que a memória compartilhada ainda está bloqueada pelo processo de trabalho morto. Por exemplo, em seu exemplo inicial, parece que o processo de trabalho 501 é eliminado primeiro, mas ainda pensa que a memória está bloqueada por pid 501, levando a esse impasse.
  
  
  
  • Parece que o nginx deve desbloquear a memória compartilhada em travamentos, então não tenho certeza de por que isso pode não estar acontecendo. Mas se os trabalhadores estão sendo mortos com SIGKILL (9), então todas as apostas podem ser canceladas (já que sigkill normalmente significa matar o processo à força e não há chance de limpar).
  
  

Então, você vê algo em seus logs de nível de sistema sobre memória insuficiente ou oom-killer? Você tem algum outro monitoramento nesses servidores que possa indicar crescimento de memória ou vazamento de memória no nginx? Não acho que vimos vazamentos de memória em nenhuma de nossas instalações lua-resty-auto-ssl, então estou me perguntando se alguns dos outros módulos nginx também podem estar desempenhando uma função (há esta menção de um vazamento de memória em lua-upstream-cache-nginx-module).

Desculpe - eu queria esclarecer de volta para @GUI que o

Devo acrescentar que removi alguns módulos para tentar ajudar no problema, o obsoleto lua-upstream-cache-nginx-module e removi a velocidade de página, mas isso não parece ter ajudado.

Tenho mais algumas linhas de erro que podem ser úteis. Em breve tentarei obtê-las dos servidores.

@ajmgh : Não tenho certeza se está relacionado, mas acho que rastreei alguns problemas em potencial que poderiam levar a erros estranhos se o tamanho da memória lua_shared_dict configurado fosse muito baixo: https://github.com / GUI / lua-resty-auto-ssl / issues / 48 # issuecomment -294397379

Então, você sabe aproximadamente quantos certificados existem em seu sistema e quão grande lua_shared_dict auto_ssl está configurado em sua configuração nginx? Você também pode tentar atualizar para a v0.10.6, se possível, já que houve algumas atualizações desde a 0.10.3 que podem corrigir isso (se tivermos sorte), ou pelo menos fornecer um melhor tratamento de erros e mensagens.

Estou enfrentando exatamente o mesmo erro.
Acabei de atualizar lua-resty-auto-ssl para a versão 0.10.6-1 e aumentar lua_shared_dict auto_ssl_settings para 1000m (antes de ser definido para 64k).
lua_shared_dict auto_ssl mantém o mesmo: 1000m

Só estou esperando para ver se essas mudanças resolverão este problema: /

@ajmgh você resolveu seu problema?

@aiev auto_ssl_settings atualmente armazena apenas uma string curta, bem como um booleano, então alterá-la não fará nenhuma diferença. Os certificados são armazenados em auto_ssl . Portanto, em vez disso, tente aumentar isso.

Não, a atualização mais recente não corrige nosso problema. Aumentei o tamanho de auto_ssl para 8M, o que é um exagero, pois usamos apenas cerca de 10 certificados e não vimos nenhuma alteração.

# Log entries after my script detects nginx is unresponsive and force kills it
2017/05/24 13:29:15 [alert] 462#0: worker process 474 exited on signal 9
2017/05/24 13:29:15 [alert] 462#0: worker process 475 exited on signal 9
2017/05/24 13:29:15 [alert] 462#0: shared memory zone "auto_ssl" was locked by 475

Eu tive o mesmo problema algumas vezes.
Estou usando o OpenResty 1.11.2.3/4 e lua-resty-auto-ssl 0.11.0-1 do luarocks.
Quando esse problema aparece, mais de 100 conexões tcp estão travadas no estado CLOSE_WAIT.

Também enfrentamos o mesmo problema muitas vezes.
versão nginx: openresty / 1.11.2.4
lua-resty-auto-ssl 0.11.0-1
Existem muitos estados CLOSE_WAIT, e o nginx não pode mais responder. Precisamos encerrar a conexão CLOSE_WAIT ou reiniciar o docker para resolver esse problema.

@ajmgh você resolveu seu problema? Estamos enfrentando o mesmo problema em nossos contêineres abertos. Nós obtivemos aproximadamente 1200 conexão no estado CLOSE_WAIT e muitos arquivos desidratados em / tmp em nossos servidores que rodam apenas openresty com lua-resty-auto-ssl.

Aqui está a configuração do nosso sistema

• Qual versão de lua-resty-auto-ssl você está executando?
  0.11.0-1
• Você está executando o OpenResty ou nginx com o módulo lua instalado manualmente?
  aberto
• Quais versões do OpenResty ou nginx + lua você está executando?
  openresty 1.11.2.4
• Que mecanismo de armazenamento você está usando com lua-resty-auto-ssl (Redis, sistema de arquivos, outra coisa)?
  redis
• Com que frequência as coisas travam? Parece acontecer apenas quando novos certificados estão sendo registrados ou renovações estão ocorrendo, ou é aparentemente aleatório?
  Parece muito aleatório. Aconteceu ontem e levou a um tempo de inatividade de 30 minutos em nosso sistema. A última vez que isso aconteceu foi há 2 meses.
• Você está recarregando o nginx (enviando um SIGHUP para o processo mestre e gerando novos trabalhadores em vez de reiniciar totalmente o processo mestre)?
  acabamos de substituir todos os contêineres docker
• Quantos workers nginx você tem em execução (configuração worker_processes na configuração nginx)?
  2
• Você tem algum outro plug-in nginx instalado (além dos que vêm com o OpenResty por padrão, se você estiver no OpenResty)?
  não lua-resty-auto-ssl é o único plugin que temos instalado

@ronail Não, no entanto, adicionamos servidores extras em nosso roundrobin, bem como temos um script de reinicialização automatizada quando esse problema acontece, portanto, o atenuamos fortemente.

Todos os outros usuários do Docker apresentam esse bug? Talvez seja algo muito estranho acontecendo com uma mistura de Lua / OpenResty e Docker.

Não estou usando o docker e estou enfrentando o mesmo problema.

Eu acho que este é um problema quando desidratado tenta emitir o certificado.

Também estou tendo um problema semelhante, tendo que forçar Jenkins a reiniciar o OpenResty a cada 30 minutos (trava a cada hora ou assim constantemente ...)

Tenho altos limites de memória definidos, no entanto, percebi que estou obtendo alguns limites de proporção para autenticações com falha no LetsEncrypt, se isso ajuda?

Fomos atingidos com o mesmo problema ontem e encontramos esses relatórios (# 43, # 136) que não continham indicações sobre o que poderia ser a causa raiz. Não foi possível reproduzir o problema em nosso sistema de teste, então fomos forçados a depurar no de produção. 'Felizmente', as travas eram frequentes o suficiente, então pudemos iterar rapidamente por meio de nossos métodos de depuração. Primeiro, era apenas um strace -fp $ pid em todos os processos nginx, e isso revelou que todos eles estavam esperando por um futex () - consistente com o fato de que um dos pids sempre manteve um bloqueio em um shdict. Em seguida, adicionei um dump do backtrace do gdb de cada processo e, depois de adicionar símbolos de depuração à imagem, ficou claro que o problema está no seguinte caminho de código:

#3  0x00007f8f4ea50219 in ngx_shmtx_lock (mtx=0x7f8f31a0c068) at src/core/ngx_shmtx.c:111
#4  0x00007f8f4eb7afbe in ngx_http_lua_shdict_set_helper (L=0x418257a0, flags=0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:1016
#5  0x00007f8f4eb7a4a4 in ngx_http_lua_shdict_delete (L=0x418257a0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:632
#6  0x00007f8f4debd2f3 in lj_BC_FUNCC () from /usr/local/openresty/luajit/lib/libluajit-5.1.so.2
#7  0x00007f8f4dec0b9f in gc_call_finalizer (g=0x418063b8, L=0x418257a0, mo=0x7ffc7592da00, o=0x40e11948) at lj_gc.c:475
#8  0x00007f8f4dec0e2b in gc_finalize (L=0x418257a0) at lj_gc.c:509
#9  0x00007f8f4dec15d9 in gc_onestep (L=0x418257a0) at lj_gc.c:659
#10 0x00007f8f4dec16ef in lj_gc_step (L=0x418257a0) at lj_gc.c:689
#11 0x00007f8f4ded8c3d in lua_pushlstring (L=0x418257a0, str=0x7f8f330a6066 "0\202\002\v\n\001", len=527) at lj_api.c:639
#12 0x00007f8f4eb7a225 in ngx_http_lua_shdict_get_helper (L=0x418257a0, get_stale=0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:538
#13 0x00007f8f4eb79eb6 in ngx_http_lua_shdict_get (L=0x418257a0) at ../ngx_lua-0.10.13/src/ngx_http_lua_shdict.c:419

Após uma rápida olhada em ngx_http_lua_shdict_get_helper (), a causa raiz do problema fica clara: o shdict é bloqueado e lua_pushlstring às vezes chama o coletor de lixo, que pode querer remover itens do mesmo shdict, causando o impasse.

Minha solução rápida e suja foi esta (é tão feia que não vou publicar um patch);

    case SHDICT_TSTRING:
{
int len = value.len;
char *tmp = malloc(len);
if(!tmp) {
    ngx_log_error(NGX_LOG_ERR, ctx->log, 0, "dict get: malloc: out of memory");
    return luaL_error(L, "out of memory");
}
ngx_memcpy(tmp, value.data, value.len);
ngx_shmtx_unlock(&ctx->shpool->mutex);
lua_pushlstring(L, tmp, len);
free(tmp);
}
        break;

Até agora, isso funcionou perfeitamente - alguém com mais conhecimento sobre o funcionamento interno do sistema pode querer produzir uma correção melhor.

Curiosamente, é um fato conhecido!
https://github.com/openresty/lua-nginx-module/issues/1207#issuecomment -350745592

isso é realmente interessante. de acordo com o problema que você mencionou, usar lua-resty-core resolveria o problema e, de acordo com sua documentação, ele é carregado automaticamente desde o openresty 1.15.8.1, então esse bug foi corrigido silenciosamente nessa versão. vamos atualizar nosso proxy e relatar de volta.

parece que está funcionando perfeitamente - supondo que a condição que o fez travar antes ainda persista, eu diria que o bug foi corrigido.

Acabei de se deparar com isso, após mais de 3 anos funcionando sem problemas.

Também encontrei esse problema na produção - obrigado @koszik e al. Apenas para confirmar, para resolver este problema:

Atualize o OpenResty para >1.15.8.1

Isso parece tão pernicioso que pode valer a pena lançar f66bb61f11a654f66d35dd793ceaf0293d9c0f46 em breve, ou pelo menos atualizar a documentação de acordo com o requisito, em vez de uma recomendação.