<div dir="ltr"><div>у программы, собранной с отладочными символами должно быть вот так (with debug_info, not stripped)<br></div><div><br></div><div>[ilia@localhost ~]$ gcc -g 1.c<br>[ilia@localhost ~]$ file a.out<br>a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a767b5ee04499077d7685c5d353759d331846666, with debug_info, not stripped<br>[ilia@localhost ~]$ <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 1 июн. 2019 г. в 00:16, Alexey Galygin <<a href="mailto:mif@me.com">mif@me.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<div dir="auto">на CentOS /sbin – симлинк на /usr/sbin<br></div>
<div dir="auto">which nginx даёт /sbin/nginx</div>
<div dir="auto"><br></div>
<div dir="auto">но файл тот же</div>
<div dir="auto"><br></div>
<div dir="auto">$ file `which nginx`<br>
/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></div>
<div dir="auto"><br></div>
<div dir="auto">а)</div>
<div dir="auto"><br></div>
<div dir="auto">nginx version: nginx/1.16.0<br>
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)<br>
built with OpenSSL 1.1.1b 26 Feb 2019<br>
TLS SNI support enabled<br>
configure arguments: --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 dir="auto"><br></div>
<div dir="auto">б)</div>
<div dir="auto"><br></div>
<div dir="auto">уже днём так и сделал</div>
<div dir="auto"><br></div>
<div dir="auto">в)</div>
<div dir="auto"><br></div>
<div dir="auto">make install вполне себе сделал дело</div>
<div dir="auto">файл тот же</div>
<div dir="auto"><br></div>
<div dir="auto">~/work/nginx-1.16.0/objs # sha1sum nginx<br>
29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx<br>
<br></div>
<div dir="auto">~/work/nginx-1.16.0/objs # ls -la nginx<br>
-rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx<br>
<br></div>
<div dir="auto">~/work/nginx-1.16.0/objs # ls -la /sbin/nginx<br>
-rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx<br>
<br></div>
<div dir="auto">~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx<br>
29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx<br></div>
<div dir="auto"><br></div>
</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">On 31 May 2019, 22:08 +0300, Илья Шипицин <<a href="mailto:chipitsine@gmail.com" target="_blank">chipitsine@gmail.com</a>>, wrote:<br>
<blockquote type="cite" class="gmail-m_-7867124161268206480spark_quote" style="margin:5px;padding-left:10px;border-left:thin solid rgb(26,188,156)">
<div dir="ltr">
<div>покажите вывод</div>
<div><br></div>
<div>file `which nginx`</div>
<div><br></div>
<div>?</div>
<div><br></div>
<div>и такой момент. как можно с минимальным риском подменить бинарник</div>
<div>а) смотрим "nginx -V"</div>
<div>б) берем исходники, компилируем их с всем, что есть в пункте "a)" и добавляем --with-debug</div>
<div>в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем руками этот бинарник вместо nginx, который в путях (ни в коем случае не "make install")<br></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <<a href="mailto:mif@me.com" target="_blank">mif@me.com</a>>:<br></div>
<blockquote class="gmail_quote gmail-m_-7867124161268206480spark_quote" style="margin:5px;padding-left:10px;border-left:thin solid rgb(230,126,34)">
<div>
<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, Илья Шипицин <<a href="mailto:chipitsine@gmail.com" target="_blank">chipitsine@gmail.com</a>>, wrote:<br>
<blockquote type="cite" class="gmail-m_-7867124161268206480gmail-m_8386205402112152215spark_quote gmail-m_-7867124161268206480spark_quote" style="margin:5px;padding-left:10px;border-left:thin solid rgb(52,152,219)">
<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" target="_blank">mif@me.com</a>> wrote:<br></div>
<blockquote class="gmail_quote gmail-m_-7867124161268206480gmail-m_8386205402112152215spark_quote gmail-m_-7867124161268206480spark_quote" style="margin:5px;padding-left:10px;border-left:thin solid rgb(211,84,0)">
<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" rel="noreferrer" target="_blank">chipitsine@gmail.com</a>>, wrote:<br>
<blockquote type="cite" style="margin:5px;padding-left:10px;border-left:thin solid rgb(52,73,94)" class="gmail-m_-7867124161268206480gmail-m_8386205402112152215spark_quote gmail-m_-7867124161268206480spark_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" rel="noreferrer" target="_blank">nginx-ru@nginx.org</a>>:<br></div>
<blockquote class="gmail_quote gmail-m_-7867124161268206480gmail-m_8386205402112152215spark_quote gmail-m_-7867124161268206480spark_quote" style="margin:5px;padding-left:10px;border-left:thin solid rgb(46,204,113)">
<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/" rel="noreferrer" target="_blank">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/" rel="noreferrer" target="_blank">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/" rel="noreferrer" target="_blank">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/" rel="noreferrer" target="_blank">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;padding-left:10px;border-left:thin solid rgb(155,89,182)" class="gmail-m_-7867124161268206480gmail-m_8386205402112152215spark_quote gmail-m_-7867124161268206480spark_quote"></blockquote>
</div>
</div>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" rel="noreferrer" target="_blank">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>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>

</blockquote></div>