Lua-resty-auto-ssl: 잠금 문제

앗, 이로 인해 서비스가 중단되었다는 소식을 듣게 되어 유감입니다!

불행히도 상당한 양의 트래픽을 얻는 우리 설치에서 이와 같은 것을 본 적이 없습니다(당신이 언급한 지난 3월의 사건 이후). 그러나 #29에 보고된 이와 유사한 또 다른 유사한 문제가 있었습니다. 여기에서 우리는 관련되었을 수 있는 문제를 수정했지만 문제를 완전히 설명하지는 않았을 수 있습니다. 그러나 해당 문제는 관련이 없을 수도 있습니다(등록이 발생한 시점에만 해당됨).

이 문제를 디버깅하는 데 도움이 되는 제안에 감사드립니다. 몇 가지 초기 질문이 있습니다.

• 실행 중인 lua-resty-auto-ssl 버전은 무엇입니까?
• lua 모듈을 수동으로 설치하여 OpenResty 또는 nginx를 실행하고 있습니까?
• 어떤 버전의 OpenResty 또는 nginx+lua를 실행하고 있습니까?
• lua-resty-auto-ssl(Redis, 파일 시스템 등)과 함께 어떤 저장 메커니즘을 사용하고 있습니까?
• 얼마나 자주 물건이 걸려 있습니까? 새 인증서가 등록되거나 갱신이 진행 중일 때만 발생하는 것 같습니까? 아니면 무작위로 보이는 것입니까?
• nginx를 전혀 다시 로드하고 있습니까(마스터 프로세스를 완전히 다시 시작하는 대신 마스터 프로세스에 SIGHUP을 보내고 새 작업자를 생성)?
• 얼마나 많은 nginx 작업자를 실행하고 있습니까(nginx 구성에서 worker_processes 설정)?
• 다른 nginx 플러그인이 설치되어 있습니까(OpenResty를 사용하는 경우 기본적으로 OpenResty와 함께 제공되는 플러그인 외에)?

lua-resty-auto-ssl은 luarocks의 0.10.3-1입니다.
우리는 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

현재 파일 시스템은 각 서버가 처리하는 하위 도메인이 분리되어 있습니다.
충돌이 발생할 때 3시간에서 좋은 3일까지 완전히 무작위로 보입니다.
nginx atm을 다시 로드하지 않고 다시 시작하기만 하면 됩니다. 하지만 이것을 시도하고 이것이 작동하는지 확인하겠습니다.
처음에는 작업자 1명을 사용했지만 문제가 발생했을 때 이를 2개로 늘려 차이가 있는지 확인했습니다.
다음 비 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
• 테스트쿠키-nginx-module https://github.com/kyprizel/testcookie-nginx-module
  및 --with-http_v2_module --with-http_secure_link_module

아직 이 프로젝트 이외의 구성 코드에서 다른 Lua를 사용하고 있지 않습니다.

후속 조치가 늦어져서 죄송합니다! 몇 가지 더 검색한 후에 무슨 일이 일어날 수 있는지에 대한 몇 가지 이론이 있습니다.

• "exited on signal 9" 오류가 표시된다는 사실은 메모리 부족 오류가 발생하고 시스템이 적극적으로 프로세스를 종료하고 있음을 나타낼 수 있습니다 .
• 이와 같이 프로세스가 충돌하거나 강제로 종료되면 nginx가 공유 메모리가 죽은 작업자 프로세스에 의해 여전히 잠겨 있다고 생각하게 할 수 있습니다. 예를 들어, 초기 예제에서 작업자 프로세스 501이 먼저 종료된 것처럼 보이지만 여전히 메모리가 pid 501에 의해 잠겨 있다고 생각하여 이 교착 상태로 이어집니다.
  
  
  
  • nginx는 충돌 시 공유 메모리의 잠금을 해제해야 하는 것 같으 므로 왜 그런 일이 일어나지 않을 수 있는지 완전히 모르겠습니다. 그러나 작업자가 SIGKILL(9)로 종료되는 경우 모든 베팅이 해제될 수 있습니다(sigkill은 일반적으로 프로세스를 강제로 종료하고 정리할 기회가 없음을 의미하기 때문에).
  
  

시스템 수준 로그에 메모리 부족 또는 oom-killer에 대한 내용이 있습니까? nginx에서 메모리 증가 또는 메모리 누수를 나타낼 수 있는 이러한 서버에 대한 다른 모니터링이 있습니까? 나는 우리가 다른 Nginx에 모듈의 일부도 역할을 할 수 있다면 궁금하네요 그래서, 우리 루아 - resty - 자동 SSL 설치의 어떤 메모리 누수를 본 적이 생각하지 않는다 (이이 언급 의 lua-upstream-cache-nginx-module의 메모리 누수).

