nginx pid что это

Управление nginx

TERM, INT	быстрое завершение
QUIT	плавное завершение
HUP	изменение конфигурации, обновление изменившейся временной зоны (только для FreeBSD и Linux), запуск новых рабочих процессов с новой конфигурацией, плавное завершение старых рабочих процессов
USR1	переоткрытие лог-файлов
USR2	обновление исполняемого файла
WINCH	плавное завершение рабочих процессов

Управлять рабочими процессами по отдельности не нужно. Тем не менее, они тоже поддерживают некоторые сигналы:

TERM, INT	быстрое завершение
QUIT	плавное завершение
USR1	переоткрытие лог-файлов
WINCH	аварийное завершение для отладки (требует включения debug_points)

Изменение конфигурации

Для того чтобы nginx перечитал файл конфигурации, нужно послать главному процессу сигнал HUP. Главный процесс сначала проверяет синтаксическую правильность конфигурации, а затем пытается применить новую конфигурацию, то есть, открыть лог-файлы и новые listen сокеты. Если ему это не удаётся, то он откатывает изменения и продолжает работать со старой конфигурацией. Если же удаётся, то он запускает новые рабочие процессы, а старым шлёт сообщение о плавном выходе. Старые рабочие процессы закрывают listen сокеты и продолжают обслуживать старых клиентов. После обслуживания всех клиентов старые рабочие процессы завершаются.

Предположим, на FreeBSD команда

показывает примерно такую картину:

Если послать сигнал HUP главному процессу, то картина может быть такой:

Один старый рабочий процесс 33129 всё ещё продолжает работать. По истечении некоторого времени он завершается:

Ротация лог-файлов

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

Обновление исполняемого файла на лету

Теперь все рабочие процессы наравне принимают запросы. Если послать сигнал WINCH первому главному процессу, то он пошлёт своим рабочим процессам сообщение о плавном выходе, и они будут постепенно выходить:

По истечении времени запросы будут обрабатывать только новые рабочие процессы:

Нужно заметить, что старый процесс не закрывает свои listen сокеты и при необходимости ему можно сказать, чтобы он снова запустил свои рабочие процессы. Если работа нового исполняемого файла по каким-то причинам не устраивает, можно проделать одно из следующих действий:

Послать старому главному процессу сигнал HUP. Старый главный процесс, не перечитывая конфигурации, запустит новые рабочие процессы. После этого можно плавно завершить все новые процессы, послав новому главному процессу сигнал QUIT.

Послать новому главному процессу сигнал TERM. В ответ на это он пошлёт сообщение о немедленном выходе своим рабочим процессам, и все они практически сразу же завершатся. (Если новые процессы по каким-то причинам не завершаются, нужно послать им сигнал KILL, который заставит их завершиться.) По завершению нового главного процесса старый главный процесс автоматически запустит новые рабочие процессы.

Если же обновление прошло удачно, то старому процессу нужно послать сигнал QUIT, и останутся только новые процессы:

Источник

Журналирование и ротация логов Nginx на сервере Ubuntu

Вовремя настроенное журналирование позволяет в дальнейшем избежать неожиданных проблем с веб-сервером. Информация, хранящаяся в логах (или журналах) сервера, помогает быстро оценить ситуацию и устранить ошибки.

Данное руководство знакомит с возможностями журналирования Nginx и предназначенными для этого инструментами.

Примечание: данное руководство предназначено для Ubuntu 12.04, но любой современный дистрибутив будет работать аналогичным образом.

Директива error_log

Для управления логами веб-сервер Nginx использует несколько специальных директив. Одна из основных директив – error_log.

Синтаксис error_log

Директива error_log используется для обработки общих сообщений об ошибках. В целом она очень похожа на директиву ErrorLog веб-сервера Apache.

Директива error_log имеет следующий синтаксис:

error_log log_file [ log_level ]

В примере log_file указывает файл, в который будут записываться данные, а log_level задаёт самый низкий уровень логирования.

Уровни логирования

Директиву error_log можно настроить для логирования определённого количества информации. Существуют следующие уровни логирования:

