Lua-resty-auto-ssl: लॉकिंग समस्या

आउच, यह सुनकर खेद है कि एक आउटेज हो गया!

दुर्भाग्य से मैंने अपने इंस्टालेशन में ऐसा कुछ भी नहीं देखा है जिसे अच्छी मात्रा में ट्रैफ़िक मिलता है (पिछले मार्च की घटना के बाद से जिसका आपने उल्लेख किया है)। हालाँकि, कुछ इसी तरह का एक और मुद्दा था जो #29 में रिपोर्ट किया गया था, जहाँ हमने एक ऐसा मुद्दा तय किया था जो संबंधित हो सकता था, लेकिन हो सकता है कि इसने इस मुद्दे को पूरी तरह से समझाया न हो। लेकिन वह मुद्दा भी संबंधित नहीं हो सकता है (यह विशिष्ट था जब पंजीकरण हुआ था)।

इसे डीबग करने में मदद करने के प्रस्ताव के लिए धन्यवाद, हालांकि, इसकी तह तक जाना निश्चित रूप से अच्छा होगा। मेरे कुछ प्रारंभिक प्रश्न हैं:

• आप लुआ-रेस्टी-ऑटो-एसएसएल का कौन सा संस्करण चला रहे हैं?
• क्या आप मैन्युअल रूप से स्थापित लुआ मॉड्यूल के साथ OpenResty या nginx चला रहे हैं?
• आप OpenResty या nginx+lua के कौन से संस्करण चला रहे हैं?
• लुआ-रेस्टी-ऑटो-एसएसएल (रेडिस, फाइल सिस्टम, कुछ और) के साथ आप किस स्टोरेज मैकेनिज्म का उपयोग कर रहे हैं?
• चीजें कितनी बार लटकती हैं? क्या ऐसा लगता है कि केवल तभी होता है जब नए प्रमाणपत्र पंजीकृत किए जा रहे हों या नवीनीकरण हो रहे हों, या यह यादृच्छिक प्रतीत होता है?
• क्या आप nginx को फिर से लोड कर रहे हैं (मास्टर प्रक्रिया में SIGHUP भेज रहे हैं और मास्टर प्रक्रिया को पूरी तरह से पुनरारंभ करने के बजाय नए श्रमिकों को पैदा कर रहे हैं)?
• आपके पास कितने nginx कार्यकर्ता चल रहे हैं ( worker_processes nginx config में सेटिंग)?
• क्या आपके पास कोई अन्य 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 को पुनः लोड नहीं करना, बस पुनरारंभ करना, लेकिन मैं इसे आज़माउंगा और देख सकता हूं कि यह भी काम करता है या नहीं।
प्रारंभ में मैं 1 कार्यकर्ता का उपयोग कर रहा था, लेकिन मैंने इसे 2 तक बढ़ाने की कोशिश की जब यह देखने के लिए कि क्या इससे कोई फर्क पड़ेगा।
निम्नलिखित गैर-ओपनरेस्टी मॉड्यूल का उपयोग करना:

• nginx-मॉड्यूल-vts https://github.com/vozlt/nginx-module-vts
• लुआ-अपस्ट्रीम-कैश-nginx-मॉड्यूल https://github.com/cloudflare/lua-upstream-cache-nginx-module
• testcookie-nginx-module https://github.com/kyprizel/testcookie-nginx-module
  और --साथ-http_v2_module --with-http_secure_link_module

मैं इस परियोजना के अलावा अभी तक कॉन्फ़िगरेशन कोड में किसी अन्य लुआ का उपयोग नहीं कर रहा हूं।

देरी से फॉलोअप के लिए खेद है! कुछ और खोज करने के बाद, मेरे पास कुछ सिद्धांत हैं कि क्या हो रहा है:

• तथ्य यह है कि आप "सिग्नल 9 पर बाहर निकले" त्रुटियों को देख रहे हैं, यह संकेत दे सकता है कि आप आउट-ऑफ-मेमोरी त्रुटियों को मार रहे हैं, और सिस्टम आक्रामक रूप से प्रक्रियाओं को मार रहा है: http://raspberrypi.stackexchange.com/questions/40883 /nginx-आउट-ऑफ-मेमोरी-किल-प्रोसेस
• जब कोई प्रक्रिया दुर्घटनाग्रस्त हो जाती है या इस तरह जबरन मार दी जाती है, तो यह nginx को यह सोचकर ले जा सकता है कि साझा स्मृति अभी भी मृत कार्यकर्ता प्रक्रिया द्वारा बंद है। उदाहरण के लिए, आपके प्रारंभिक उदाहरण में, ऐसा लगता है कि कार्यकर्ता प्रक्रिया 501 पहले मार दी जाती है, लेकिन फिर भी यह सोचता है कि स्मृति को pid ​​501 द्वारा बंद कर दिया गया है, जिससे यह गतिरोध हो सकता है।
  
  
  
  • ऐसा लगता है कि nginx को क्रैश पर साझा मेमोरी को अनलॉक करना है, इसलिए मुझे पूरी तरह से यकीन नहीं है कि ऐसा क्यों नहीं हो रहा है। लेकिन अगर सिगकिल (9) के साथ कार्यकर्ता मारे जा रहे हैं, तो सभी दांव बंद हो सकते हैं (चूंकि सिगकिल का मतलब आमतौर पर प्रक्रिया को जबरन मारना है और सफाई का कोई मौका नहीं है)।
  
  

