Nginx reload не работает

Команда nginx reload shell не работает в скрипте lua

У меня есть докернизированный сервер Nginx, созданный с базовым образом openresty. Когда вызывается конкретная конечная точка, необходимо динамически обновлять конфигурацию nginx. Чтобы изменения отражали, я пытаюсь перезагрузить nginx вскоре после изменений в конфигурации.

В контейнере я могу перезагрузить сервер nginx, используя /usr/local/openresty/nginx/sbin/nginx -s reload

Когда я пытаюсь использовать то же самое с in lua, как показано ниже, оно не выдает никакой ошибки, но изменения конфигурации не отражаются.

2 ответа

Вы можете вообще пропустить вызов nginx и просто отправить сигнал HUP ведущему процессу, используя FFI LuaJIT.

Однако это не решает проблему с разрешениями.

Одна идея, которая могла бы работать:

• Настройте именованный канал с помощью mkfifo и сделайте так, чтобы ваш пользователь nginx мог писать в него
• Включить Привилегированный агент рабочий процесс.
• Установите привилегированного работника так, чтобы он прослушивал входные данные в именованном канале (например, с помощью модуля ngx.pipe открывал cat и ждал ввода) и отправлял сигнал HUP главному процессу
• Измените код os.execute , чтобы вместо этого записать некоторую строку текста в именованный канал, чтобы привилегированный агент перезагрузил сервер.

На самом деле вы даже можете заменить именованный канал на openresty семафор, чтобы сделать все это полностью автономным в одном экземпляре сервера nginx: D

Эта команда будет выполняться с правами рабочего процесса nginx, и для ее выполнения вам нужно быть пользователем root. Вы можете попробовать создать для этого конкретный скрипт (предположим, его имя будет /usr/local/openresty/nginx/sbin/reload-nginx.sh :

Установите владельца этого сценария без имени пользователя процесса nginx (допустим, его имя nginx) и установите suid немного в этом скрипте

И попробуйте выполнить этот скрипт из вашего кода lua:

Источник

Как перезапустить Nginx

Если вы начинающий администратор или только перенесли свой проект на VPS и еще не со всем разобрались, то у вас может возникнуть вопрос как перезапустить Nginx. Это очень популярный веб-сервер, такой же популярный, как и Apache и достаточно часто используется для различных проектов.

Перезапуск веб-сервера может понадобиться после того, как вы изменили его настройки, добавили новый домен и так далее. В этой небольшой статье мы рассмотрим как выполняется перезагрузка Nginx на сервере.

Как перезапустить Nginx

Первое что вам нужно — это получить доступ по ssh к серверу, но если вы уже меняли там какие-либо настройки, то, скорее всего, доступ у вас есть, так что этот момент упустим. Другой момент, это система управления процессами, сейчас большинство, если не все популярные дистрибутивы, используют systemd. Поэтому я буду описывать работу именно с ней. И еще, вам нужен именно VPS, или сервер, на хостинге такое сделать у вас не получится, даже если есть ssh доступ.

Первое что желательно сделать если вы меняли настройки Nginx, и что-то делали с конфигурационными файлами, это проверить их на ошибки с помощью команды:

Если это производственный сервер, то пользователи вообще не должны заметить что был перезапуск Nginx, а если будут проблемы то после установки веб-сервер не запустится и будет лежать пока вы их не решите. Только теперь можно перезапустить Nginx:

systemctl restart nginx

Если нужно только перечитать конфигурационные файлы выполните:

systemctl reload nginx

Есть еще один путь, можно передать команду перезапуска самому сервису nginx с помощью опции -s:

В случае если обычная перезагрузка не помогла, можно попытаться остановить сервис, а затем снова его запустить:

systemctl status nginx

systemctl stop nginx

systemctl start nginx

Перезапуск Nginx с помощью ISPManager

Панель управления VPS ISPManager довольно популярна среди пользователей и если вы используете ее на своем сервере, то можете перезапустить Nginx с помощью нее. Для этого авторизуйтесь в панели, перейдите на вкладку «Система», «Службы», а затем найдите там пункт «Nginx», выделите его и нажмите кнопку «Перезапуск»:

Готово, теперь Nginx перезапущен.

Выводы

В этой небольшой статье мы рассмотрели как перезапустить Nginx на вашем сервере. Если у вас остались вопросы, спрашивайте в комментариях!

Конференция HighLoad в которой рассказывается что нового в Nginx:

Источник

Ошибки Nginx и их устранение

Описание основных ошибок и варианты их устранения

502 Bad Gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache,Memcached, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его).

Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в /etc/php-fpm.d/www.conf прописаны правильные права