Чем выше уровень находится в этом списке, тем выше его приоритет. Логи фиксируют указанный уровень логирования, а также все уровни с более высоким приоритетом. К примеру, если выбрать уровень error, логи будут фиксировать уровни error, crit, alert и emerg.

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

Чтобы директива error_log не фиксировала никаких данных, отправьте её вывод в /dev/null.

error_log /dev/null crit;

Директивы HttpLogModule

Директива error_log ходит в основной модуль, а access_log (следующая директива, которую стоит рассмотреть) входит в модуль HttpLogModule, который предоставляет возможность настраивать логи.

В этот модуль также включено несколько других директив, помогающих настраивать пользовательские логи.

Директива log_format

Директива log_format описывает формат записи лога при помощи простого текста и переменных.

Формат, который использует Nginx, называется комбинированным. Этот общий формат используется многими серверами. Он имеет следующий вид:

Определение этой директивы охватывает несколько строк и заканчивается точкой с запятой (;).

Общий синтаксис команды:

log_format format_name string_describing_formatting;

Директива access_log

Синтаксис директивы access_log похож на синтаксис error_log, но он более гибок. Та директива используется для настройки пользовательских логов.

access_log /path/to/log/location [ format_of_log buffer_size ];

Стандартным форматом директивы access_log является combined (как и в log_format). Можно использовать любой формат, определённый в log_format.

Фрагмент команды buffer_size задаёт максимальный объём данных, которые хранит сервер Nginx, прежде чем внести их в лог. Чтобы настроить сжатие лог-файла, нужно добавить в директиву gzip:

access_log location format gzip;

В отличие от error_log, директиву access_log можно просто выключить:

Её вывод не обязательно переводить в /dev/null.

Ротация логов

Во избежание заполнения дискового пространства необходимо использовать механизмы логирования по мере роста лог-файлов. Ротация логов – это процесс, подразумевающий отключение устаревших или слишком объёмных лог-файлов и их архивирование (на установленный период времени).

Сервер Nginx не предоставляет инструментов для управления лог-файлами, но позволяет использовать механизмы, упрощающие ротацию логов.

Ротация логов вручную

Чтобы запустить ротацию логов вручную (или же создать скрипт для запуска ротации), выполните команды:

То есть сначала нужно переместить текущий лог в новый файл для хранения. В имени нового лог-файла принято использовать суффикс 0, в имени более старого – суффикс 1, и т.д.

Команда, выполняющая ротацию логов:

На самом деле она не останавливает процесс Nginx, а отправляет ему сигнал, перезагружающий лог-файлы. Следовательно, новые запросы попадут в обновлённый лог-файл.

В файле /var/run/nginx.pid веб-сервер хранит pid главного процесса. Этот файл указывается в конфигурационном файле в строке, которая начинается с pid:

После выполнения ротации нужно запустить команду:

Эта команда позволяет процессу завершить переход. После этого можно заархивировать старый лог-файл.

Утилита logrotate

logrotate – это простая программа для ротации логов. Её можно найти в репозитории Ubuntu. Кроме того, Nginx поставляется в Ubuntu с пользовательским скриптом logrotate.

Чтобы просмотреть скрипт, введите:

sudo nano /etc/logrotate.d/nginx

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

Остальные строки файла будут выполнять ежедневную ротацию заданного файла, а также хранить 52 устаревшие его копии. К сожалению, данное руководство не охватывает общие настройки logrotate.

Как видите, раздел postrotate содержит команду, которая похожа на ту, что была использована при ручной ротации логов:

Этот раздел перезагружает лог-файлы Nginx после выполнения ротации.

Заключение

Конечно, это руководство охватывает только основы логирования.

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

Также очень важно следить за логами сервера, чтобы случайно не подвергнуть опасности конфиденциальную информацию.

Источник

Руководство для начинающих

В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.

У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).

Запуск, остановка, перезагрузка конфигурации

Где сигнал может быть одним из нижеследующих:

Например, чтобы остановить процессы nginx с ожиданием окончания обслуживания текущих запросов рабочими процессами, можно выполнить следующую команду:

Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.

