В error_log ничего на сегфолте не может записаться, нет особого смысла его включать в debug
По bt full больше инфы будет On Fri, May 31, 2019, 5:26 PM Alexey Galygin <m...@me.com> wrote: > Илья, модули все из коробки > > ничего лишнего не доливаем > > из экстрима, пожалуй, только perl-модуль для ряда мелких задачек > > --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 > > --with-debug ещё добавил только что на время теста… и уровень отладки > error_log включил debug > но у нас за пару минут лог в таком режиме достигает 40 Мб ;-) > > корки сейчас включу и буду ловить > но это ещё умудриться словить момент и дождаться, когда упадёт, может за > час несколько раз свалится > > > On 31 May 2019, 14:48 +0300, Илья Шипицин <chipits...@gmail.com>, wrote: > > привет! > > segfault - с очень-очень-очень большой вероятностью из-за сторонних > модулей nginx. > можете показать вывод "nginx -V" ? > > как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с > отладкой, при это не strip-нуть ее в момент инсталяции > команда "file `which nginx`" должна показыват "not stripped" > > далее - в вашей операционной системе разрешаете сохранение core dump > (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей) > > потом, берете сохраненный core dump, при помощи gdb открываете, делаете > "bt full", смотрите на чем именно упало. > > если что, обращайтесь. тут в рассылке куча людей умеет такое делать )) > > пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru < > nginx-ru@nginx.org>: > >> всем привет >> >> ПРОБЛЕМА >> >> давно (уже не первый год обновление за обновлением nginx и OpenSSL) >> наблюдаем, >> что ряд страниц при обновлении кэша входят в вечный статус UPDATING >> >> см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет) >> >> происходит это совершенно на рандомных страницах, и способа воспроизвести >> нет – только по прецедентной жалобе от пользователей, что закешированный >> контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи >> всё в норму, но ждать до утра никто не хочет) >> >> КОНФИГУРАЦИЯ >> >> релевантные настройки такие: >> >> proxy_cache_use_stale error timeout invalid_header updating http_500 >> http_502 http_503 http_504; >> proxy_cache_background_update on; >> proxy_cache_lock on; >> proxy_cache_lock_timeout 25s; >> >> недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка >> кастомная): >> >> nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI >> support enabled >> >> при этом: >> >> nginx -s reload # не помогает… >> >> а помогает только явный «мягкий» перезапуск сервера (процедура похожая на >> обновление бинарника): >> >> #!/usr/bin/env bash >> # скрипт перезапуска или обновления бинарника: >> sudo kill -s USR2 `cat /run/nginx.pid` >> sudo kill -s WINCH `cat /run/nginx.pid.oldbin` >> echo 'waiting for 5 minutes required for graceful reload' >> sleep 300 >> sudo kill -s TERM `cat /run/nginx.pid.oldbin` >> >> ЛОГИ И ДЕМО >> >> есть предположение, что это из-за эпозодического падения worker'ов (таких >> набирается несколько десятков за день, при сотнях тысяч запросов) >> >> dmesg: >> >> [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp >> 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000] >> … >> >> error.log: >> >> 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on >> signal 11 (core dumped) >> … >> >> подобные падения нас пресделуют много лет (их в день не много), на самых >> разных версиях nginx, в разных ДЦ, на разных серверах, при разных >> окружениях; >> (по хорошему, надо включить сбор корок и попытаться разобраться, где оно >> падает…) >> >> наше предположение такое: >> >> воркер, который должен был обновить истёкшие данные умирает, а статус так >> и остаётся UPDATING (на вечно), >> всём клиентам отдаётся старый контент, >> а новые воркеры уже не планируют запрос обновления с бэка >> >> вот свежий пример (в заголовке x-ireland-cache-status выводим значение >> $upstream_cache_status): >> >> H27: ~ $ curl -I https://www.hse.ru/our/ >> HTTP/2 200 >> server: nginx >> date: Thu, 30 May 2019 14:54:52 GMT >> … >> x-ireland-cache-status: UPDATING >> >> … можно очень долго ждать – статус так и будет UPDATING … >> >> H27: ~ $ curl -I https://www.hse.ru/our/ >> HTTP/2 200 >> server: nginx >> date: Thu, 30 May 2019 14:56:47 GMT >> … >> x-ireland-cache-status: UPDATING >> >> после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был >> приведён выше): >> >> H27: ~ $ curl -I https://www.hse.ru/our/ >> HTTP/2 200 >> server: nginx >> date: Thu, 30 May 2019 14:57:37 GMT >> … >> x-ireland-cache-status: STALE >> >> H27: ~ $ curl -I https://www.hse.ru/our/ >> HTTP/2 200 >> server: nginx >> date: Thu, 30 May 2019 14:57:39 GMT >> … >> x-ireland-cache-status: HIT >> >> всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём >> следующего звоночка… >> >> у нас нет инструмента по отслеживанию «застрявших UPDATING», >> и нет способа точечно их пнуть >> (если только не отслеживать $upstream_cache_status по каждому ресурсу и >> переходы статусов со временем, которые в 99.99% переходят из UPDATING в >> правильные статусы); >> >> приходится ждать только сигнала от недовольных пользователей… >> >> РЕЗЮМИРУЕМ >> >> ещё раз, сценарий, как мы видим откуда растёт проблема: >> >> 1. некоторая страница успешно кэшируется >> 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер >> падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч >> запросов) >> 3. никакой больше воркер это задание не получает до перезапуска nginx >> 4. недовольные клиенты получают устаревший контент >> >> РЕШЕНИЕ? >> >> перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы. >> >> какие варианты решения подобной проблемы существуют? в чём может быть >> возможная причина? >> >> может есть рекомендации по дополнительным настройкам? >> >> да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но >> их (падения воркеров) надо учитывать в работе nginx: >> >> если это рассматривать как баг nginx – можно ли найти ему решение в >> будущих обновлениях, в виде отправки повторной задачи воркерам на >> обновление кэша, по таймауту?.. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > >
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
