Lua-resty-auto-ssl: Masalah penguncian

Aduh, maaf mendengar ini menyebabkan pemadaman!

Sayangnya saya belum pernah melihat hal seperti ini di instalasi kami yang mendapatkan jumlah lalu lintas yang layak (sejak insiden Maret lalu yang Anda maksud). Namun, ada masalah lain yang agak mirip seperti yang dilaporkan di #29, di mana kami memperbaiki masalah yang mungkin terkait, tetapi mungkin tidak sepenuhnya menjelaskan masalah tersebut. Tetapi masalah itu mungkin juga tidak terkait (khusus saat pendaftaran terjadi).

Terima kasih atas tawaran untuk membantu men-debug ini, meskipun, pasti akan baik untuk sampai ke dasar. Saya punya beberapa pertanyaan awal:

• Versi lua-resty-auto-ssl apa yang Anda jalankan?
• Apakah Anda menjalankan OpenResty atau nginx dengan modul lua diinstal secara manual?
• Versi OpenResty atau nginx+lua apa yang Anda jalankan?
• Mekanisme penyimpanan apa yang Anda gunakan dengan lua-resty-auto-ssl (Redis, filesystem, sesuatu yang lain)?
• Seberapa sering hal-hal menggantung? Apakah itu tampaknya hanya terjadi ketika sertifikat baru didaftarkan atau pembaruan sedang berlangsung, atau tampaknya acak?
• Apakah Anda memuat ulang nginx sama sekali (mengirim SIGHUP ke proses master dan memunculkan pekerja baru alih-alih memulai ulang sepenuhnya proses master)?
• Berapa banyak pekerja nginx yang Anda jalankan ( pengaturan worker_processes di konfigurasi nginx)?
• Apakah Anda memiliki plugin nginx lain yang diinstal (di luar yang disertakan dengan OpenResty secara default jika Anda menggunakan OpenResty)?

lua-resty-auto-ssl adalah 0.10.3-1 dari luarocks
Kami menggunakan 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

Sistem file untuk saat ini, karena subdomain yang ditangani setiap server terpisah.
Tampaknya benar-benar acak ketika terjadi crash, mulai dari 3 jam hingga 3 hari yang baik.
Tidak memuat ulang nginx atm, hanya melakukan restart, tetapi saya akan mencoba ini dan melihat apakah ini berfungsi juga.
Awalnya saya menggunakan 1 pekerja, tetapi saya mencoba meningkatkan ini menjadi 2 ketika masalah terjadi untuk melihat apakah itu akan membuat perbedaan.
Menggunakan modul non-OpenResty berikut:

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

Saya belum menggunakan Lua lain dalam kode konfigurasi selain proyek ini.

Maaf untuk tindak lanjut yang tertunda! Setelah mencari-cari lagi, saya memiliki beberapa teori tentang apa yang mungkin terjadi:

• Fakta bahwa Anda melihat kesalahan "keluar pada sinyal 9", mungkin menunjukkan bahwa Anda mengalami kesalahan kehabisan memori, dan sistem secara agresif mematikan proses: http://raspberrypi.stackexchange.com/questions/40883 /nginx-out-of-memory-kill-process
• Ketika suatu proses macet atau dibunuh secara paksa seperti ini, maka itu dapat menyebabkan nginx berpikir bahwa memori bersama masih dikunci oleh proses pekerja yang mati. Misalnya, dalam contoh awal Anda, sepertinya proses pekerja 501 terbunuh terlebih dahulu, tetapi kemudian masih menganggap memori dikunci oleh pid 501, yang mengarah ke kebuntuan ini.
  
  
  
  • Sepertinya nginx seharusnya membuka kunci memori bersama saat macet, jadi saya tidak sepenuhnya yakin mengapa itu tidak terjadi. Tetapi jika pekerja terbunuh dengan SIGKILL (9), maka semua taruhan mungkin dibatalkan (karena sigkill biasanya berarti mematikan proses secara paksa dan tidak ada kesempatan untuk membersihkan).
  
  

Jadi, apakah Anda melihat sesuatu di log tingkat sistem Anda tentang kehabisan memori atau oom-killer? Apakah Anda memiliki pemantauan lain di server ini yang mungkin mengindikasikan pertumbuhan memori atau kebocoran memori di nginx? Saya tidak berpikir kami telah melihat kebocoran memori di salah satu instalasi lua-resty-auto-ssl kami, jadi saya bertanya-tanya apakah beberapa modul nginx lain mungkin juga berperan (ada yang menyebutkan a kebocoran memori di modul lua-upstream-cache-nginx).

