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, просто выполняю перезапуск, но я попробую это и посмотрю, работает ли это тоже.
Первоначально я использовал 1 воркера, но когда возникли проблемы, я попытался увеличить его до 2, чтобы посмотреть, будет ли это иметь значение.
Используя следующие модули, не относящиеся к OpenResty:

• nginx-модуль-vts https://github.com/vozlt/nginx-module-vts
• lua-upstream-cache-nginx-модуль https://github.com/cloudflare/lua-upstream-cache-nginx-module
• модуль testcookie-nginx https://github.com/kyprizel/testcookie-nginx-module
  и --with-http_v2_module --with-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, что убитый по сигналу 9 не связан с ошибкой, но мы намеренно убиваем процесс nginx, чтобы противостоять проблеме. На этих серверах нет проблем с памятью, у них около 2 ГБ памяти, при этом фактически используется крошечный объем, а остальное в основном кеш. OOM не убивает dmesg.

Я должен добавить, что я удалил некоторые модули, чтобы попытаться решить проблему, устаревший модуль lua-upstream-cache-nginx-module и удалил pagepeed, но, похоже, это не помогло.

У меня есть еще несколько строк ошибок, которые могут быть полезны, я постараюсь получить их с серверов в ближайшее время.

@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 до 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

Я сталкивался с одной и той же проблемой несколько раз.
Я использую 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 вы решили свою проблему? Мы сталкиваемся с той же проблемой в наших контейнерах openresty. У нас есть ~ 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, файловая система, что-то еще)?
  Redis
• Как часто что-то зависает? Кажется, это происходит только тогда, когда регистрируются новые сертификаты или происходят обновления, или это кажется случайным?
  Выглядит очень случайно. Это произошло вчера и привело к 30-минутному простою в нашей системе. В прошлый раз это произошло 2 месяца назад.
• Вы вообще перезагружаете nginx (отправляете SIGHUP главному процессу и порождаете новых воркеров вместо полного перезапуска главного процесса)?
  мы просто заменили все докер-контейнеры
• Сколько рабочих процессов nginx у вас запущено (настройка worker_processes в конфигурации nginx)?
  2
• Установлены ли у вас какие-либо другие плагины nginx (помимо тех, которые поставляются с OpenResty по умолчанию, если вы используете OpenResty)?
  nope lua-resty-auto-ssl - единственный плагин, который мы установили

@ronail Нет, однако мы добавили дополнительные серверы в наш раундробин, а также создали сценарий автоматического перезапуска, когда возникает эта проблема, поэтому мы значительно ее смягчили.

Все, кто столкнулся с этой ошибкой, используют Docker? Возможно, что-то действительно странное происходит со смесью Lua / OpenResty и Docker.

Я не использую докер, и у меня такая же проблема.

Я предполагаю, что это проблема, когда обезвоженный пытается выдать сертификат.

У меня также возникает аналогичная проблема, когда мне приходится заставлять Дженкинса перезапускать OpenResty каждые 30 минут (сбои каждый час или около того постоянно ...)

У меня установлены высокие ограничения по памяти, однако я заметил, что получаю довольно много значений ratelimit для неудачных аутентификаций в LetsEncrypt, если это поможет?

Вчера мы столкнулись с той же проблемой и обнаружили эти отчеты (№43, №136), в которых не было указателей на то, что может быть основной причиной. Нам не удалось воспроизвести проблему в нашей тестовой системе, поэтому мы были вынуждены отлаживать в производственной системе. «К счастью», зависания случались достаточно часто, поэтому мы могли быстро перебирать наши методы отладки. Во-первых, это был только strace -fp $ pid для всех процессов nginx, и это показало, что все они ожидали futex () - в соответствии с тем фактом, что один из pid всегда удерживал блокировку на 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+ лет безупречной работы.

Также столкнулся с этой проблемой при производстве - спасибо @koszik и др. Просто чтобы подтвердить, чтобы решить эту проблему:

Обновите OpenResty до >1.15.8.1

Это кажется настолько пагубным, что, возможно, стоит в ближайшее время выпустить f66bb61f11a654f66d35dd793ceaf0293d9c0f46 или, по крайней мере, обновить документацию в соответствии с требованиями, а не рекомендацией.