죄송합니다. @GUI 에서 신호 9에서 사망한 것이 버그와 연결되어 있지 싶었지만 문제에 대응하기 위해 의도적으로 nginx 프로세스를 종료했습니다. 이 서버의 메모리에는 문제가 없으며 약 2GB의 메모리가 있으며 실제로는 소량이 사용되고 나머지는 대부분 캐시됩니다. dmesg에서 OOM 킬이 없습니다.

더 이상 사용되지 않는 lua-upstream-cache-nginx-module 및 제거된 pagespeed 문제를 해결하기 위해 일부 모듈을 제거했지만 도움이 되지 않는 것으로 보입니다.

도움이 될 수 있는 오류 행이 몇 개 더 있습니다. 곧 서버에서 가져오도록 하겠습니다.

@ajmgh : 관련이 있는지 완전히 확신할 수는 없지만 구성된 lua_shared_dict 메모리 크기가 너무 작은 경우 이상한 오류로 이어질 수 있는 몇 가지 잠재적인 문제를 추적한 것 같습니다. https://github.com /GUI/lua-resty-auto-ssl/issues/48#issuecomment -294397379

따라서 시스템에 얼마나 많은 인증서가 있고 nginx 구성에 얼마나 큰 lua_shared_dict auto_ssl 가 구성되어 있는지 알고 있습니까? 0.10.3 이후로 이 문제를 해결할 수 있는 몇 가지 업데이트가 있으므로(운이 좋다면) 최소한 더 나은 오류 처리 및 메시지를 제공하므로 가능하면 v0.10.6으로 업그레이드를 시도할 수도 있습니다.

나는 똑같은 오류에 직면하고 있습니다.
lua-resty-auto-ssl을 버전 0.10.6-1로 업데이트하고 lua_shared_dict auto_ssl_settings 를 1000m로 늘립니다(64k로 설정되기 전).
lua_shared_dict auto_ssl 는 동일하게 유지: 1000m

이러한 변경으로 이 문제가 해결되는지 확인하기만 하면 됩니다./

@ajmgh 문제를 해결하셨나요?

@aiev auto_ssl_settings 현재 짧은 문자열과 하나의 부울만 저장하므로 변경해도 아무런 차이가 없습니다. 인증서는 auto_ssl 저장됩니다. 그러니 대신 늘려보세요.

아니요, 최신 업데이트로 문제가 해결되지 않습니다. auto_ssl 크기를 8M으로 올렸습니다. 이는 약 10개의 인증서만 사용하고 변경 사항이 없기 때문에 과도합니다.

# 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

나는 같은 문제를 몇 번 경험했습니다.
저는 luarocks의 OpenResty 1.11.2.3/4 및 lua-resty-auto-ssl 0.11.0-1을 사용하고 있습니다.
이 문제가 나타나면 100개 이상의 tcp 연결이 CLOSE_WAIT 상태에서 멈춥니다.

우리도 같은 문제를 여러 번 경험했습니다.
nginx 버전: openresty/1.11.2.4
lua-resty-auto-ssl 0.11.0-1
CLOSE_WAIT 상태가 많이 있으며 nginx는 더 이상 응답할 수 없습니다. 이 문제를 해결하려면 CLOSE_WAIT 연결을 종료하거나 도커를 다시 시작해야 합니다.

@ajmgh 문제를 해결하셨나요? 우리는 openresty 컨테이너에서 동일한 문제를 겪고 있습니다. CLOSE_WAIT 상태에서 ~1200개의 연결이 있고 lua-resty-auto-ssl로 openresty만 실행하는 서버의 /tmp에 많은 탈수된 파일이 있습니다.

다음은 시스템 구성입니다.

• 실행 중인 lua-resty-auto-ssl 버전은 무엇입니까?
  0.11.0-1
• lua 모듈을 수동으로 설치하여 OpenResty 또는 nginx를 실행하고 있습니까?
  개방성
• 어떤 버전의 OpenResty 또는 nginx+lua를 실행하고 있습니까?
  개방성 1.11.2.4
• lua-resty-auto-ssl(Redis, 파일 시스템 등)과 함께 어떤 저장 메커니즘을 사용하고 있습니까?
  레디스