तो क्या आप अपने सिस्टम-स्तरीय लॉग में स्मृति या ओम-किलर के बारे में कुछ भी देखते हैं? क्या आपके पास इन सर्वरों पर कोई अन्य निगरानी है जो स्मृति वृद्धि या nginx में स्मृति रिसाव का संकेत दे सकती है? मुझे नहीं लगता कि हमने अपने किसी भी लुआ-रेस्टी-ऑटो-एसएसएल इंस्टॉलेशन में कोई मेमोरी लीक देखा है, इसलिए मैं सोच रहा हूं कि क्या कुछ अन्य nginx मॉड्यूल भी भूमिका निभा सकते हैं (इसमें इसका उल्लेख है a लुआ-अपस्ट्रीम-कैश-nginx-मॉड्यूल में मेमोरी लीक)।

क्षमा करें - मेरा मतलब @GUI को वापस स्पष्ट करना था कि सिग्नल 9 पर मारे गए बग से जुड़ा नहीं है, लेकिन हम इस मुद्दे का मुकाबला करने के लिए जानबूझकर nginx प्रक्रिया को मार रहे हैं। इन सर्वरों पर मेमोरी के साथ कोई समस्या नहीं है, उनके पास लगभग 2GB मेमोरी है, वास्तव में एक छोटी राशि का उपयोग किया जा रहा है और बाकी ज्यादातर कैश है। कोई OOM dmesg पर नहीं मारता है।

मुझे यह जोड़ना चाहिए कि मैंने इस मुद्दे को आजमाने और मदद करने के लिए कुछ मॉड्यूल हटा दिए हैं, बहिष्कृत lua-upstream-cache-nginx-module और हटाए गए पेजस्पेड, लेकिन ऐसा लगता है कि इससे मदद नहीं मिली है।

मेरे पास कुछ और त्रुटि पंक्तियाँ हैं जो सहायक हो सकती हैं, मैं कोशिश करूँगा और उन्हें शीघ्र ही सर्वर से प्राप्त करूँगा।

@ajmgh : अगर यह संबंधित है तो मैं पूरी तरह से निश्चित नहीं हूं, लेकिन मुझे लगता है कि मैंने कुछ संभावित समस्याओं को ट्रैक किया है जो अजीब त्रुटियों को जन्म दे सकती हैं यदि कॉन्फ़िगर किया गया lua_shared_dict मेमोरी आकार बहुत कम था: https://github.com /GUI/lua-resty-auto-ssl/issues/48#issuecomment -294397379

तो क्या आप मोटे तौर पर जानते हैं कि आपके सिस्टम में कितने प्रमाणपत्र हैं, और आपके 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 वर्तमान में केवल एक छोटी स्ट्रिंग के साथ-साथ एक बूलियन भी संग्रहीत करता है, इसलिए इसे बदलने से कोई फर्क नहीं पड़ेगा। प्रमाणपत्र 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 संस्करण: ओपनरेस्टी/1.11.2.4
लुआ-रेस्टी-ऑटो-एसएसएल 0.11.0-1
कई CLOSE_WAIT राज्य हैं, और nginx अब प्रतिक्रिया नहीं दे सकता है। या तो हमें CLOSE_WAIT कनेक्शन को बंद करना होगा, या इस समस्या को हल करने के लिए docker को पुनरारंभ करना होगा।

@ajmgh क्या आपने अपनी समस्या हल कर

यहाँ हमारा सिस्टम कॉन्फ़िगरेशन है

• आप लुआ-रेस्टी-ऑटो-एसएसएल का कौन सा संस्करण चला रहे हैं?
  0.11.0-1
• क्या आप मैन्युअल रूप से स्थापित लुआ मॉड्यूल के साथ OpenResty या nginx चला रहे हैं?
  खुलापन
• आप OpenResty या nginx+lua के कौन से संस्करण चला रहे हैं?
  खुलापन 1.11.2.4
• लुआ-रेस्टी-ऑटो-एसएसएल (रेडिस, फाइल सिस्टम, कुछ और) के साथ आप किस स्टोरेज मैकेनिज्म का उपयोग कर रहे हैं?
  रेडिस
• चीजें कितनी बार लटकती हैं? क्या ऐसा लगता है कि केवल तभी होता है जब नए प्रमाणपत्र पंजीकृत किए जा रहे हों या नवीनीकरण हो रहे हों, या यह यादृच्छिक प्रतीत होता है?
  यह बहुत यादृच्छिक लगता है। यह कल ही हुआ और हमारे सिस्टम में ३० मिनट का डाउनटाइम हो गया। पिछली बार यह 2 महीने पहले हुआ था।
