судя по официальному сборщику (и мы похожим образом делали), отладочные
символы добавляются через --with-debug

http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l116

придумаю, что у вас - расскажу)) нет идей

сб, 1 июн. 2019 г. в 00:21, Илья Шипицин <chipitsine@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 <mif@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, Илья Шипицин <chipitsine@gmail.com>, wrote:
>>
>> покажите вывод
>>
>> file `which nginx`
>>
>> ?
>>
>> и такой момент. как можно с минимальным риском подменить бинарник
>> а) смотрим "nginx -V"
>> б) берем исходники, компилируем их с всем, что есть в пункте "a)" и
>> добавляем --with-debug
>> в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем
>> руками этот бинарник вместо nginx, который в путях (ни в коем случае не
>> "make install")
>>
>> сб, 1 июн. 2019 г. в 00:01, Alexey Galygin <mif@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, Илья Шипицин <chipitsine@gmail.com>, wrote:
>>
>> В error_log ничего на сегфолте не может записаться, нет особого смысла
>> его включать в debug
>>
>> По bt full больше инфы будет
>>
>> On Fri, May 31, 2019, 5:26 PM Alexey Galygin <mif@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, Илья Шипицин <chipitsine@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