Lua-resty-auto-ssl: Problema de bloqueo

¡Ay, lamento oír que esto provocó un apagón!

Lamentablemente, no he visto nada como esto en nuestra instalación que reciba una cantidad decente de tráfico (desde el incidente de marzo pasado al que se refirió). Sin embargo, hubo otro problema algo similar como este informado en el n. ° 29, donde solucionamos un problema que podría haber estado relacionado, pero es posible que no haya explicado totalmente el problema. Pero ese problema también puede no estar relacionado (era específico de cuándo ocurrieron los registros).

Sin embargo, gracias por la oferta para ayudar a depurar esto, definitivamente sería bueno llegar al fondo de. Tengo algunas preguntas iniciales:

• ¿Qué versión de lua-resty-auto-ssl está ejecutando?
• ¿Está ejecutando OpenResty o nginx con el módulo lua instalado manualmente?
• ¿Qué versiones de OpenResty o nginx + lua está ejecutando?
• ¿Qué mecanismo de almacenamiento está utilizando con lua-resty-auto-ssl (Redis, sistema de archivos, algo más)?
• ¿Con qué frecuencia cuelgan las cosas? ¿Parece que solo sucede cuando se registran nuevos certificados o se realizan renovaciones, o es aparentemente aleatorio?
• ¿Está recargando nginx (enviando un SIGHUP al proceso maestro y generando nuevos trabajadores en lugar de reiniciar completamente el proceso maestro)?
• ¿Cuántos trabajadores de nginx tiene en ejecución (configuración worker_processes en la configuración de nginx)?
• ¿Tiene instalados otros complementos de nginx (además de los que vienen con OpenResty de forma predeterminada si está en OpenResty)?

lua-resty-auto-ssl es 0.10.3-1 de luarocks
Estamos usando 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 archivos por ahora, ya que los subdominios con los que se ocupa cada servidor están separados.
Parece ser completamente aleatorio cuando ocurre un accidente, desde 3 horas hasta unos buenos 3 días.
No recargar el cajero automático nginx, solo reiniciar, pero intentaré esto y veré si esto también funciona.
Inicialmente estaba usando 1 trabajador, pero intenté aumentar esto a 2 cuando ocurrieron los problemas para ver si había alguna diferencia.
Usando los siguientes módulos que no son de 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
  y --with-http_v2_module --with-http_secure_link_module

No estoy usando ningún otro Lua en el código de configuración que no sea este proyecto.

¡Perdón por la demora en el seguimiento! Después de buscar un poco más, tengo algunas teorías sobre lo que podría estar sucediendo:

• El hecho de que esté viendo errores de "salida en la señal 9" puede indicar que está teniendo errores de memoria insuficiente y que el sistema está matando procesos de manera agresiva: http://raspberrypi.stackexchange.com/questions/40883 / nginx-out-of-memory-kill-process
• Cuando un proceso falla o se mata a la fuerza de esta manera, entonces nginx puede pensar que la memoria compartida todavía está bloqueada por el proceso de trabajo muerto. Por ejemplo, en su ejemplo inicial, parece que el proceso de trabajo 501 se mata primero, pero luego todavía piensa que la memoria está bloqueada por el pid 501, lo que lleva a este punto muerto.
  
  
  
  • No parece como nginx se supone que la memoria compartida de desbloqueo en accidentes, por lo que no estoy del todo seguro de por qué no puede estar sucediendo. Pero si los trabajadores están siendo eliminados con SIGKILL (9), entonces todas las apuestas podrían estar canceladas (ya que sigkill generalmente significa matar a la fuerza el proceso y no hay posibilidad de limpiar).
  
  

Entonces, ¿ve algo en los registros de nivel de sistema sobre memoria insuficiente o oom-killer? ¿Tiene alguna otra supervisión en estos servidores que pueda indicar un crecimiento de la memoria o una pérdida de memoria en nginx? No creo que hayamos visto ninguna fuga de memoria en ninguna de nuestras instalaciones lua-resty-auto-ssl, así que me pregunto si algunos de los otros módulos nginx también podrían estar desempeñando un papel (hay una mención de un pérdida de memoria en lua-upstream-cache-nginx-module).

