Lua-resty-auto-ssl: مشكلة القفل

أوه ، آسف لسماع هذا أدى إلى انقطاع التيار!

لسوء الحظ ، لم أر شيئًا كهذا في التثبيت الخاص بنا الذي يحصل على قدر مناسب من حركة المرور (منذ الحادث الذي أشرت إليه في مارس الماضي). ومع ذلك ، كانت هناك مشكلة أخرى مماثلة إلى حد ما مثل هذه تم الإبلاغ عنها في # 29 ، حيث قمنا بإصلاح مشكلة ربما كانت ذات صلة ، لكنها ربما لم توضح المشكلة تمامًا. ولكن قد لا تكون هذه المشكلة مرتبطة أيضًا (كانت خاصة بوقت حدوث التسجيلات).

نشكرك على عرض المساعدة في تصحيح هذا ، مع ذلك ، سيكون من الجيد بالتأكيد الوصول إلى الجزء السفلي من. لدي بعض الأسئلة الأولية:

• ما هو إصدار lua-resty-auto-ssl الذي تستخدمه؟
• هل تقوم بتشغيل OpenResty أو nginx مع تثبيت وحدة lua يدويًا؟
• ما هي إصدارات OpenResty أو nginx + lua التي تقوم بتشغيلها؟
• ما آلية التخزين التي تستخدمها مع lua-resty-auto-ssl (Redis ، نظام الملفات ، شيء آخر)؟
• كم مرة تتعطل الأشياء؟ هل يبدو أنه يحدث فقط عندما يتم تسجيل شهادات جديدة أو إجراء عمليات تجديد ، أم أنها تبدو عشوائية؟
• هل تقوم بإعادة تحميل nginx على الإطلاق (إرسال SIGHUP إلى العملية الرئيسية وتوليد عمال جدد بدلاً من إعادة تشغيل العملية الرئيسية بالكامل)؟
• كم عدد العاملين في nginx الذين تقوم بتشغيلهم (إعداد worker_processes في تهيئة nginx)؟
• هل لديك أي إضافات nginx مثبتة (بخلاف تلك التي تأتي مع OpenResty افتراضيًا إذا كنت تستخدم OpenResty)؟

قيمة lua-resty-auto-ssl هي 0.10.3-1 من luarocks
نحن نستخدم 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 ، فقط أقوم بإعادة التشغيل ، لكنني سأحاول ذلك وأرى ما إذا كان هذا يعمل أيضًا.
في البداية كنت أستخدم عاملًا واحدًا ، لكنني حاولت زيادة هذا إلى 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
  و - مع - http_v2_module - مع - http_secure_link_module

أنا لا أستخدم أي Lua آخر في رمز التكوين بخلاف هذا المشروع.

آسف للمتابعة المتأخرة! بعد البحث حول المزيد ، لدي بعض النظريات حول ما قد يحدث:

• حقيقة أنك ترى أخطاء "تم الخروج عند الإشارة 9" ، قد تشير إلى أنك تصطدم بأخطاء نفاد الذاكرة ، وأن النظام يقتل العمليات بقوة: http://raspberrypi.stackexchange.com/questions/40883 / nginx-out-of-memory-kill-process
• عندما تتعطل عملية ما أو تُقتل بالقوة مثل هذا ، فقد يؤدي ذلك إلى تفكير nginx في أن الذاكرة المشتركة لا تزال مقفلة بواسطة عملية العامل الميت. على سبيل المثال ، في المثال الأولي الخاص بك ، يبدو أن العملية المنفذة 501 قد قُتلت أولاً ، لكنها لا تزال تعتقد أن الذاكرة مقفلة بواسطة pid 501 ، مما أدى إلى هذا المأزق.
  
  
  
  • يبدو أنه من المفترض أن يقوم nginx بإلغاء تأمين الذاكرة المشتركة عند حدوث أعطال ، لذلك لست متأكدًا تمامًا من سبب عدم حدوث ذلك. ولكن إذا تم قتل العمال باستخدام SIGKILL (9) ، فقد يتم إيقاف كل الرهانات (نظرًا لأن sigkill يعني عادةً قتل العملية بالقوة وليس هناك فرصة للتنظيف).
  
  