Maaf - saya bermaksud untuk mengklarifikasi kembali ke @GUI bahwa

Saya harus menambahkan bahwa saya telah menghapus beberapa modul untuk mencoba dan membantu masalah ini, modul lua-upstream-cache-nginx-module yang tidak digunakan lagi dan menghapus kecepatan halaman, tetapi ini sepertinya tidak membantu.

Saya memiliki beberapa baris kesalahan lagi yang mungkin bisa membantu, saya akan mencoba dan mendapatkannya dari server segera.

@ajmgh : Saya tidak sepenuhnya yakin apakah ini terkait, tetapi saya pikir saya melacak beberapa masalah potensial yang dapat menyebabkan kesalahan aneh jika ukuran memori lua_shared_dict dikonfigurasi terlalu rendah: https://github.com /GUI/lua-resty-auto-ssl/issues/48#issuecomment -294397379

Jadi, apakah Anda tahu kira-kira berapa banyak sertifikat yang ada di sistem Anda, dan seberapa besar lua_shared_dict auto_ssl yang dikonfigurasi dalam konfigurasi nginx Anda? Anda juga dapat mencoba memutakhirkan ke v0.10.6, jika memungkinkan, karena ada beberapa pembaruan sejak 0.10.3 yang mungkin memperbaiki ini (jika kita beruntung), atau setidaknya memberikan penanganan kesalahan dan pesan yang lebih baik.

Saya menghadapi kesalahan yang persis sama.
Saya baru saja memperbarui lua-resty-auto-ssl ke versi 0.10.6-1 dan meningkatkan lua_shared_dict auto_ssl_settings menjadi 1000m (sebelum disetel ke 64k).
lua_shared_dict auto_ssl tetap sama: 1000m

Hanya menunggu untuk melihat apakah perubahan ini akan memperbaiki masalah ini :/

@ajmgh apakah Anda menyelesaikan masalah Anda?

@aiev auto_ssl_settings saat ini hanya menyimpan string pendek serta satu boolean, jadi mengubahnya tidak akan membuat perbedaan. Sertifikat disimpan di auto_ssl . Jadi, silakan coba tingkatkan itu.

Tidak, pembaruan terbaru tidak memperbaiki masalah kami. Saya telah meningkatkan ukuran auto_ssl menjadi 8M, yang berlebihan karena kami hanya menggunakan sekitar 10 sertifikat dan tidak melihat perubahan apa pun.

# 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

Saya telah mengalami masalah yang sama beberapa kali.
Saya menggunakan OpenResty 1.11.2.3/4 dan lua-resty-auto-ssl 0.11.0-1 dari luarocks.
Saat masalah ini muncul, lebih dari 100 koneksi tcp macet pada status CLOSE_WAIT.

Kami telah mengalami masalah yang sama berkali-kali juga.
versi nginx: openresty/1.11.2.4
lua-resty-auto-ssl 0.11.0-1
Ada banyak status CLOSE_WAIT, dan nginx tidak dapat merespons lagi. Entah kita perlu mematikan koneksi CLOSE_WAIT, atau memulai ulang buruh pelabuhan untuk menyelesaikan masalah ini.

@ajmgh sudahkah Anda menyelesaikan masalah Anda? Kami mengalami masalah yang sama dalam wadah openresty kami. Kami mendapatkan ~1200 koneksi dalam keadaan CLOSE_WAIT dan banyak file dehidrasi di /tmp di server kami yang hanya menjalankan openresty dengan lua-resty-auto-ssl.

Berikut adalah konfigurasi sistem kami

• Versi lua-resty-auto-ssl apa yang Anda jalankan?
  0.11.0-1
• Apakah Anda menjalankan OpenResty atau nginx dengan modul lua diinstal secara manual?
  restoran terbuka
• Versi OpenResty atau nginx+lua apa yang Anda jalankan?
  openresty 1.11.2.4
• Mekanisme penyimpanan apa yang Anda gunakan dengan lua-resty-auto-ssl (Redis, filesystem, sesuatu yang lain)?
  redis
• Seberapa sering hal-hal menggantung? Apakah itu tampaknya hanya terjadi ketika sertifikat baru didaftarkan atau pembaruan sedang berlangsung, atau tampaknya acak?
  Ini terlihat sangat acak. Itu baru saja terjadi kemarin dan menyebabkan downtime 30 menit di sistem kami. Sebelumnya terjadi 2 bulan yang lalu.