Lo siento, quería aclararle a @GUI que la muerte en la señal 9 no está conectada al error, pero nosotros matamos deliberadamente el proceso nginx para contrarrestar el problema. No hay ningún problema con la memoria en estos servidores, tienen alrededor de 2 GB de memoria, con una pequeña cantidad que se usa en realidad y el resto principalmente en caché. No OOM mata en dmesg.

Debo agregar que eliminé algunos módulos para tratar de ayudar con el problema, el módulo lua-upstream-cache-nginx-module obsoleto y eliminé pagespeed, pero esto no parece haber ayudado.

Tengo algunas líneas de error más que pueden ser útiles, intentaré obtenerlas de los servidores en breve.

@ajmgh : No estoy del todo seguro si está relacionado, pero creo que rastreé algunos problemas potenciales que podrían conducir a errores extraños si el tamaño de memoria lua_shared_dict configurado era demasiado bajo: https://github.com / GUI / lua-resty-auto-ssl / issues / 48 # issuecomment -294397379

Entonces, ¿sabe aproximadamente cuántos certificados hay en su sistema y qué tan grande lua_shared_dict auto_ssl está configurado para ser en su configuración de nginx? También puede intentar actualizar a v0.10.6, si es posible, ya que ha habido algunas actualizaciones desde 0.10.3 que podrían solucionar esto (si tenemos suerte), o al menos proporcionar un mejor manejo de errores y mensajes.

Estoy enfrentando exactamente el mismo error.
Acabo de actualizar lua-resty-auto-ssl a la versión 0.10.6-1 y aumento lua_shared_dict auto_ssl_settings a 1000m (antes de que se estableciera en 64k).
lua_shared_dict auto_ssl mantiene igual: 1000m

Solo espero a ver si estos cambios solucionarán este problema: /

@ajmgh , ¿resolvió su problema?

@aiev auto_ssl_settings actualmente solo almacena una cadena corta y un booleano, por lo que cambiarlo no hará ninguna diferencia. Los certificados se almacenan en auto_ssl . Así que intente aumentarlo en su lugar.

No, la última actualización no soluciona nuestro problema. Aumenté el tamaño de auto_ssl a 8M, lo cual es excesivo ya que usamos solo alrededor de 10 certificados y no vimos ningún cambio.

# 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

He experimentado el mismo problema varias veces.
Estoy usando OpenResty 1.11.2.3/4 y lua-resty-auto-ssl 0.11.0-1 de luarocks.
Cuando aparece este problema, más de 100 conexiones tcp están bloqueadas en el estado CLOSE_WAIT.

También hemos experimentado el mismo problema muchas veces.
versión de nginx: openresty / 1.11.2.4
lua-resty-auto-ssl 0.11.0-1
Hay muchos estados CLOSE_WAIT y nginx ya no puede responder. O debemos eliminar la conexión CLOSE_WAIT o reiniciar la ventana acoplable para resolver este problema.

@ajmgh, ¿ ha resuelto su problema? Estamos experimentando el mismo problema en nuestros contenedores abiertos. Tenemos una conexión de ~ 1200 en el estado CLOSE_WAIT y muchos archivos deshidratados en / tmp en nuestros servidores que solo ejecutan openresty con lua-resty-auto-ssl.

Aquí está la configuración de nuestro sistema

• ¿Qué versión de lua-resty-auto-ssl está ejecutando?
  0.11.0-1
• ¿Está ejecutando OpenResty o nginx con el módulo lua instalado manualmente?
  abierto
• ¿Qué versiones de OpenResty o nginx + lua está ejecutando?
  openresty 1.11.2.4
• ¿Qué mecanismo de almacenamiento está utilizando con lua-resty-auto-ssl (Redis, sistema de archivos, algo más)?
  redis