هل ترى أي شيء في سجلاتك على مستوى النظام حول نفاد الذاكرة أو قاتل oom-killer؟ هل لديك أي مراقبة أخرى على هذه الخوادم قد تشير إلى نمو الذاكرة أو تسرب الذاكرة في nginx؟ لا أعتقد أننا رأينا أي تسرب للذاكرة في أي من تركيبات lua-resty-auto-ssl الخاصة بنا ، لذلك أتساءل عما إذا كانت بعض وحدات nginx الأخرى قد تلعب دورًا أيضًا (هناك ذكر هذا لـ تسرب الذاكرة في lua-upstream-cache-nginx-module).

عذرًا - قصدت أن أوضح مرة أخرى لـ GUI أن بالخطأ ، لكننا نتعمد قتل عملية nginx لمواجهة المشكلة. لا توجد مشكلة في الذاكرة على هذه الخوادم ، فهي تحتوي على حوالي 2 غيغابايت من الذاكرة ، مع مقدار ضئيل يتم استخدامه فعليًا والباقي في الغالب ذاكرة تخزين مؤقت. لا تقتل OOM على dmesg.

يجب أن أضيف أنني أزلت بعض الوحدات لمحاولة المساعدة في هذه المشكلة ، ووحدة lua-upstream-cache-nginx المتوقفة وإزالة سرعة الصفحات ، ولكن لا يبدو أن هذا قد ساعد.

لدي عدد قليل من سطور الخطأ التي قد تكون مفيدة ، سأحاول الحصول عليها من الخوادم قريبًا.

ajmgh : لست متأكدًا تمامًا مما إذا كانت مرتبطة ، لكنني أعتقد أنني تعقبت بعض المشكلات المحتملة التي قد تؤدي إلى أخطاء غريبة إذا كان حجم الذاكرة الذي تم تكوينه lua_shared_dict منخفضًا جدًا: https://github.com / GUI / lua-resty-auto-ssl / issues / 48 # issuecomment -294397379

هل تعرف عدد الشهادات الموجودة في نظامك تقريبًا ، وما حجم lua_shared_dict auto_ssl تم تكوينه ليكون في تكوين nginx الخاص بك؟ يمكنك أيضًا محاولة الترقية إلى الإصدار v0.10.6 ، إن أمكن ، نظرًا لوجود بعض التحديثات منذ 0.10.3 والتي قد تعمل على إصلاح هذا (إذا كنا محظوظين) ، أو على الأقل توفير معالجة أفضل للأخطاء ورسائل.

أواجه نفس الخطأ بالضبط.
لقد قمت للتو بتحديث lua-resty-auto-ssl إلى الإصدار 0.10.6-1 وزيادة lua_shared_dict auto_ssl_settings إلى 1000
lua_shared_dict auto_ssl يحتفظ بالشيء نفسه: 1000

فقط في انتظار لمعرفة ما إذا كانت هذه التغييرات ستعمل على حل هذه المشكلة: /

ajmgh هل حل مشكلتك؟

يخزنaiev auto_ssl_settings حاليًا سلسلة قصيرة فقط بالإضافة إلى قيمة منطقية واحدة ، لذا لن يحدث تغييرها أي فرق. يتم تخزين الشهادات في auto_ssl . لذا يرجى محاولة زيادة ذلك بدلاً من ذلك.

لا ، التحديث الأخير لا يصلح مشكلتنا. لقد قمت برفع حجم auto_ssl إلى 8 ملايين ، وهو مبالغة لأننا نستخدم حوالي 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

لقد واجهت نفس المشكلة عدة مرات.
أنا أستخدم OpenResty 1.11.2.3/4 و lua-resty-auto-ssl 0.11.0-1 من luarocks.
عند ظهور هذه المشكلة ، هناك أكثر من 100 اتصال tcp عالقة في حالة CLOSE_WAIT.

لقد واجهنا نفس المشكلة عدة مرات أيضًا.
إصدار nginx: openresty / 1.11.2.4
lua-resty-auto-ssl 0.11.0-1
هناك العديد من حالات CLOSE_WAIT ، ولا يمكن لـ nginx الاستجابة بعد الآن. إما أننا بحاجة إلى إنهاء اتصال CLOSE_WAIT أو إعادة تشغيل عامل الإرساء لحل هذه المشكلة.

ajmgh هل حللت مشكلتك؟ نحن نواجه نفس المشكلة في حاويات الصراحة لدينا. حصلنا على 1200 اتصال تقريبًا في حالة CLOSE_WAIT والكثير من الملفات المجففة في / tmp في خوادمنا التي تعمل فقط مع openresty مع lua-resty-auto-ssl.