504 Gateway Time-out

Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если сервис, с которым nginx работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.

При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения

Также, причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.

Здесь тоже можно увеличить время ожидания таймаута

413 Request Entity Too Large

Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку

и заменить значение на нужное. Например, мы увеличим размер загружаеамых файлов до 30Mb

Также, можно отключить проверку тела ответа полностью значением ноль:

После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx

Как перезагрузить nginx

Для перезагрузки NGINX используйте restart или reload.

Команда в консоли:

Эти команды остановят и перезапустят сервер NGINX.

Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:

Проверить правильность конфигурации можно командой

В чём разница между reload и restart

Как происходит перезагрузка в NGINX:

Команда посылается серверу

Сервер анализирует конфигурационный файл

Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу

Если конфигурация содержит ошибки, то при использовании

restart процесс перезагрузки сервера прерывается, сервер не запускается

reload сервер откатывается назад к старой конфигурации, работа продолжается

restart обрывает работу резко, reload делает это плавно.

Источник

Почему nginx недоступен во время reload?

Во время релоада конфига nginx (4 ядра, 4Gb, выступает в роли reverse proxy) временно перестает отвечать на запросы, включая и те, что приходят на localhost (zabbix рапортует о недоступности). RPS при этом находится на уровне 1600-1800, netstat ничего, на мой взгляд, необычного, не показывает.

• Вопрос задан более трёх лет назад
• 1056 просмотров

140 секунд после выполнения команды.

Алексей: Тестил postman’ ом — похоже, именно не соединяется, плюс по графикам видно, что клиенты ждут ответа, и не отвалившиеся по таймауту резко отлпой наваливаются после того, как nginx приходит в себя.

По поводу 80 и 443 — подозреваю, что да, аналогичное, но не проверял.

В error.log ничего по этому поводу нет.

Два подряд релоада приводят к тому, что существенно подрастает лоад на сервере (worker_priority -15) и выедатется почти вся память, потому воркеры начинают прибиваться oom killer’ом (видно по записям в messages).

iowait процессов с высоким IO не показывает. В top, похоже, тоже все ок.

Dmitry:
Вот этого бывает достаточно:

‘active-connections-openings’)
res=`netstat -s | grep ‘active connections openings’ | awk ‘‘` ;;

‘passive-connection-openings’)
res=`netstat -s | grep ‘passive connection openings’ | awk ‘‘` ;;

‘failed-connection-attempts’)
res=`netstat -s | grep ‘failed connection attempts’ | awk ‘‘` ;;

‘packets-pruned-socket-buffer-overrun’)
res=`netstat -s | grep ‘packets pruned from receive queue because of socket buffer overrun’ | awk ‘‘` ;;

‘listen-overflowed’)
res=`netstat -s | grep ‘listen queue of a socket overflowed’ | awk ‘‘` ;;

‘TCPTimeouts’)
res=`netstat -s | grep ‘TCPTimeouts’ | awk ‘‘` ;;

‘established’)
res=`netstat -s | grep ‘connections established’ | awk ‘‘` ;;

‘invalid-SYN-cookies-received’)
res=`netstat -s | grep ‘invalid SYN cookies received’ | awk ‘‘` ;;

‘resets-received-for-embryonic-SYN_RECV-sockets’)
res=`netstat -s | grep ‘resets received for embryonic SYN_RECV sockets’ | awk ‘‘` ;;