Изменения, сделанные в конфигурационном файле, не будут применены, пока команда перезагрузить конфигурацию не будет вручную отправлена nginx’у или он не будет перезапущен. Для перезагрузки конфигурации выполните:

Получив сигнал, главный процесс проверяет правильность синтаксиса нового конфигурационного файла и пытается применить конфигурацию, содержащуюся в нём. Если это ему удаётся, главный процесс запускает новые рабочие процессы и отправляет сообщения старым рабочим процессам с требованием завершиться. В противном случае, главный процесс откатывает изменения и продолжает работать со старой конфигурацией. Старые рабочие процессы, получив команду завершиться, прекращают принимать новые запросы и продолжают обслуживать текущие запросы до тех пор, пока все такие запросы не будут обслужены. После этого старые рабочие процессы завершаются.

Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.

Структура конфигурационного файла

nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой ( ; ). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( < и >). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).

Часть строки после символа # считается комментарием.

Раздача статического содержимого

Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.

В блок server добавьте блок location следующего вида:

Далее, добавьте второй блок location :

Он будет давать совпадение с запросами, начинающимися с /images/ ( location / для них тоже подходит, но указанный там префикс короче).

Итоговая конфигурация блока server должна выглядеть следующим образом:

Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:

Настройка простого прокси-сервера

Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.

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

Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:

Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080 ):

Итоговая конфигурация прокси-сервера выглядит следующим образом:

Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.

Существует множество других директив для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.

Источник

Основная функциональность

Пример конфигурации

Директивы

Если accept_mutex включён, рабочие процессы будут принимать новые соединения по очереди. В противном случае о новых соединениях будет сообщаться сразу всем рабочим процессам, и при низкой интенсивности поступления новых соединений часть рабочих процессов может работать вхолостую.

Нет необходимости включать accept_mutex на системах, поддерживающих флаг EPOLLEXCLUSIVE (1.11.3), или при использовании reuseport.

При включённом accept_mutex задаёт максимальное время, в течение которого рабочий процесс вновь попытается начать принимать новые соединения, если в настоящий момент новые соединения принимает другой рабочий процесс.

Определяет, будет ли nginx запускаться в режиме демона. Используется в основном для разработки.

Включает отладочный лог для отдельных клиентских соединений. Для остальных соединений используется уровень лога, заданный директивой error_log. Отлаживаемые соединения задаются IPv4 или IPv6 (1.3.0, 1.2.1) адресом или сетью. Соединение может быть также задано при помощи имени хоста. Отладочный лог для соединений через UNIX-сокеты (1.3.0, 1.2.1) включается параметром “ unix: ”.

Эта директива используется для отладки.

В случае обнаружения внутренней ошибки, например, утечки сокетов в момент перезапуска рабочих процессов, включение debug_points приводит к созданию core-файла ( abort ) или остановке процесса ( stop ) с целью последующей диагностики с помощью системного отладчика.

По умолчанию nginx удаляет все переменные окружения, унаследованные от своего родительского процесса, кроме переменной TZ. Эта директива позволяет сохранить часть унаследованных переменных, поменять им значения или же создать новые переменные окружения. Эти переменные затем:

Если переменная TZ не описана явно, то она всегда наследуется и всегда доступна модулю ngx_http_perl_module.

Переменная окружения NGINX используется для внутренних целей nginx и не должна устанавливаться непосредственно самим пользователем.

Конфигурирует запись в лог. На одном уровне конфигурации может использоваться несколько логов (1.5.2). Если на уровне конфигурации main запись лога в файл явно не задана, то используется файл по умолчанию.

Директива может быть указана на уровне stream начиная с версии 1.7.11 и на уровне mail начиная с версии 1.9.0.

Предоставляет контекст конфигурационного файла, в котором указываются директивы, влияющие на обработку соединений.

Включает в конфигурацию другой файл или файлы, подходящие под заданную маску. Включаемые файлы должны содержать синтаксически верные директивы и блоки.

Эта директива появилась в версии 1.9.11.

Загружает динамический модуль.