هنا هو تكوين نظامنا

• ما هو إصدار lua-resty-auto-ssl الذي تستخدمه؟
  0.11.0-1
• هل تقوم بتشغيل OpenResty أو nginx مع تثبيت وحدة lua يدويًا؟
  الصراحة
• ما هي إصدارات OpenResty أو nginx + lua التي تقوم بتشغيلها؟
  الصراحة 1.11.2.4
• ما آلية التخزين التي تستخدمها مع lua-resty-auto-ssl (Redis ، نظام الملفات ، شيء آخر)؟
  ريديس
• كم مرة تتعطل الأشياء؟ هل يبدو أنه يحدث فقط عندما يتم تسجيل شهادات جديدة أو إجراء عمليات تجديد ، أم أنها تبدو عشوائية؟
  يبدو عشوائيًا جدًا. لقد حدث بالأمس وأدى إلى توقف لمدة 30 دقيقة في نظامنا. كانت المرة السابقة التي حدث فيها ذلك قبل شهرين.
• هل تقوم بإعادة تحميل nginx على الإطلاق (إرسال SIGHUP إلى العملية الرئيسية وتوليد عمال جدد بدلاً من إعادة تشغيل العملية الرئيسية بالكامل)؟
  لقد استبدلنا للتو جميع حاويات الرصيف
• كم عدد العاملين في nginx الذين يعملون لديك (إعداد worker_processes في تكوين nginx)؟
  2
• هل لديك أي إضافات nginx مثبتة (بخلاف تلك التي تأتي مع OpenResty افتراضيًا إذا كنت تستخدم OpenResty)؟
  nope lua-resty-auto-ssl هو المكون الإضافي الوحيد الذي قمنا بتثبيته

ronail لا ، ولكننا أضفنا خوادم إضافية على roundrobin الخاص بنا وكذلك لدينا برنامج نصي لإعادة التشغيل التلقائي عند حدوث هذه المشكلة ، لذلك قمنا بتخفيفها بشكل كبير.

هل يستخدم أي شخص آخر Docker الذي يعاني من هذا الخطأ؟ ربما يكون شيئًا غريبًا حقًا يحدث مع مزيج من Lua / OpenResty و Docker.

أنا لا أستخدم عامل الإرساء وأواجه نفس المشكلة.

أعتقد أن هذه مشكلة عندما يحاول المجفف إصدار الشهادة.

لدي أيضًا مشكلة مماثلة ، حيث أضطر إلى إجبار Jenkins على إعادة تشغيل OpenResty كل 30 دقيقة (يتعطل كل ساعة أو بشكل مستمر ...)

لقد تم تعيين حدود ذاكرة عالية ، ومع ذلك فقد لاحظت أنني أحصل على عدد قليل جدًا من الحدود المعدية لعمليات المصادقة الفاشلة على LetsEncrypt إذا كان ذلك يساعد؟

لقد واجهتنا نفس المشكلة بالأمس ، ووجدنا هذه التقارير (# 43 ، # 136) التي لا تحتوي على مؤشرات لما قد يكون السبب الأساسي. لم نتمكن من إعادة إظهار المشكلة في نظام الاختبار الخاص بنا ، لذلك اضطررنا إلى تصحيح الأخطاء في نظام الإنتاج. "لحسن الحظ" ، كانت عمليات التعليق متكررة بدرجة كافية ، لذلك يمكننا التكرار بسرعة من خلال أساليب التصحيح الخاصة بنا. أولاً ، لم يكن سوى strace -fp $ pid على جميع عمليات nginx ، وقد كشف هذا أن جميعهم كانوا ينتظرون في futex () - بما يتوافق مع حقيقة أن أحد النوتات يحمل دائمًا قفلًا على shdict. بعد ذلك ، أضفت ملف تفريغ لـ gdb backtrace لكل عملية ، وبعد إضافة رموز التصحيح إلى الصورة ، أصبح من الواضح أن المشكلة في مسار الكود التالي:

#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 أحيانًا باستدعاء جامع القمامة ، والذي قد يرغب في إزالة العناصر من نفس الأداة ، مما يتسبب في حدوث مأزق.

كان الحل السريع والقذر هو هذا (إنه أمر قبيح جدًا لن أنشر تصحيحًا) ؛

    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 قريبًا ، أو على الأقل تحديث المستندات وفقًا للمتطلبات ، بدلاً من التوصية.