• Apakah Anda memuat ulang nginx sama sekali (mengirim SIGHUP ke proses master dan memunculkan pekerja baru alih-alih memulai ulang sepenuhnya proses master)?
  kami baru saja mengganti semua wadah buruh pelabuhan
• Berapa banyak pekerja nginx yang Anda jalankan (pengaturan worker_processes di konfigurasi nginx)?
  2
• Apakah Anda memiliki plugin nginx lain yang diinstal (di luar yang disertakan dengan OpenResty secara default jika Anda menggunakan OpenResty)?
  tidak lua-resty-auto-ssl adalah satu-satunya plugin yang kami instal

@ronail Tidak, namun kami menambahkan server tambahan di roundrobin kami serta memiliki skrip restart otomatis ketika masalah ini terjadi jadi kami telah menguranginya.

Apakah semua orang menggunakan Docker yang mengalami bug ini? Mungkin sesuatu yang sangat aneh terjadi dengan campuran Lua/OpenResty dan Docker.

Saya tidak menggunakan buruh pelabuhan dan saya menghadapi masalah yang sama.

Saya kira ini adalah masalah ketika dehidrasi mencoba mengeluarkan sertifikat.

Saya juga mendapatkan masalah serupa, harus memaksa jenkins untuk memulai ulang OpenResty setiap 30 menit (Macet setiap jam atau lebih terus-menerus ...)

Saya telah menetapkan batas memori yang tinggi, namun saya perhatikan saya mendapatkan beberapa batas kecepatan yang adil untuk autentikasi yang gagal di LetsEncrypt jika itu membantu?

Kami telah mengalami masalah yang sama kemarin, dan menemukan laporan ini (#43, #136) yang tidak berisi petunjuk tentang apa yang mungkin menjadi penyebab utama. Kami tidak dapat mereproduksi masalah pada sistem pengujian kami, jadi kami terpaksa melakukan debug pada sistem produksi. 'Untungnya', hang cukup sering terjadi, sehingga kami dapat dengan cepat mengulangi metode debug kami. Pertama, itu hanya strace -fp $pid pada semua proses nginx, dan ini mengungkapkan bahwa semuanya menunggu di futex() - konsisten dengan fakta bahwa salah satu pid selalu mengunci shdict. Selanjutnya, saya menambahkan dump gdb backtrace dari setiap proses, dan setelah menambahkan simbol debug ke gambar, menjadi jelas, bahwa masalahnya ada di jalur kode berikut:

#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

Setelah melihat sekilas ngx_http_lua_shdict_get_helper() akar penyebab masalah menjadi jelas: shdict terkunci, dan lua_pushlstring terkadang memanggil pengumpul sampah, yang mungkin ingin menghapus item dari shdict yang sama, menyebabkan kebuntuan.

Solusi cepat dan kotor saya adalah ini (sangat jelek saya tidak akan menerbitkan tambalan);

    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;

Sejauh ini ini berjalan dengan sempurna - seseorang dengan lebih banyak wawasan tentang cara kerja bagian dalam sistem mungkin ingin menghasilkan perbaikan yang lebih baik.

Menariknya, itu fakta yang diketahui!
https://github.com/openresty/lua-nginx-module/issues/1207#issuecomment -350745592

itu memang menarik. sesuai masalah yang Anda sebutkan, menggunakan lua-resty-core akan memperbaiki masalah, dan menurut dokumentasinya, ini dimuat secara otomatis sejak openresty 1.15.8.1, jadi bug ini diperbaiki secara diam-diam di versi itu. kami akan meningkatkan proxy kami dan melaporkan kembali.

sepertinya berfungsi dengan baik - dengan asumsi kondisi yang menyebabkannya hang sebelum masih bertahan, saya akan mengatakan bug telah diperbaiki.

Baru saja mengalami ini, setelah 3+ tahun berjalan mulus.

Juga mengalami masalah ini dalam produksi – terima kasih @koszik dan al. Hanya untuk mengonfirmasi, untuk menyelesaikan masalah ini:

Perbarui OpenResty ke >1.15.8.1

Ini tampaknya sangat merusak sehingga mungkin perlu segera merilis f66bb61f11a654f66d35dd793ceaf0293d9c0f46, atau setidaknya memperbarui dokumentasi sesuai kebutuhan, daripada rekomendasi.