‘connection-resets-received’)
res=`netstat -s | grep ‘connection resets received’ | awk ‘‘` ;;

‘TCPRenoFailures’)
res=`netstat -s | grep ‘TCPRenoFailures’ | awk ‘‘` ;;

‘TCPLossFailures’)
res=`netstat -s | grep ‘TCPLossFailures’ | awk ‘‘` ;;

‘TCPSlowStartRetrans’)
res=`netstat -s | grep ‘TCPSlowStartRetrans’ | awk ‘‘` ;;

‘TCPAbortOnClose’)
res=`netstat -s | grep ‘TCPAbortOnClose’ | awk ‘‘` ;;

*)
echo ‘3999999999’ ;;
esac

[ x»$res» == x»» ] && echo 1 || echo $res
exit 0

—
+ Вывести это отдельными графиками на скрин, сгруппировав по ошбикам/кол-ву коннектов/кол-ву established. Для дебага задать интервал обновления поменьше, аля 15-30 секунд.

Источник

Nginx config reload without downtime

I use nginx as a reverse proxy. Whenever I update the config for it using

I face a brief downtime. How can I avoid that?

6 Answers 6

Run service nginx reload or /etc/init.d/nginx reload

It will do a hot reload of the configuration without downtime. If you have pending requests, then there will be lingering nginx processes that will handle those connections before it dies, so it’s an extremely graceful way to reload configs.

Sometimes you may want to prepend with sudo

Run /usr/sbin/nginx -s reload

No, you are incorrect, you aren’t supposed to be facing any downtime with the procedure you describe. (Nginx can do not only configuration reload on the fly without any downtime, but even the upgrade of the executable on the fly, still without any downtime.)

As per http://nginx.org/docs/control.html#reconfiguration, sending the HUP signal to nginx makes sure that it performs a graceful restart, and, if the configuration files are incorrect, the whole procedure is abandoned, and you’re left with the nginx as before sending the HUP signal. At no point should any downtime be possible.

In order for nginx to re-read the configuration file, a HUP signal should be sent to the master process. The master process first checks the syntax validity, then tries to apply new configuration, that is, to open log files and new listen sockets. If this fails, it rolls back changes and continues to work with old configuration.

Nginx and Signals

The kill approach you used ( kill -s HUP $(cat /var/run/nginx.pid ) is correct. Init scripts for RH or Debian distributions are in the end also implemented using kill command. You can check Init example from nginx website or contents of Ubuntu Nginx package.

There are multiple signals, that nginx can listen to (mentioned in wiki):

• TERM , INT — Quick shutdown.
• QUIT — Graceful shutdown.
• KILL — Halts a stubborn process.
• HUP — Configuration reload. Start the new worker processes with a new configuration. Gracefully shutdown the old worker processes.
• USR1 — Reopen the log files.
• USR2 — Upgrade Executable on the fly.
• WINCH — Gracefully shutdown the worker processes.

Nginx Reload

Nginx reload ( HUP signal) is more specifically implemented as several steps [1,2]:

• The master process checks the syntax validity.
• Applies new configuration, that is, to open log files and new listen sockets.
• If this fails, it rolls back changes and continues to work with old configuration.
• If this succeeds, it starts new worker processes, and sends messages to old worker processes requesting them to shut down gracefully.
• Old worker processes close listen sockets and continue to service old clients.
• After all clients are serviced, old worker processes are shut down.

Only one issue I can think of why you had downtime (based on the reload process) is that you were using only one worker process ( worker_processes directive), which by design was serving old clients, but had closed listen socket, therefore you couldn’t open new connection.

I can also recommend you to always use /usr/sbin/nginx -t to validate configuration files before applying new config.

Nginx Reload in Depth

Reconfigure signal is handled in file ngx_process_cycle.c and we can see it starts new worker processes in function ngx_start_worker_processes(. ) and at the end it stops old worker processes in function ngx_signal_worker_processes(. ) , which iterates over them with NGX_SHUTDOWN_SIGNAL signal.

Источник