Lua-resty-auto-ssl: Sperrproblem

Autsch, es tut mir leid zu hören, dass dies zu einem Ausfall geführt hat!

Leider habe ich so etwas in unserer Installation, die einen ordentlichen Verkehr hat, nicht gesehen (seit dem Vorfall vom letzten März, auf den Sie sich bezogen haben). Es gab jedoch ein anderes, etwas ähnliches Problem wie dieses in #29, bei dem wir ein Problem behoben haben, das möglicherweise damit verbunden war, das Problem jedoch möglicherweise nicht vollständig erklärt hat. Aber dieses Problem kann auch nicht zusammenhängen (es war spezifisch für den Zeitpunkt, an dem die Registrierungen erfolgten).

Danke für das Angebot, bei der Fehlerbehebung zu helfen, aber es wäre definitiv gut, dem auf den Grund zu gehen. Ich habe ein paar erste Fragen:

• Welche Version von lua-resty-auto-ssl verwendest du?
• Führen Sie OpenResty oder nginx mit manuell installiertem lua-Modul aus?
• Welche Versionen von OpenResty oder nginx+lua verwenden Sie?
• Welchen Speichermechanismus verwenden Sie mit lua-resty-auto-ssl (Redis, Dateisystem, etwas anderes)?
• Wie oft hängen Dinge? Scheint es nur zu passieren, wenn neue Zertifikate registriert werden oder Verlängerungen stattfinden, oder scheint es zufällig zu sein?
• Laden Sie nginx überhaupt neu (senden Sie ein SIGHUP an den Master-Prozess und erzeugen Sie neue Arbeiter, anstatt den Master-Prozess vollständig neu zu starten)?
• Wie viele nginx-Worker laufen worker_processes Ihnen (Einstellung
• Haben Sie andere nginx-Plugins installiert (außer denen, die standardmäßig mit OpenResty geliefert werden, wenn Sie OpenResty verwenden)?

lua-resty-auto-ssl ist 0.10.3-1 von luarocks
Wir verwenden 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

Dateisystem vorerst, da die Subdomains, mit denen sich jeder Server befasst, getrennt sind.
Scheint völlig zufällig zu sein, wenn ein Absturz auftritt, alles von 3 Stunden bis zu guten 3 Tagen.
nginx atm nicht neu laden, nur einen Neustart durchführen, aber ich werde dies versuchen und sehen, ob dies auch funktioniert.
Anfangs habe ich 1 Worker verwendet, aber ich habe versucht, dies auf 2 zu erhöhen, als die Probleme auftraten, um zu sehen, ob es einen Unterschied machen würde.
Verwenden der folgenden Nicht-OpenResty-Module:

• 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
  und --with-http_v2_module --with-http_secure_link_module

Ich verwende noch kein anderes Lua im Konfigurationscode außer diesem Projekt.

Sorry für die verspätete Nachverfolgung! Nachdem ich mich noch etwas umgesehen habe, habe ich einige Theorien darüber, was passieren könnte:

• Die Tatsache, dass Sie "Exited on Signal 9"-Fehler sehen, kann darauf hindeuten, dass Sie auf Fehler wegen unzureichenden Speichers stoßen und das System aggressiv Prozesse abbricht :
• Wenn ein Prozess auf diese Weise abstürzt oder gewaltsam beendet wird, kann dies dazu führen, dass nginx denkt, dass der gemeinsame Speicher immer noch vom toten Worker-Prozess gesperrt ist. In Ihrem ersten Beispiel sieht es beispielsweise so aus, als ob der Worker-Prozess 501 zuerst beendet wird, aber dann denkt er immer noch, dass der Speicher von pid 501 gesperrt ist, was zu diesem Deadlock führt.
  
  
  
  • Es scheint, als ob nginx den gemeinsamen Speicher bei Abstürzen entsperren soll, daher bin ich mir nicht ganz sicher, warum dies nicht der Fall ist. Aber wenn Arbeiter mit SIGKILL (9) getötet werden, dann könnten alle Wetten falsch sein (da Sigkill normalerweise bedeutet, den Prozess gewaltsam zu beenden und es keine Chance gibt, aufzuräumen).
  
  

Sehen Sie also in Ihren Protokollen auf Systemebene irgendetwas über Speichermangel oder Oom-Killer? Haben Sie eine andere Überwachung auf diesen Servern, die auf Speicherwachstum oder ein Speicherleck in nginx hinweisen könnte? Ich glaube nicht , dass wir keine Speicherlecks in einem unserer lua-resty-Auto-ssl Installationen gesehen habe, so frage ich mich , ob einige der anderen nginx Module auch eine Rolle spielen könnte (es ist diese Erwähnung eines Speicherleck im lua-upstream-cache-nginx-modul).

Entschuldigung - ich wollte @GUI klarstellen, dass das Getötete bei Signal 9 nicht mit dem Fehler zusammenhängt, aber wir haben den nginx-Prozess absichtlich beendet, um dem Problem entgegenzuwirken. Es gibt kein Problem mit dem Arbeitsspeicher auf diesen Servern, sie haben etwa 2 GB Arbeitsspeicher, wobei eine winzige Menge tatsächlich verwendet wird und der Rest hauptsächlich zwischenspeichert. Keine OOM-Kills auf dmesg.

Ich sollte hinzufügen, dass ich einige Module entfernt habe, um das Problem zu lösen, das veraltete lua-upstream-cache-nginx-Modul und das Pagespeed entfernt habe, aber das scheint nicht geholfen zu haben.

Ich habe noch ein paar Fehlerzeilen, die hilfreich sein könnten, ich werde versuchen, sie in Kürze von den Servern zu bekommen.

@ajmgh : Ich bin mir nicht ganz sicher, ob es damit zusammenhängt, aber ich denke, ich habe einige potenzielle Probleme aufgespürt, die zu seltsamen Fehlern führen könnten, wenn die konfigurierte Speichergröße von lua_shared_dict zu niedrig war: https://github.com /GUI/lua-resty-auto-ssl/issues/48#issuecomment -294397379

Wissen Sie also ungefähr, wie viele Zertifikate sich in Ihrem System befinden und wie groß lua_shared_dict auto_ssl in Ihrer nginx-Konfiguration konfiguriert ist? Sie können auch versuchen, auf v0.10.6 zu aktualisieren, wenn möglich, da es seit 0.10.3 einige Updates gegeben hat, die dies beheben könnten (wenn wir Glück haben) oder zumindest eine bessere Fehlerbehandlung und Meldungen bieten.

Ich stehe vor genau dem gleichen Fehler.
Ich aktualisiere gerade lua-resty-auto-ssl auf Version 0.10.6-1 und erhöhe lua_shared_dict auto_ssl_settings auf 1000m (bevor es auf 64k gesetzt wurde).
lua_shared_dict auto_ssl bleibt gleich: 1000m

Ich warte nur darauf, ob diese Änderungen dieses Problem beheben :/

@ajmgh hast du dein Problem gelöst?

@aiev auto_ssl_settings speichert derzeit nur einen kurzen String sowie einen booleschen auto_ssl gespeichert. Versuchen Sie also stattdessen, diesen Wert zu erhöhen.

Nein, das neueste Update behebt unser Problem nicht. Ich habe die auto_ssl-Größe auf 8M erhöht, was übertrieben ist, da wir nur etwa 10 Zertifikate verwenden und keine Änderung festgestellt haben.

# 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

Ich habe das gleiche Problem ein paar Mal erlebt.
Ich verwende OpenResty 1.11.2.3/4 und lua-resty-auto-ssl 0.11.0-1 von luarocks.
Wenn dieses Problem auftritt, bleiben mehr als 100 TCP-Verbindungen im Status CLOSE_WAIT hängen.

Wir haben das gleiche Problem auch schon oft erlebt.
nginx-Version: openresty/1.11.2.4
lua-resty-auto-ssl 0.11.0-1
Es gibt viele CLOSE_WAIT-Status und nginx kann nicht mehr antworten. Entweder müssen wir die CLOSE_WAIT-Verbindung beenden oder den Docker neu starten, um dieses Problem zu beheben.

@ajmgh hast du dein Problem gelöst? Wir haben das gleiche Problem in unseren Openresty-Containern. Wir haben ~1200 Verbindung im Zustand CLOSE_WAIT und viele dehydrierte Dateien in /tmp auf unseren Servern, die nur Openresty mit lua-resty-auto-ssl ausführen.

Hier ist unsere Systemkonfiguration

• Welche Version von lua-resty-auto-ssl verwendest du?
  0.11.0-1
• Führen Sie OpenResty oder nginx mit manuell installiertem lua-Modul aus?
  Openresty
• Welche Versionen von OpenResty oder nginx+lua verwenden Sie?
  openresty 1.11.2.4
• Welchen Speichermechanismus verwenden Sie mit lua-resty-auto-ssl (Redis, Dateisystem, etwas anderes)?
  redis
• Wie oft hängen Dinge? Scheint es nur zu passieren, wenn neue Zertifikate registriert werden oder Verlängerungen stattfinden, oder scheint es zufällig zu sein?
  Es sieht sehr zufällig aus. Es ist erst gestern passiert und hat zu einer 30-minütigen Ausfallzeit in unserem System geführt. Das letzte Mal war es vor 2 Monaten.
• Laden Sie nginx überhaupt neu (senden Sie ein SIGHUP an den Master-Prozess und erzeugen Sie neue Arbeiter, anstatt den Master-Prozess vollständig neu zu starten)?
  wir haben gerade alle Docker-Container ersetzt
• Wie viele nginx-Worker laufen (worker_processes-Einstellung in der nginx-Konfiguration)?
  2
• Haben Sie andere nginx-Plugins installiert (außer denen, die standardmäßig mit OpenResty geliefert werden, wenn Sie OpenResty verwenden)?
  nein lua-resty-auto-ssl ist das einzige Plugin, das wir installiert haben

@ronail Nein, aber wir haben unserem Roundrobin zusätzliche Server hinzugefügt und haben ein automatisches Neustart-Skript, wenn dieses Problem auftritt, also haben wir es stark gemildert.

Verwenden alle anderen Docker, bei denen dieser Fehler auftritt? Vielleicht ist es etwas wirklich Seltsames mit einer Mischung aus Lua/OpenResty und Docker.

Ich benutze Docker nicht und habe das gleiche Problem.

Ich vermute, dass dies ein Problem ist, wenn dehydriert versucht, das Zertifikat auszustellen.

Ich habe auch ein ähnliches Problem, das Jenkins zwingen muss, OpenResty alle 30 Minuten neu zu starten (Stürzt jede Stunde oder so ständig ab ...)

Ich habe hohe Speicherlimits eingestellt, habe jedoch festgestellt, dass ich bei LetsEncrypt einige Ratenlimits für fehlgeschlagene Authentifizierungen erhalte, wenn das hilft?

Wir wurden gestern mit dem gleichen Problem konfrontiert und haben diese Berichte (#43, #136) gefunden, die keine Hinweise auf die Ursache enthielten. Wir konnten das Problem auf unserem Testsystem nicht reproduzieren, sodass wir gezwungen waren, auf dem Produktionssystem zu debuggen. "Glücklicherweise" waren die Hänger häufig genug, sodass wir unsere Debugging-Methoden schnell durchlaufen konnten. Erstens war es nur ein strace -fp $pid auf allen nginx-Prozessen, und dies zeigte, dass alle auf ein futex() warteten - im Einklang mit der Tatsache, dass einer der pids immer ein Shdict festhielt. Als nächstes fügte ich einen Dump des gdb-Backtraces jedes Prozesses hinzu, und nachdem ich dem Bild Debug-Symbole hinzugefügt hatte, wurde klar, dass das Problem im folgenden Codepfad liegt:

#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

Nach einem kurzen Blick auf ngx_http_lua_shdict_get_helper() wird die Ursache des Problems klar: Der Shdict wird gesperrt, und lua_pushlstring ruft manchmal den Garbage Collector auf, der möglicherweise Elemente aus demselben Shdict entfernen möchte, was den Deadlock verursacht.

Meine schnelle und schmutzige Lösung war folgende (es ist so hässlich, dass ich keinen Patch veröffentlichen werde);

    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;

Bisher läuft dies einwandfrei - jemand mit mehr Einblick in das Innenleben des Systems möchte vielleicht eine bessere Lösung erstellen.

Interessanterweise ist es eine bekannte Tatsache!
https://github.com/openresty/lua-nginx-module/issues/1207#issuecomment -350745592

das ist in der Tat interessant. Gemäß dem von Ihnen erwähnten Problem würde die Verwendung von lua-resty-core das Problem beheben, und laut seiner Dokumentation wird es seit Openresty 1.15.8.1 automatisch geladen, sodass dieser Fehler in dieser Version stillschweigend behoben wurde. Wir werden unseren Proxy aktualisieren und berichten.

Es sieht so aus, als ob es perfekt funktioniert - vorausgesetzt, die Bedingung, die dazu führte, dass es vorher hängen blieb, besteht weiterhin, würde ich sagen, dass der Fehler behoben wurde.

Ich bin gerade darauf gestoßen, nach mehr als 3 Jahren reibungslosen Ablaufs.

Ist auch in der Produktion auf dieses Problem @koszik und al. Nur zur Bestätigung, um dieses Problem zu beheben:

Aktualisiere OpenResty auf >1.15.8.1

Dies scheint so schädlich zu sein, dass es sich lohnen könnte, f66bb61f11a654f66d35dd793ceaf0293d9c0f46 bald zu veröffentlichen oder zumindest die Dokumentation entsprechend den Anforderungen zu aktualisieren, anstatt eine Empfehlung zu geben.