сб, 1 июн. 2019 г. в 00:34, Alexey Galygin <m...@me.com>: > пересобрал с -ggdb > > NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # ./nginx -V > nginx version: nginx/1.16.0 > built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) > built with OpenSSL 1.1.1b 26 Feb 2019 > TLS SNI support enabled > configure arguments: --with-cc-opt='-g -ggdb -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 > > NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # file nginx > nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically > linked (uses shared libs), for GNU/Linux 2.6.32, > BuildID[sha1]=f8e9db46a969468c67841dec62402c989797d188, not stripped > > но про debug ничего действительно > > у меня тестовый падающий пример собранный с -g: > > int main() > { > int * a = 0x11122; > *a = 42; > } > > тоже выдаёт > > # file demo > demo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically > linked (uses shared libs), for GNU/Linux 2.6.32, > BuildID[sha1]=a363cfe37d2fd364fb092ff07e8333fc26e2f9a5, not stripped > > генерирует корку > > (gdb) bt full > #0 0x00000000004004dd in ?? () > No symbol table info available. > #1 0x0000000000000000 in ?? () > No symbol table info available. > > хотя днём удавалось его заставить писать хотя бы main() … > > может дело в LXD-контейнере, ядро Ubuntu 16, гость CentOS 7 … >
если пальцем в небо, можно попробовать в вашей конфигурации прогнать тесты https://github.com/nginx/nginx-tests, возможно это покажет на какую-то проблему в контейнере (хотя, если честно, самое интересное, это конечно, получить бектрейс) > On 31 May 2019, 22:26 +0300, Илья Шипицин <chipits...@gmail.com>, wrote: > > судя по официальному сборщику (и мы похожим образом делали), отладочные > символы добавляются через --with-debug > > http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l116 > > придумаю, что у вас - расскажу)) нет идей > > сб, 1 июн. 2019 г. в 00:21, Илья Шипицин <chipits...@gmail.com>: > > у программы, собранной с отладочными символами должно быть вот так (with > debug_info, not stripped) > > [ilia@localhost ~]$ gcc -g 1.c > [ilia@localhost ~]$ file a.out > 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 > [ilia@localhost ~]$ > > сб, 1 июн. 2019 г. в 00:16, Alexey Galygin <m...@me.com>: > > на CentOS /sbin – симлинк на /usr/sbin > which nginx даёт /sbin/nginx > > но файл тот же > > $ file `which nginx` > /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 > > а) > > nginx version: nginx/1.16.0 > built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) > built with OpenSSL 1.1.1b 26 Feb 2019 > TLS SNI support enabled > 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 > > б) > > уже днём так и сделал > > в) > > make install вполне себе сделал дело > файл тот же > > ~/work/nginx-1.16.0/objs # sha1sum nginx > 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx > > ~/work/nginx-1.16.0/objs # ls -la nginx > -rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx > > ~/work/nginx-1.16.0/objs # ls -la /sbin/nginx > -rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx > > ~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx > 29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx > > On 31 May 2019, 22:08 +0300, Илья Шипицин <chipits...@gmail.com>, wrote: > > покажите вывод > > file `which nginx` > > ? > > и такой момент. как можно с минимальным риском подменить бинарник > а) смотрим "nginx -V" > б) берем исходники, компилируем их с всем, что есть в пункте "a)" и > добавляем --with-debug > в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем > руками этот бинарник вместо nginx, который в путях (ни в коем случае не > "make install") > > сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <m...@me.com>: > > получил плоды ожидания корок > > $ file /usr/sbin/nginx > /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 > > $ nm -g /usr/sbin/nginx | grep main > U __libc_start_main@@GLIBC_2.2.5 > 000000000045a4c0 T main > 000000000048fdb0 T ngx_ssl_get_client_v_remain > 00000000005c9cf0 T rand_pool_bytes_remaining > > > > нападало две группы корок (то есть, осыпается сразу аж группами): > > -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434 > … всего порядка 20 штук за раз > -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635 > > и через пол часа: > > -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426 > … ешё 30 штук за раз > -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302 > > > падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес > 0x0…0) > но gdb символов в точке падения не видит: > > # gdb core.nginx.11620 > GNU gdb (GDB) … > Missing separate debuginfo for the main executable file > Try: yum --enablerepo='*debug*' install > /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой > штуки нет) > Core was generated by `nginx: worker pr'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007f8512e2ea1e in ?? () > "/tmp/core.nginx.11620" is a core file. > Please specify an executable to debug. > (gdb) bt full > #0 0x00007f8512e2ea1e in ?? () > No symbol table info available. > #1 0x0000000000000000 in ?? () > No symbol table info available. > (gdb) > > > куда копать? > > On 31 May 2019, 15:32 +0300, Илья Шипицин <chipits...@gmail.com>, wrote: > > В 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