• ¿Con qué frecuencia cuelgan las cosas? ¿Parece que solo sucede cuando se registran nuevos certificados o se realizan renovaciones, o es aparentemente aleatorio?
  Parece muy aleatorio. Sucedió ayer y provocó un tiempo de inactividad de 30 minutos en nuestro sistema. La última vez que sucedió fue hace 2 meses.
• ¿Está recargando nginx (enviando un SIGHUP al proceso maestro y generando nuevos trabajadores en lugar de reiniciar completamente el proceso maestro)?
  acabamos de reemplazar todos los contenedores Docker
• ¿Cuántos trabajadores de nginx tiene en ejecución (configuración de worker_processes en la configuración de nginx)?
  2
• ¿Tiene instalados otros complementos de nginx (además de los que vienen con OpenResty de forma predeterminada si está en OpenResty)?
  no, lua-resty-auto-ssl es el único complemento que tenemos instalado

@ronail No, sin embargo, agregamos servidores adicionales en nuestro roundrobin y también tenemos un script de reinicio automático cuando ocurre este problema, por lo que lo hemos mitigado en gran medida.

¿Están todos los demás usuarios de Docker que experimentan este error? Tal vez sea algo realmente extraño con una mezcla de Lua / OpenResty y Docker.

No estoy usando Docker y estoy enfrentando el mismo problema.

Supongo que esto es un problema cuando deshidratado intenta emitir el certificado.

También tengo un problema similar, tener que obligar a jenkins a reiniciar OpenResty cada 30 minutos (se bloquea cada hora aproximadamente constantemente ...)

Tengo establecidos límites de memoria altos, sin embargo, he notado que obtengo algunos límites de velocidad para las autorizaciones fallidas en LetsEncrypt, si eso ayuda.

Ayer nos toparon con el mismo problema y encontramos estos informes (# 43, # 136) que no contenían indicaciones sobre cuál podría ser la causa raíz. No pudimos reproducir el problema en nuestro sistema de prueba, por lo que nos vimos obligados a depurar en el de producción. "Afortunadamente", los bloqueos eran lo suficientemente frecuentes, por lo que pudimos iterar rápidamente a través de nuestros métodos de depuración. Primero, era solo un strace -fp $ pid en todos los procesos de nginx, y esto reveló que todos estaban esperando en un futex (), de acuerdo con el hecho de que uno de los pids siempre mantenía un bloqueo en un shdict. A continuación, agregué un volcado del backtrace gdb de cada proceso, y después de agregar símbolos de depuración a la imagen, quedó claro que el problema está en la siguiente ruta 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

Después de un vistazo rápido a ngx_http_lua_shdict_get_helper (), la causa raíz del problema se vuelve clara: el shdict se bloquea y lua_pushlstring a veces llama al recolector de basura, que puede querer eliminar elementos del mismo shdict, provocando el interbloqueo.

Mi solución rápida y sucia fue esta (es tan feo que no voy a publicar un parche);

    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;

Hasta ahora, esto funciona a la perfección: alguien con más conocimiento del funcionamiento interno del sistema podría querer producir una mejor solución.

Curiosamente, ¡es un hecho conocido!
https://github.com/openresty/lua-nginx-module/issues/1207#issuecomment -350745592

eso es realmente interesante. según el problema que mencionaste, el uso de lua-resty-core solucionaría el problema y, de acuerdo con su documentación, se carga automáticamente desde openresty 1.15.8.1, por lo que este error se corrigió silenciosamente en esa versión. actualizaremos nuestro proxy y le informaremos.

parece que está funcionando perfectamente, asumiendo que la condición que causó que se bloqueara antes aún persista, yo diría que el error se ha solucionado.

Me encontré con esto, después de más de 3 años funcionando sin problemas.

También encontré este problema en producción, gracias @koszik y al. Solo para confirmar, para resolver este problema:

Actualizar OpenResty a >1.15.8.1

Esto parece tan pernicioso que podría valer la pena publicar f66bb61f11a654f66d35dd793ceaf0293d9c0f46 pronto, o al menos actualizar la documentación a un requisito, en lugar de una recomendación.