Opened 10 years ago
Closed 10 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)
follow-up: 3 comment:1 by , 10 years ago
follow-up: 4 comment:2 by , 10 years ago
Добрый день!
Стандартная рекомендация для таких случаев: попробовать воспроизвести ситуацию без third-party modules, воспользовавшись, например, пакетами с nginx.org:
http://nginx.org/en/download.html
http://nginx.org/en/linux_packages.html
comment:3 by , 10 years ago
Replying to Valentin V. Bartenev:
На всякий случай уточню: а вы уверены, что у вас сообщения ядра попадают в
/var/log/messages? Имеет смысл посмотретьdmesg.
Смотрел и dmesg, там тоже пусто.
comment:4 by , 10 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 , 10 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
Сигнал 9 не мог случится сам по себе, его кто-то послал. Сам nginx мог это сделать только в том случае, если его попросили завершиться быстро и рабочие процессы не успели сделать это за 1 секунду. Если nginx завершаться не просили - значит, его послал кто-то ещё. OOM-killer наиболее вероятный кандидат, но я встречал и случаи, когда SIGKILL посылали неправильно настроенные скрипты вращения логов.
Что касается "помогла лишь перезагрузка", то это как раз вполне объяснимо - в версии 1.2.1 ещё не было разблокировки зон разделяемой памяти при аварийном завершении рабочих процессов. Так что даже одного "удачно" убитого по SIGKILL процесса могло оказаться достаточно, чтобы всё перестало работать. В свежих версиях ситуация чуть лучше - блокировку nginx снимает, и если сами структуры данных не повреждены - всё продолжит работать. Но вообще убивать nginx по SIGKILL - это плохо.
В любом случае это не выглядит как какая-либо ошибка в nginx'е, так что тикет я закрываю.
На всякий случай уточню: а вы уверены, что у вас сообщения ядра попадают в
/var/log/messages? Имеет смысл посмотретьdmesg.