
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">

<div dir="auto">

<div dir="auto">получил плоды ожидания корок</div>

<div dir="auto"><br /></div>

$ file /usr/sbin/nginx<br />

/usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped<br />

<br />

$ nm -g /usr/sbin/nginx | grep main<br />

U __libc_start_main@@GLIBC_2.2.5<br />

000000000045a4c0 T main<br />

000000000048fdb0 T ngx_ssl_get_client_v_remain<br />

00000000005c9cf0 T rand_pool_bytes_remaining<br />

<br />

<br />

<br />

нападало две группы корок (то есть, осыпается сразу аж группами):<br />

<br />

-rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434<br />

… всего порядка 20 штук за раз<br />

-rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635<br />

<br />

и через пол часа:<br />

<br />

-rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426<br />

… ешё 30 штук за раз<br />

-rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302<br />

<br />

<br />

падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес 0x0…0)<br />

но gdb символов в точке падения не видит:<br />

<br />

# gdb core.nginx.11620<br />

GNU gdb (GDB) …<br />

Missing separate debuginfo for the main executable file<br />

Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой штуки нет)<br />

Core was generated by `nginx: worker pr'.<br />

Program terminated with signal 11, Segmentation fault.<br />

#0 0x00007f8512e2ea1e in ?? ()<br />

"/tmp/core.nginx.11620" is a core file.<br />

Please specify an executable to debug.<br />

(gdb) bt full<br />

#0 0x00007f8512e2ea1e in ?? ()<br />

No symbol table info available.<br />

#1 0x0000000000000000 in ?? ()<br />

No symbol table info available.<br />

(gdb)<br />

<div dir="auto"><br /></div>

<div dir="auto"><br /></div>

<div dir="auto">куда копать?</div>

<div dir="auto"><br /></div>

</div>

</div>

<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">On 31 May 2019, 15:32 +0300, Илья Шипицин <chipitsine@gmail.com>, wrote:<br />

<blockquote type="cite" class="spark_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">

<div dir="auto">В error_log ничего на сегфолте не может записаться, нет особого смысла его включать в debug

<div dir="auto"><br /></div>

<div dir="auto">По bt full больше инфы будет</div>

</div>

<br />

<div class="gmail_quote">

<div dir="ltr" class="gmail_attr">On Fri, May 31, 2019, 5:26 PM Alexey Galygin <<a href="mailto:mif@me.com">mif@me.com</a>> wrote:<br /></div>

<blockquote class="gmail_quote spark_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">

<div>

<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">Илья, модули все из коробки

<div><br /></div>

<div>ничего лишнего не доливаем</div>

<div><br /></div>

<div>из экстрима, пожалуй, только perl-модуль для ряда мелких задачек</div>

<div><br /></div>

<div>--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug<br /></div>

</div>

<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><br />

<div>--with-debug ещё добавил только что на время теста… и уровень отладки error_log включил debug</div>

<div>но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)</div>

<div><br /></div>

<div>корки сейчас включу и буду ловить</div>

<div>но это ещё умудриться словить момент и дождаться, когда упадёт, может за час несколько раз свалится</div>

<div><br /></div>

<div><br /></div>

</div>

<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">On 31 May 2019, 14:48 +0300, Илья Шипицин <<a href="mailto:chipitsine@gmail.com" target="_blank" rel="noreferrer">chipitsine@gmail.com</a>>, wrote:<br />

<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #3498db;" class="spark_quote">

<div dir="ltr">

<div>привет!</div>

<div><br /></div>

<div>segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей nginx.</div>

<div> можете показать вывод "nginx -V" ?</div>

<div><br /></div>

<div>как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с отладкой, при это не strip-нуть ее в момент инсталяции</div>

<div>команда "file `which nginx`" должна показыват "not stripped"</div>

<div><br /></div>

<div>далее - в вашей операционной системе разрешаете сохранение core dump (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)</div>

<div><br /></div>

<div>потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt full", смотрите на чем именно упало.</div>

<div><br /></div>

<div>если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))<br /></div>

</div>

<br />

<div class="gmail_quote">

<div dir="ltr" class="gmail_attr">пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <<a href="mailto:nginx-ru@nginx.org" target="_blank" rel="noreferrer">nginx-ru@nginx.org</a>>:<br /></div>

<blockquote class="gmail_quote spark_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #d35400;">

<div>

<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">

<div>всем привет</div>

<div><br /></div>

<div>ПРОБЛЕМА</div>

<div><br /></div>

<div>давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,</div>

<div>что ряд страниц при обновлении кэша входят в вечный статус UPDATING</div>

<div><br /></div>

<div>см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)</div>

<div><br /></div>

<div>происходит это совершенно на рандомных страницах, и способа воспроизвести нет – только по прецедентной жалобе от пользователей, что закешированный контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи всё в норму, но ждать до утра никто не хочет)</div>

<div><br /></div>

<div>КОНФИГУРАЦИЯ</div>

<div><br /></div>

<div>релевантные настройки такие:</div>

<div><br /></div>

<div>proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;</div>

<div>proxy_cache_background_update on;</div>

<div>proxy_cache_lock on;</div>

<div>proxy_cache_lock_timeout 25s;</div>

<div><br /></div>

<div>недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):</div>

<div><br /></div>

<div>nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled</div>

<div><br /></div>

<div>при этом:</div>

<div><br /></div>

<div>nginx -s reload # не помогает…</div>

<div><br /></div>

<div>а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):</div>

<div><br /></div>

<div>#!/usr/bin/env bash</div>

<div># скрипт перезапуска или обновления бинарника:</div>

<div>sudo kill -s USR2 `cat /run/nginx.pid`</div>

<div>sudo kill -s WINCH `cat /run/nginx.pid.oldbin`</div>

<div>echo 'waiting for 5 minutes required for graceful reload'</div>

<div>sleep 300</div>

<div>sudo kill -s TERM `cat /run/nginx.pid.oldbin`</div>

<div><br /></div>

<div>ЛОГИ И ДЕМО</div>

<div><br /></div>

<div>есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)</div>

<div><br /></div>

<div>dmesg:</div>

<div><br /></div>

<div>[4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]</div>

<div>…</div>

<div><br /></div>

<div>error.log:</div>

<div><br /></div>

<div>2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)</div>

<div>…</div>

<div><br /></div>

<div>подобные падения нас пресделуют много лет (их в день не много), на самых разных версиях nginx, в разных ДЦ, на разных серверах, при разных окружениях;</div>

<div>(по хорошему, надо включить сбор корок и попытаться разобраться, где оно падает…)</div>

<div><br /></div>

<div>наше предположение такое:</div>

<div><br /></div>

<div>воркер, который должен был обновить истёкшие данные умирает, а статус так и остаётся UPDATING (на вечно),</div>

<div>всём клиентам отдаётся старый контент,</div>

<div>а новые воркеры уже не планируют запрос обновления с бэка</div>

<div><br /></div>

<div>вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):</div>

<div><br /></div>

<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank" rel="noreferrer">https://www.hse.ru/our/</a></div>

<div>HTTP/2 200</div>

<div>server: nginx</div>

<div>date: Thu, 30 May 2019 14:54:52 GMT</div>

<div>…</div>

<div>x-ireland-cache-status: UPDATING</div>

<div><br /></div>

<div>… можно очень долго ждать – статус так и будет UPDATING …</div>

<div><br /></div>

<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank" rel="noreferrer">https://www.hse.ru/our/</a></div>

<div>HTTP/2 200</div>

<div>server: nginx</div>

<div>date: Thu, 30 May 2019 14:56:47 GMT</div>

<div>…</div>

<div>x-ireland-cache-status: UPDATING</div>

<div><br /></div>

<div>после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):</div>

<div><br /></div>

<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank" rel="noreferrer">https://www.hse.ru/our/</a></div>

<div>HTTP/2 200</div>

<div>server: nginx</div>

<div>date: Thu, 30 May 2019 14:57:37 GMT</div>

<div>…</div>

<div>x-ireland-cache-status: STALE</div>

<div><br /></div>

<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank" rel="noreferrer">https://www.hse.ru/our/</a></div>

<div>HTTP/2 200</div>

<div>server: nginx</div>

<div>date: Thu, 30 May 2019 14:57:39 GMT</div>

<div>…</div>

<div>x-ireland-cache-status: HIT</div>

<div><br /></div>

<div>всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…</div>

<div><br /></div>

<div>у нас нет инструмента по отслеживанию «застрявших UPDATING»,</div>

<div>и нет способа точечно их пнуть</div>

<div>(если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);</div>

<div><br /></div>

<div>приходится ждать только сигнала от недовольных пользователей…</div>

<div><br /></div>

<div>РЕЗЮМИРУЕМ</div>

<div><br /></div>

<div>ещё раз, сценарий, как мы видим откуда растёт проблема:</div>

<div><br /></div>

<div>1. некоторая страница успешно кэшируется</div>

<div>2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)</div>

<div>3. никакой больше воркер это задание не получает до перезапуска nginx</div>

<div>4. недовольные клиенты получают устаревший контент</div>

<div><br /></div>

<div>РЕШЕНИЕ?</div>

<div><br /></div>

<div>перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.</div>

<div><br /></div>

<div>какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?</div>

<div><br /></div>

<div>может есть рекомендации по дополнительным настройкам?</div>

<div><br /></div>

<div>да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:</div>

<div><br /></div>

<div>если это рассматривать как баг nginx – можно ли найти ему решение в будущих обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по таймауту?..</div>

</div>

<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">

<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #34495e;" class="spark_quote"></blockquote>

</div>

</div>

_______________________________________________<br />

nginx-ru mailing list<br />

<a href="mailto:nginx-ru@nginx.org" target="_blank" rel="noreferrer">nginx-ru@nginx.org</a><br />

<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote>

</div>

</blockquote>

</div>

</div>

</blockquote>

</div>

</blockquote>

</div>

</body>

</html>