• क्या आप nginx को फिर से लोड कर रहे हैं (मास्टर प्रक्रिया में SIGHUP भेज रहे हैं और मास्टर प्रक्रिया को पूरी तरह से पुनरारंभ करने के बजाय नए श्रमिकों को पैदा कर रहे हैं)?
  हमने अभी सभी डॉकटर कंटेनरों को बदल दिया है
• आपके पास कितने nginx कार्यकर्ता चल रहे हैं (worker_processes nginx config में सेटिंग)?
  2
• क्या आपके पास कोई अन्य nginx प्लगइन्स स्थापित है (यदि आप OpenResty पर हैं तो डिफ़ॉल्ट रूप से OpenResty के साथ आने वाले प्लगइन्स से परे)?
  नहीं लुआ-रेस्टी-ऑटो-एसएसएल एकमात्र प्लगइन है जिसे हमने इंस्टॉल किया है

@ronail नहीं, हालाँकि हमने अपने राउंडरोबिन पर अतिरिक्त सर्वर जोड़े हैं और साथ ही एक स्वचालित पुनरारंभ स्क्रिप्ट है जब यह समस्या होती है तो हमने इसे बहुत कम कर दिया है।

क्या हर कोई डॉकर का उपयोग कर रहा है जो इस बग का अनुभव करता है? हो सकता है कि लुआ/ओपनरेस्टी और डॉकर के मिश्रण के साथ वास्तव में कुछ अजीब चल रहा हो।

मैं डोकर का उपयोग नहीं कर रहा हूँ और मैं एक ही समस्या का सामना कर रहा हूँ।

मुझे लगता है कि यह एक मुद्दा है जब निर्जलित प्रमाण पत्र जारी करने का प्रयास करता है।

मुझे भी इसी तरह का मुद्दा मिल रहा है, जेनकिंस को हर 30 मिनट में ओपनरेस्टी को फिर से शुरू करने के लिए मजबूर करना (हर घंटे या लगातार क्रैश ...)

मेरे पास उच्च स्मृति सीमाएं निर्धारित हैं, हालांकि मैंने देखा है कि अगर इससे मदद मिलती है तो मुझे LetsEncrypt पर असफल लेख के लिए कुछ उचित दर सीमाएं मिल रही हैं?

हमें कल भी यही समस्या का सामना करना पड़ा था, और हमें ये रिपोर्टें मिलीं (#43, #136) जिनमें कोई संकेत नहीं था कि मूल कारण क्या हो सकता है। हम अपने परीक्षण सिस्टम पर समस्या को पुन: पेश करने में असमर्थ थे, इसलिए हमें उत्पादन एक पर डिबग करने के लिए मजबूर होना पड़ा। 'सौभाग्य से', हैंग अक्सर पर्याप्त थे, इसलिए हम अपने डिबगिंग विधियों के माध्यम से जल्दी से पुनरावृति कर सकते थे। सबसे पहले, यह सभी nginx प्रक्रियाओं पर केवल एक strace -fp $pid था, और इससे पता चला कि वे सभी एक futex() पर प्रतीक्षा कर रहे थे - इस तथ्य के अनुरूप कि पिड्स में से एक हमेशा एक shdict पर ताला रखता था। इसके बाद, मैंने प्रत्येक प्रक्रिया के जीडीबी बैकट्रैक का एक डंप जोड़ा, और छवि में डीबग प्रतीकों को जोड़ने के बाद, यह स्पष्ट हो गया कि समस्या निम्न कोड पथ पर है:

#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 का उपयोग करने से समस्या ठीक हो जाएगी, और इसके दस्तावेज़ीकरण के अनुसार, यह ओपनरेस्टी 1.15.8.1 के बाद से स्वचालित रूप से लोड हो जाता है, इसलिए यह बग उस संस्करण में चुपचाप तय किया गया था। हम अपने प्रॉक्सी को अपग्रेड करेंगे और वापस रिपोर्ट करेंगे।

ऐसा लगता है कि यह पूरी तरह से काम कर रहा है - यह मानते हुए कि यह अभी भी जारी रहने से पहले लटका हुआ है, मैं कहूंगा कि बग को ठीक कर दिया गया है।

3+ साल सुचारू रूप से चलने के बाद, बस इसमें भाग गया।

उत्पादन में भी इस मुद्दे में भाग गया - धन्यवाद @koszik और al। बस पुष्टि करने के लिए, इस मुद्दे को हल करने के लिए:

OpenResty को >1.15.8.1 अपडेट करें

यह इतना हानिकारक लगता है कि यह जल्द ही f66bb61f11a654f66d35dd793ceaf0293d9c0f46 जारी करने के लायक हो सकता है, या कम से कम एक सिफारिश के बजाय दस्तावेज़ीकरण को आवश्यकता के अनुसार अपडेट कर सकता है।