Для реализации accept_mutex и сериализации доступа к разделяемой памяти nginx использует механизм блокировок. На большинстве систем блокировки реализованы с помощью атомарных операций, и эта директива игнорируется. Для остальных систем применяется механизм файлов блокировок. Эта директива задаёт префикс имён файлов блокировок.

Определяет, будут ли запускаться рабочие процессы. Эта директива предназначена для разработчиков nginx.

Если multi_accept выключен, рабочий процесс за один раз будет принимать только одно новое соединение. В противном случае рабочий процесс за один раз будет принимать сразу все новые соединения.

Директива игнорируется в случае использования метода обработки соединений kqueue, т.к. данный метод сам сообщает число новых соединений, ожидающих приёма.

Эта директива появилась в версии 1.1.12.

Разрешает или запрещает использование JIT-компиляции (PCRE JIT) для регулярных выражений, известных на момент парсинга конфигурации.

Использование PCRE JIT способно существенно ускорить обработку регулярных выражений.

Задаёт название аппаратного SSL-акселератора.

Эта директива появилась в версии 1.7.11.

Задаёт имя и параметры пула потоков, используемого для многопоточной обработки операций чтения и отправки файлов без блокирования рабочего процесса.

Параметр threads задаёт число потоков в пуле.

Если все потоки из пула заняты выполнением заданий, новое задание будет ожидать своего выполнения в очереди. Параметр max_queue ограничивает число заданий, ожидающих своего выполнения в очереди. По умолчанию в очереди может находиться до 65536 заданий. При переполнении очереди задание завершается с ошибкой.

Внутренняя реализация интервала зависит от используемого метода:

Задаёт пользователя и группу, с правами которого будут работать рабочие процессы. Если группа не задана, то используется группа, имя которой совпадает с именем пользователя.

Эта директива появилась в версиях 1.1.4 и 1.0.7.

При использовании aio совместно с методом обработки соединений epoll, задаёт максимальное число ожидающих обработки операций асинхронного ввода-вывода для одного рабочего процесса.

Задаёт максимальное число соединений, которые одновременно может открыть рабочий процесс.

Следует иметь в виду, что в это число входят все соединения (в том числе, например, соединения с проксируемыми серверами), а не только соединения с клиентами. Стоит также учитывать, что фактическое число одновременных соединений не может превышать действующего ограничения на максимальное число открытых файлов, которое можно изменить с помощью worker_rlimit_nofile.

Привязывает рабочие процессы к группам процессоров. Каждая группа процессоров задаётся битовой маской разрешённых к использованию процессоров. Для каждого рабочего процесса должна быть задана отдельная группа. По умолчанию рабочие процессы не привязаны к конкретным процессорам.

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

привязывает первый рабочий процесс к CPU0/CPU2, а второй — к CPU1/CPU3. Второй пример пригоден для hyper-threading.

Специальное значение auto (1.9.10) позволяет автоматически привязать рабочие процессы к доступным процессорам:

С помощью необязательной маски можно ограничить процессоры, доступные для автоматической привязки:

Директива доступна только на FreeBSD и Linux.

Задаёт число рабочих процессов.

Оптимальное значение зависит от множества факторов, включая (но не ограничиваясь ими) число процессорных ядер, число жёстких дисков с данными и картину нагрузок. Если затрудняетесь в выборе правильного значения, можно начать с установки его равным числу процессорных ядер (значение “ auto ” пытается определить его автоматически).

Параметр auto поддерживается только начиная с версий 1.3.8 и 1.2.5.

Изменяет ограничение на наибольший размер core-файла ( RLIMIT_CORE ) для рабочих процессов. Используется для увеличения ограничения без перезапуска главного процесса.

Изменяет ограничение на максимальное число открытых файлов ( RLIMIT_NOFILE ) для рабочих процессов. Используется для увеличения ограничения без перезапуска главного процесса.

Эта директива появилась в версии 1.11.11.

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

Задаёт каталог, который будет текущим для рабочего процесса. Основное применение — запись core-файла, в этом случае рабочий процесс должен иметь права на запись в этот каталог.

Источник