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です
OpenResty1.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
• testcookie-nginx-module https://github.com/kyprizel/testcookie-nginx-module
  および--with-http_v2_module--with-http_secure_link_module

構成コードでは、このプロジェクト以外のLuaをまだ使用していません。

フォローアップが遅れてすみません！ さらにいくつか調べた後、何が起こっているのかについていくつかの理論があります。

• 「シグナル9で終了」エラーが表示されているという事実は、メモリ不足エラーが発生していることを示している可能性があり、システムは積極的にプロセスを強制終了しています： //raspberrypi.stackexchange.com/questions/40883 / nginx-out-of-memory-kill-process
• プロセスがクラッシュしたり、このように強制的に強制終了されたりすると、nginxは、共有メモリがデッドワーカープロセスによってまだロックされていると見なす可能性があります。 たとえば、最初の例では、ワーカープロセス501が最初に強制終了されたように見えますが、それでもメモリはpid 501によってロックされていると見なされ、このデッドロックが発生します。
  
  
  
  • nginxはクラッシュ時に共有メモリのロックを解除することになっているようですので、なぜそれが起こらないのか完全にはわかりません。 しかし、ワーカーがSIGKILL（9）で殺されている場合は、すべての賭けがオフになっている可能性があります（sigkillは通常、プロセスを強制的に強制終了することを意味し、クリーンアップする機会がないため）。
  
  

では、システムレベルのログにメモリ不足やoom-killerについて何か見かけますか？ これらのサーバーで、nginxのメモリ増加またはメモリリークを示す可能性のある他の監視がありますか？ 私たちは、他のnginxのモジュールのいくつかはまた、役割を果たしている可能性がある場合、私は思ったんだけどので、私たちのLUA-resty-自動SSLのインストールのいずれかにおける任意のメモリリークを見てきたとは思わない（これがある言及Aのlua-upstream-cache-nginx-moduleのメモリリーク）。

申し訳ありませんが、 @ GUIに戻って、killed on signal 9はバグに関連していないことを明確にする強制終了しました。 これらのサーバーのメモリに問題はありません。約2GBのメモリがあり、実際に使用されているのはごくわずかで、残りはほとんどキャッシュです。 dmesgでOOMを強制終了することはありません。

問題を解決するためにいくつかのモジュールを削除し、非推奨のlua-upstream-cache-nginx-moduleを削除し、pagespeedを削除したことを追加する必要がありますが、これは役に立たなかったようです。

役立つ可能性のあるエラー行がさらにいくつかあります。すぐにサーバーから取得してみます。

@ajmgh ：関連しているかどうかは完全にはlua_shared_dictメモリサイズが小さすぎる場合に奇妙なエラーにつながる可能性のあるいくつかの潜在的な問題を追跡したと思います： https ：

では、システムにある証明書の概数と、nginx構成で構成されているlua_shared_dict auto_ssl大きさを知っていますか？ 可能であれば、v0.10.6にアップグレードしてみることもできます。これは、0.10.3以降、これを修正する可能性のある更新がいくつかあるため（運が良ければ）、少なくともエラー処理とメッセージが改善される可能性があるためです。

私はまったく同じエラーに直面しています。
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現在、短い文字列と1つのブール値のみを格納するため、変更しても違いはありません。 証明書は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のOpenResty1.11.2.3 / 4とlua-resty-auto-ssl0.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接続を強制終了するか、Dockerを再起動する必要があります。

@ajmghあなたはあなたの問題を解決しましたか？ openrestyコンテナでも同じ問題が発生しています。 CLOSE_WAIT状態で最大1200の接続があり、lua-resty-auto-sslでopenrestyのみを実行するサーバーの/ tmpに多くの脱水ファイルがあります。

これが私たちのシステム構成です

• どのバージョンのlua-resty-auto-sslを実行していますか？
  0.11.0-1
• luaモジュールを手動でインストールしてOpenRestyまたはnginxを実行していますか？
  openresty
• どのバージョンのOpenRestyまたはnginx + luaを実行していますか？
  openresty 1.11.2.4
• lua-resty-auto-ssl（Redis、ファイルシステム、その他）でどのストレージメカニズムを使用していますか？
  redis
• 物事はどのくらいの頻度でハングしますか？ 新しい証明書が登録されているか、更新が行われているときにのみ発生するように見えますか、それともランダムに見えますか？
  それは非常にランダムに見えます。 昨日発生したばかりで、システムのダウンタイムが30分になりました。 前回の発生は2ヶ月前でした。
• nginxをリロードしていますか（マスタープロセスを完全に再起動する代わりに、マスタープロセスにSIGHUPを送信し、新しいワーカーを生成します）？
  すべてのDockerコンテナを交換しました
• いくつのnginxワーカーを実行していますか（nginx configのworker_processes設定）？
  2
• 他のnginxプラグインがインストールされていますか（OpenRestyを使用している場合、デフォルトでOpenRestyに付属しているプラ​​グイン以外）？
  いいえ、lua-resty-auto-sslは私たちがインストールした唯一のプラグインです

@ronailいいえ。ただし、ラウンドロビンにサーバーを追加し、この問題が発生したときに自動再起動スクリプトを使用するようにしたため、大幅に軽減しました。

このバグを経験したDockerを使用している人は他にいますか？ たぶんそれはLua / OpenRestyとDockerの組み合わせで起こっている本当に奇妙なことです。

Dockerを使用していませんが、同じ問題に直面しています。

脱水状態で証明書を発行しようとすると、これが問題になると思います。

同様の問題が発生しており、jenkinsに30分ごとにOpenRestyを再起動させる必要があります（1時間ごとにクラッシュします...）

高いメモリ制限が設定されていますが、それが役立つ場合、LetsEncryptで失敗した認証に対してかなりの数のレート制限が発生していることに気付きましたか？

昨日同じ問題が発生し、根本的な原因が何であるかについてのポインタが含まれていないこれらのレポート（＃43、＃136）が見つかりました。 テストシステムで問題を再現できなかったため、本番システムでデバッグする必要がありました。 「幸いなことに」、ハングは十分に頻繁に発生したため、デバッグメソッドをすばやく繰り返すことができました。 まず、すべてのnginxプロセスでstrace -fp $ pidのみでした。これにより、すべてのプロセスがfutex（）を待機していることが明らかになりました。これは、pidの1つが常に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年以上スムーズに走った後、ちょうどこれに遭遇しました。

また、本番環境でこの問題が発生しました–

OpenRestyを>1.15.8.1更新します

これは非常に有害であるように思われるので、f66bb61f11a654f66d35dd793ceaf0293d9c0f46をすぐにリリースするか、少なくとも推奨事項ではなく、要件に合わせてドキュメントを更新する価値があるかもしれません。