Opened 6 years ago

Closed 6 years ago

#597 closed defect (worksforme)

Самопроизвольное отключение процессов

Reported by: openid.yandex.ru/amet1395 Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.2.x
Keywords: Cc:
uname -a: Linux binghost.ru 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.2.1
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module

Description

2014-07-22 08:07:54 я обнаружил, что один из моих сайтов не работает (shared hosting).
В 08:32:21 все сайты работать перестали.
Я посмотрел лог и увидел:
root@server:~# cat /var/log/nginx/error.log | grep "2014/07/22 08" | tail -8
2014/07/22 08:32:21 [alert] 9073#0: worker process 9074 exited on signal 9
2014/07/22 08:32:21 [alert] 9073#0: worker process 9075 exited on signal 9
2014/07/22 08:32:21 [alert] 9073#0: worker process 9076 exited on signal 9
2014/07/22 08:32:21 [alert] 9073#0: worker process 9079 exited on signal 9
2014/07/22 08:32:21 [alert] 9073#0: worker process 9080 exited on signal 9
2014/07/22 08:32:21 [alert] 9073#0: worker process 9081 exited on signal 9
2014/07/22 08:32:21 [alert] 9073#0: worker process 9082 exited on signal 9
2014/07/22 08:32:21 [alert] 9073#0: worker process 9084 exited on signal 9

Первым делом подумал, что процессы убил oom-killer, однако версия не подтвердилась:
root@server:~# cat /var/log/messages | grep -i oom
пусто

Помогла лишь перезагрузка nginx.

Каким образом я могу обнаружить причину отказа всех процессов nginx? Возможно я должен был смотреть другие логи и что-то упустил?

Change History (5)

comment:1 by Valentin V. Bartenev, 6 years ago

На всякий случай уточню: а вы уверены, что у вас сообщения ядра попадают в /var/log/messages? Имеет смысл посмотреть dmesg.

comment:2 by maxim, 6 years ago

Добрый день!

Стандартная рекомендация для таких случаев: попробовать воспроизвести ситуацию без third-party modules, воспользовавшись, например, пакетами с nginx.org:

http://nginx.org/en/download.html
http://nginx.org/en/linux_packages.html

in reply to:  1 comment:3 by openid.yandex.ru/amet1395, 6 years ago

Replying to Valentin V. Bartenev:

На всякий случай уточню: а вы уверены, что у вас сообщения ядра попадают в /var/log/messages? Имеет смысл посмотреть dmesg.

Смотрел и dmesg, там тоже пусто.

in reply to:  2 comment:4 by openid.yandex.ru/amet1395, 6 years ago

Replying to maxim:

Добрый день!

Стандартная рекомендация для таких случаев: попробовать воспроизвести ситуацию без third-party modules, воспользовавшись, например, пакетами с nginx.org:

http://nginx.org/en/download.html
http://nginx.org/en/linux_packages.html

Спасибо.
Дело в том что понятия не имею как воспроизвести эту ситуацию, так как вышла она спонтанно и наверное уже вряд ли повторится. Хотелось бы причину выяснить.

comment:5 by Maxim Dounin, 6 years ago

Resolution: worksforme
Status: newclosed

Сигнал 9 не мог случится сам по себе, его кто-то послал. Сам nginx мог это сделать только в том случае, если его попросили завершиться быстро и рабочие процессы не успели сделать это за 1 секунду. Если nginx завершаться не просили - значит, его послал кто-то ещё. OOM-killer наиболее вероятный кандидат, но я встречал и случаи, когда SIGKILL посылали неправильно настроенные скрипты вращения логов.

Что касается "помогла лишь перезагрузка", то это как раз вполне объяснимо - в версии 1.2.1 ещё не было разблокировки зон разделяемой памяти при аварийном завершении рабочих процессов. Так что даже одного "удачно" убитого по SIGKILL процесса могло оказаться достаточно, чтобы всё перестало работать. В свежих версиях ситуация чуть лучше - блокировку nginx снимает, и если сами структуры данных не повреждены - всё продолжит работать. Но вообще убивать nginx по SIGKILL - это плохо.

В любом случае это не выглядит как какая-либо ошибка в nginx'е, так что тикет я закрываю.

Note: See TracTickets for help on using tickets.