• 얼마나 자주 물건이 걸려 있습니까? 새 인증서가 등록되거나 갱신이 진행 중일 때만 발생하는 것 같습니까? 아니면 무작위로 보이는 것입니까?
  그것은 매우 무작위로 보입니다. 어제 발생한 일이며 시스템에서 30분의 다운타임이 발생했습니다. 이전에 일어난 일은 2개월 전이었습니다.
• nginx를 전혀 다시 로드하고 있습니까(마스터 프로세스를 완전히 다시 시작하는 대신 마스터 프로세스에 SIGHUP을 보내고 새 작업자를 생성)?
  우리는 방금 모든 도커 컨테이너를 교체했습니다.
• 얼마나 많은 nginx 작업자를 실행하고 있습니까(nginx 구성의 worker_processes 설정)?
  2
• 다른 nginx 플러그인이 설치되어 있습니까(OpenResty를 사용하는 경우 기본적으로 OpenResty와 함께 제공되는 플러그인 외에)?
  아니요 lua-resty-auto-ssl은 우리가 설치한 유일한 플러그인입니다.

@ronail 아니요. 하지만

이 버그가 발생한 다른 모든 사람들이 Docker를 사용하고 있습니까? Lua/OpenResty와 Docker를 함께 사용하면 정말 이상한 일이 벌어질 수 있습니다.

나는 도커를 사용하지 않고 있으며 같은 문제에 직면하고 있습니다.

탈수된 상태에서 인증서 발급을 시도할 때 발생하는 문제인 것 같습니다.

나는 또한 젠킨스가 30분마다 OpenResty를 다시 시작하도록 강제해야 하는 비슷한 문제가 발생합니다(매시간 또는 지속적으로 충돌이 발생합니다...)

높은 메모리 제한이 설정되어 있지만 도움이된다면 LetsEncrypt에서 실패한 인증에 대해 상당한 비율 제한을 받고 있다는 것을 알았습니다.

어제 같은 문제가 발생하여 근본 원인이 무엇인지에 대한 포인터가 없는 보고서(#43, #136)를 찾았습니다. 테스트 시스템에서 문제를 재현할 수 없었으므로 프로덕션 시스템에서 강제로 디버그해야 했습니다. '다행히' 중단이 자주 발생하여 디버깅 방법을 빠르게 반복할 수 있었습니다. 첫째, 그것은 모든 nginx 프로세스에 대한 strace -fp $pid에 불과했으며, 이는 모든 프로세스가 futex()를 기다리고 있음을 보여주었습니다. 이는 pid 중 하나가 항상 shdict에 대한 잠금을 보유하고 있다는 사실과 일치합니다. 다음으로 각 프로세스의 gdb 역추적 덤프를 추가하고 이미지에 디버그 기호를 추가한 후 문제가 다음 코드 경로에 있음이 분명해졌습니다.

#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

ngx_http_lua_shdict_get_helper()를 간략히 살펴보면 문제의 근본 원인이 명확해집니다. shdict가 잠기고 lua_pushlstring이 때때로 가비지 수집기를 호출하여 동일한 shdict에서 항목을 제거하려고 할 수 있어 교착 상태를 유발할 수 있습니다.

내 빠르고 더러운 해결책은 이것이었습니다(너무 못생겨서 패치를 게시하지 않을 것입니다).

    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;

지금까지 이것은 완벽하게 실행됩니다. 시스템의 내부 작동에 대한 더 많은 통찰력을 가진 사람이 더 나은 수정을 생성하기를 원할 수 있습니다.

흥미롭게도 이것은 알려진 사실입니다!
https://github.com/openresty/lua-nginx-module/issues/1207#issuecomment -350745592

참으로 흥미롭습니다. 언급한 문제에 따라 lua-resty-core를 사용하면 문제가 해결되며 설명서에 따르면 openresty 1.15.8.1부터 자동으로 로드되므로 이 버그는 해당 버전에서 자동으로 수정되었습니다. 프록시를 업그레이드하고 다시 보고하겠습니다.

완벽하게 작동하는 것 같습니다. 중단을 유발한 상태가 여전히 지속된다고 가정하면 버그가 수정되었다고 말할 수 있습니다.

3년 이상 순조롭게 실행한 후에 방금 이 문제에 부딪쳤습니다.

또한 프로덕션에서 이 문제가 발생했습니다. @koszik 및 al에게 감사드립니다. 확인을 위해 이 문제를 해결하려면 다음 단계를 따르세요.

OpenResty를 >1.15.8.1

이것은 매우 위험한 것으로 보이며 f66bb61f11a654f66d35dd793ceaf0293d9c0f46을 곧 출시하거나 최소한 권장 사항이 아닌 요구 사항에 맞게 문서를 업데이트할 가치가 있습니다.