Nginx error log signal process started

Русские Блоги

Несколько распространенных решений ошибок в журнале nginx error.log

В nginx.conf будет два журнала, разделенных на access.log и error.log. Эти два журнала могут быть уточнены.В общем случае журнал будет сохранен в каталоге nginx, а затем вы также можете установить access.log и error.log в соответствующем каталоге сервера, чтобы понять ситуацию на соответствующем сервере. .

access.log в основном записывает «кто вошел в систему, где вошел в систему и что произошло после входа в систему». Конкретный формат можно установить в nginx.conf.

Error.log в основном записывает ошибки, обнаруженные при проверке nginx.conf. Этот режим не поддерживает настройку. В отличие от access.log, который часто заканчивается на main, конец после error.log может быть теплым или критическим, где теплый или критический представляет уровень ошибки, критический — наименьший, а отладка — наиболее подробную запись, а пердеть — больше Запишите все.

error_log off не отключает функцию ведения журнала. Он записывает файл журнала в файл с именем off. Если вы хотите отключить функцию ведения журнала ошибок, вы должны использовать следующую конфигурацию: error_log / dev / null crit; (укажите место хранения Зайдите в черную дыру Linux).

При открытии error.log вы можете увидеть различное содержимое, например:

Это предложение означает, что есть ошибка в строке 87 файла nginx.conf. Проверьте, не является ли она избыточной, или; если она отсутствует, уровень этой ошибки является аварийным;

Это предложение означает, что настройка root в строке 86 nginx.conf повторяется, и уровень также является аварийным. Оба вышеперечисленных являются проблемами с записью и их легко исправить;

Это означает, что nginx уже выполняется и запускается, это не фатальная ошибка;

Это означает, что текущий пользователь не имеет разрешения на запись в журнал error.log. Решение состоит в том, чтобы иметь разрешение;

Nginx сообщает, что файл nginx.pid не может быть найден, используйте#/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf, Перезагрузите его, автоматически сгенерируется файл pid.

Вот несколько особенно характерных ошибок:

1) рабочий процесс XX завершился по сигналу 11 (ядро выгружено)
Этот вид ошибки возникает в основном при сканировании экрана error.log, и даже если он серьезный, nginx вылетает напрямую. Конкретная производительность со стороны пользователя: «видео нельзя открыть, веб-страницу нельзя открыть и т. Д.»

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

Как изменить, проверьте модуль «secure_download_fail_location;» в разделе антипиявочной ссылки в nginx.conf, то есть модуль «направлять на страницу с ошибкой, когда запрос неверен», и убедитесь, что местоположение направлено на правильный адрес как страницу с ошибкой.

2）nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)

Nginx сначала контролировал 80-й порт ipv4, а затем 80-й порт ipv6, поэтому он неоднократно был занят.

3) rewrite or internal redirection cycle while internally redirecting to «/ie.html», client: 127.0.0.1, server: localhost, request: «GET / HTTP/1.1», host: «203.46.90.146»

Эта ошибка обычно означает, что перенаправление перезаписи входит в бесконечный цикл. В случае клиента ошибка 500 возникает при входе в localhost / ie.html. Чтобы решить эту проблему, вам нужно, чтобы vim проверил файл конфигурации nginx.conf и нашел ie.html. Нашел эта строчка написана так:

Вернитесь в / usr / local / nginx / html и обнаружите, что ie.html действительно существует и формат правильный.

Проблема заключается в абзаце оператора if. Когда пользователь IE обнаруживает, что используемый браузер является IE, он войдет в интерфейс /ie.html. Однако при входе в /ie.html сначала будет определена модель браузера, и окажется, что это IE. Меня снова отправили войти в /ie.html, а затем, когда я вошел в /ie.html, мне пришлось снова определять модель браузера, и она повторялась бесконечно, так что в итоге это было 500, внутренняя ошибка сервера.

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

4) open () «какой-то URL» не удалось (24: слишком много открытых файлов), клиент: XX, сервер: XX .

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

ulimit -n 20000, по умолчанию это значение 1024, теперь оно увеличено до 20000.

В error.log Nginx может быть ошибка 499. Существует две возможности для этой ошибки. Первая заключается в том, что клиент активно отключает ссылку; вторая — в том, что два сообщения находятся слишком близко. Nginx считает такую ​​быструю отправку сообщений небезопасной. Да, сервер активно отказывался от ссылки.

Чтобы решить эту ошибку, нужно добавить предложение в глобальную конфигурацию nginx.conf:

Это означает, что сервер активно не закрывает ссылку на клиента. Если вы сделаете это, безопасность однозначно снизится, но это лучше, чем искать сервер.

Интеллектуальная рекомендация

Реализация оценки приложения iOS

Есть два способа получить оценку приложения: перейти в App Store для оценки и оценка в приложении. 1. Перейдите в App Store, чтобы оценить ps: appid можно запросить в iTunes Connect 2. Встроенная оцен.

JS функциональное программирование (е)

Давайте рассмотрим простой пример, чтобы проиллюстрировать, как используется Reduce. Первый параметр Reduce — это то, что мы принимаем массив arrayOfNums, а второй параметр — функцию. Эта функция прин.

PWN_JarvisOJ_Level1

Nc первый Затем мы смотрим на декомпиляцию ida Перед «Hello, World! N» есть уязвимая_функция, проверьте эту функцию после ввода Видно, что только что появившийся странный адрес является пе.

Установка и развертывание Kubernetes

На самом деле, я опубликовал статью в этом разделе давным -давно, но она не достаточно подробно, и уровень не является ясным. Когда я развернулся сегодня, я увидел его достаточно (хотя это было успешн.

На стороне многопроцессорного сервера — (2) *

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

Источник

Nginx падает ежедневно, а error.log ничего не показывает

У меня есть сервер nginx, настроенный как обратный прокси, который, кажется, ежедневно дает сбой. Раньше никогда не было проблем с сервером, но недавно (месяц или около того) я начал замечать, что nginx не работает, и мне придется войти на сервер, чтобы снова запустить процесс.

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

Версия nginx: nginx / 1.10.3 (Ubuntu)

ОС: Ubuntu 16.04.4 LTS (работает в LXC)

В файле access.log ничего подозрительного не было.

Сообщите мне, если есть дополнительная информация, которая будет полезна

Похоже, решение проблемы было найдено в /var/log/syslog . certbot отключал сервер nginx, чтобы попытаться обновить сертификаты, но из-за некоторых проблем с конфигурацией (моя ошибка) он не смог бы снова включить сервер nginx.

У меня была та же проблема, и это был тот же источник ошибки: certbot отключал сервер nginx и не мог запустить его снова после обновления.

ПРОБЛЕМА:

Вы можете проверить, не столкнулись ли вы с той же проблемой, проверив следующие журналы. Первые логи nginx:

tail -n 100 /var/log/nginx/error.log

Мы видим, что nginx безуспешно пытается перезапустить.

Вы также можете проверить системный журнал:

tail -n 100 /var/log/syslog

И ищите ту же метку времени:

Мы видим, что проблема, по всей видимости, вызывает certbot.

РЕШЕНИЕ:

В моем случае у меня была старая версия certbot. Вы можете проверить свою версию с помощью команды certbot —version . В моем случае у меня был certbot 0.10.2 .

Итак, в первую очередь обновите приложение certbot и добавьте плагин nginx:

Проверьте свою новую версию: certbot —version -> certbot 0.28.0 .

Затем вам нужно будет изменить файлы конфигурации обновления в соответствии с новой версией и использовать плагин nginx. Файл конфигурации обновления находится в каталоге /etc/letsencrypt/renewal/* . Обратите внимание, что документация по certbot не рекомендует вам изменять их вручную. .

Я изменяю все файлы конфигурации обновления из:

(обратите внимание, что были изменены только строки версия и аутентификатор, строка сервер была добавлена, а строки pre_hook и post_hook были удалены).

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

Вы должны получить следующее для каждого сертификата, без красной ошибки:

Источник

Почему nginx не подает признаков жизни?

Здравствуйте проблема такова.
Нужно поставить nginx с rtmp модулем. Делаю по гайду с хабра. Но доходя до шага проверка работы nginx и ввода команды sudo service nginx start — ничего не происходит вообще! Счастливого приветствия nginx на 127.0.0.1 не наблюдаю. В линуксе новичок, поэтому прошу помочь с данным вопросом. В /var/log/nginx/error.log получаю следующее:

2015/05/31 23:07:12 [notice] 14848#0: signal process started
2015/05/31 23:07:12 [error] 14848#0: open() «/var/run/nginx.pid» failed (2: No such file or directory)

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

14.04.1-Ubuntu SMP Thu$
May 31 13:03:45 ubuntu kernel: [ 0.000000] KERNEL supported cpus:
May 31 13:03:45 ubuntu kernel: [ 0.000000] Intel GenuineIntel
May 31 13:03:45 ubuntu kernel: [ 0.000000] AMD AuthenticAMD
May 31 13:03:45 ubuntu kernel: [ 0.000000] NSC Geode by NSC
May 31 13:03:45 ubuntu kernel: [ 0.000000] Cyrix CyrixInstead
May 31 13:03:45 ubuntu kernel: [ 0.000000] Centaur CentaurHauls
May 31 13:03:45 ubuntu kernel: [ 0.000000] Transmeta GenuineTMx86
May 31 13:03:45 ubuntu kernel: [ 0.000000] Transmeta TransmetaCPU
May 31 13:03:45 ubuntu kernel: [ 0.000000] UMC UMC UMC UMC
May 31 13:03:45 ubuntu kernel: [ 0.000000] e820: BIOS-provided physical RAM map:
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001ffeffff] usable
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x000000001fff0000-0x000000001fff2fff] ACPI NVS
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x000000001fff3000-0x000000001fffffff] ACPI data
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
May 31 13:03:45 ubuntu kernel: [ 0.000000] BIOS-e820: [mem 0x00000000ffff0000-0x00000000ffffffff] reserved
May 31 13:03:45 ubuntu kernel: [ 0.000000] Notice: NX (Execute Disable) protection missing in CPU!
May 31 13:03:45 ubuntu kernel: [ 0.000000] SMBIOS 2.2 present.
May 31 13:03:45 ubuntu kernel: [ 0.000000] DMI: /nVidia-nForce, BIOS 6.00 PG 10/17/2003
May 31 13:03:45 ubuntu kernel: [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
May 31 13:03:45 ubuntu kernel: [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
May 31 13:03:45 ubuntu kernel: [ 0.000000] e820: last_pfn = 0x1fff0 max_arch_pfn = 0x1000000
May 31 13:03:45 ubuntu kernel: [ 0.000000] MTRR default type: uncachable
May 31 13:03:45 ubuntu kernel: [ 0.000000] MTRR fixed ranges enabled:
May 31 13:03:45 ubuntu kernel: [ 0.000000] 00000-9FFFF write-back
May 31 13:03:45 ubuntu kernel: [ 0.000000] A0000-BFFFF uncachable
May 31 13:03:45 ubuntu kernel: [ 0.000000] C0000-C7FFF write-protect
May 31 13:03:45 ubuntu kernel: [ 0.000000] C8000-FFFFF uncachable
May 31 13:03:45 ubuntu kernel: [ 0.000000] MTRR variable ranges enabled:

Источник

Beginner’s Guide

This guide gives a basic introduction to nginx and describes some simple tasks that can be done with it. It is supposed that nginx is already installed on the reader’s machine. If it is not, see the Installing nginx page. This guide describes how to start and stop nginx, and reload its configuration, explains the structure of the configuration file and describes how to set up nginx to serve out static content, how to configure nginx as a proxy server, and how to connect it with a FastCGI application.

nginx has one master process and several worker processes. The main purpose of the master process is to read and evaluate configuration, and maintain worker processes. Worker processes do actual processing of requests. nginx employs event-based model and OS-dependent mechanisms to efficiently distribute requests among worker processes. The number of worker processes is defined in the configuration file and may be fixed for a given configuration or automatically adjusted to the number of available CPU cores (see worker_processes).

The way nginx and its modules work is determined in the configuration file. By default, the configuration file is named nginx.conf and placed in the directory /usr/local/nginx/conf , /etc/nginx , or /usr/local/etc/nginx .

Starting, Stopping, and Reloading Configuration

To start nginx, run the executable file. Once nginx is started, it can be controlled by invoking the executable with the -s parameter. Use the following syntax:

Where signal may be one of the following:

• stop — fast shutdown
• quit — graceful shutdown
• reload — reloading the configuration file
• reopen — reopening the log files

For example, to stop nginx processes with waiting for the worker processes to finish serving current requests, the following command can be executed:

This command should be executed under the same user that started nginx.

Changes made in the configuration file will not be applied until the command to reload configuration is sent to nginx or it is restarted. To reload configuration, execute:

Once the master process receives the signal to reload configuration, it checks the syntax validity of the new configuration file and tries to apply the configuration provided in it. If this is a success, the master process starts new worker processes and sends messages to old worker processes, requesting them to shut down. Otherwise, the master process rolls back the changes and continues to work with the old configuration. Old worker processes, receiving a command to shut down, stop accepting new connections and continue to service current requests until all such requests are serviced. After that, the old worker processes exit.

A signal may also be sent to nginx processes with the help of Unix tools such as the kill utility. In this case a signal is sent directly to a process with a given process ID. The process ID of the nginx master process is written, by default, to the nginx.pid in the directory /usr/local/nginx/logs or /var/run . For example, if the master process ID is 1628, to send the QUIT signal resulting in nginx’s graceful shutdown, execute:

For getting the list of all running nginx processes, the ps utility may be used, for example, in the following way:

For more information on sending signals to nginx, see Controlling nginx.

Configuration File’s Structure

nginx consists of modules which are controlled by directives specified in the configuration file. Directives are divided into simple directives and block directives. A simple directive consists of the name and parameters separated by spaces and ends with a semicolon ( ; ). A block directive has the same structure as a simple directive, but instead of the semicolon it ends with a set of additional instructions surrounded by braces ( < and >). If a block directive can have other directives inside braces, it is called a context (examples: events, http, server, and location).

Directives placed in the configuration file outside of any contexts are considered to be in the main context. The events and http directives reside in the main context, server in http , and location in server .

The rest of a line after the # sign is considered a comment.

Serving Static Content

An important web server task is serving out files (such as images or static HTML pages). You will implement an example where, depending on the request, files will be served from different local directories: /data/www (which may contain HTML files) and /data/images (containing images). This will require editing of the configuration file and setting up of a server block inside the http block with two location blocks.

First, create the /data/www directory and put an index.html file with any text content into it and create the /data/images directory and place some images in it.

Next, open the configuration file. The default configuration file already includes several examples of the server block, mostly commented out. For now comment out all such blocks and start a new server block:

Generally, the configuration file may include several server blocks distinguished by ports on which they listen to and by server names. Once nginx decides which server processes a request, it tests the URI specified in the request’s header against the parameters of the location directives defined inside the server block.

Add the following location block to the server block:

This location block specifies the “ / ” prefix compared with the URI from the request. For matching requests, the URI will be added to the path specified in the root directive, that is, to /data/www , to form the path to the requested file on the local file system. If there are several matching location blocks nginx selects the one with the longest prefix. The location block above provides the shortest prefix, of length one, and so only if all other location blocks fail to provide a match, this block will be used.

Next, add the second location block:

It will be a match for requests starting with /images/ ( location / also matches such requests, but has shorter prefix).

The resulting configuration of the server block should look like this:

This is already a working configuration of a server that listens on the standard port 80 and is accessible on the local machine at http://localhost/ . In response to requests with URIs starting with /images/ , the server will send files from the /data/images directory. For example, in response to the http://localhost/images/example.png request nginx will send the /data/images/example.png file. If such file does not exist, nginx will send a response indicating the 404 error. Requests with URIs not starting with /images/ will be mapped onto the /data/www directory. For example, in response to the http://localhost/some/example.html request nginx will send the /data/www/some/example.html file.

To apply the new configuration, start nginx if it is not yet started or send the reload signal to the nginx’s master process, by executing:

In case something does not work as expected, you may try to find out the reason in access.log and error.log files in the directory /usr/local/nginx/logs or /var/log/nginx .

Setting Up a Simple Proxy Server

One of the frequent uses of nginx is setting it up as a proxy server, which means a server that receives requests, passes them to the proxied servers, retrieves responses from them, and sends them to the clients.

We will configure a basic proxy server, which serves requests of images with files from the local directory and sends all other requests to a proxied server. In this example, both servers will be defined on a single nginx instance.

First, define the proxied server by adding one more server block to the nginx’s configuration file with the following contents:

This will be a simple server that listens on the port 8080 (previously, the listen directive has not been specified since the standard port 80 was used) and maps all requests to the /data/up1 directory on the local file system. Create this directory and put the index.html file into it. Note that the root directive is placed in the server context. Such root directive is used when the location block selected for serving a request does not include its own root directive.

Next, use the server configuration from the previous section and modify it to make it a proxy server configuration. In the first location block, put the proxy_pass directive with the protocol, name and port of the proxied server specified in the parameter (in our case, it is http://localhost:8080 ):

We will modify the second location block, which currently maps requests with the /images/ prefix to the files under the /data/images directory, to make it match the requests of images with typical file extensions. The modified location block looks like this:

The parameter is a regular expression matching all URIs ending with .gif , .jpg , or .png . A regular expression should be preceded with

. The corresponding requests will be mapped to the /data/images directory.

When nginx selects a location block to serve a request it first checks location directives that specify prefixes, remembering location with the longest prefix, and then checks regular expressions. If there is a match with a regular expression, nginx picks this location or, otherwise, it picks the one remembered earlier.

The resulting configuration of a proxy server will look like this:

This server will filter requests ending with .gif , .jpg , or .png and map them to the /data/images directory (by adding URI to the root directive’s parameter) and pass all other requests to the proxied server configured above.

To apply new configuration, send the reload signal to nginx as described in the previous sections.

There are many more directives that may be used to further configure a proxy connection.

Setting Up FastCGI Proxying

nginx can be used to route requests to FastCGI servers which run applications built with various frameworks and programming languages such as PHP.

The most basic nginx configuration to work with a FastCGI server includes using the fastcgi_pass directive instead of the proxy_pass directive, and fastcgi_param directives to set parameters passed to a FastCGI server. Suppose the FastCGI server is accessible on localhost:9000 . Taking the proxy configuration from the previous section as a basis, replace the proxy_pass directive with the fastcgi_pass directive and change the parameter to localhost:9000 . In PHP, the SCRIPT_FILENAME parameter is used for determining the script name, and the QUERY_STRING parameter is used to pass request parameters. The resulting configuration would be:

This will set up a server that will route all requests except for requests for static images to the proxied server operating on localhost:9000 through the FastCGI protocol.

Источник

nginx can be controlled with signals.
The process ID of the master process is written to the file
/usr/local/nginx/logs/nginx.pid by default.
This name may be changed at configuration time, or in
nginx.conf using the
pid
directive.
The master process supports the following signals:

TERM, INT	fast shutdown
QUIT	graceful shutdown
HUP	changing configuration, keeping up with a changed time zone (only for FreeBSD and Linux), starting new worker processes with a new configuration, graceful shutdown of old worker processes
USR1	re-opening log files
USR2	upgrading an executable file
WINCH	graceful shutdown of worker processes

Individual worker processes can be controlled with signals as well,
though it is not required.
The supported signals are:

TERM, INT	fast shutdown
QUIT	graceful shutdown
USR1	re-opening log files
WINCH	abnormal termination for debugging (requires debug_points to be enabled)

Changing Configuration

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.
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.

Let’s illustrate this by example.
Imagine that nginx is run on FreeBSD and the command

ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'

produces the following output:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
33127 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
33128 33126 nobody   0.0  1364 kqread nginx: worker process (nginx)
33129 33126 nobody   0.0  1364 kqread nginx: worker process (nginx)

If HUP is sent to the master process, the output becomes:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33129 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)

One of the old worker processes with PID 33129 still continues to work.
After some time it exits:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)

Rotating Log-files

In order to rotate log files, they need to be renamed first.
After that USR1 signal should be sent to the master process.
The master process will then re-open all currently open log files and
assign them an unprivileged user under which the worker processes
are running, as an owner.
After successful re-opening, the master process closes all open files and
sends the message to worker process to ask them to re-open files.
Worker processes also open new files and close old files right away.
As a result, old files are almost immediately available for post
processing, such as compression.

Upgrading Executable on the Fly

In order to upgrade the server executable, the new executable file
should be put in place of an old file first.
After that USR2 signal should be sent to the master process.
The master process first renames its file with the process ID to a
new file with the .oldbin suffix, e.g.
/usr/local/nginx/logs/nginx.pid.oldbin,
then starts a new executable file that in turn starts new
worker processes:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

After that all worker processes (old and new ones) continue to accept requests.
If the WINCH signal is sent to the first master process, it will
send messages to its worker processes, requesting them to shut
down gracefully, and they will start to exit:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33135 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

After some time, only the new worker processes will process requests:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

It should be noted that the old master process does not close its listen
sockets, and it can be managed to start its worker processes again if needed.
If for some reason the new executable file works unacceptably, one of the
following can be done:

• Send the HUP signal to the old master process.
  The old master process will start new worker processes
  without re-reading the configuration.
  After that, all new processes can be shut down gracefully,
  by sending the QUIT signal to the new master process.

• Send the TERM signal to the new master process.
  It will then send a message to its worker processes requesting them
  to exit immediately, and they will all exit almost immediately.
  (If new processes do not exit for some reason,
  the KILL signal should be sent to them to force them to exit.)
  When the new master process exits, the old master process will start new
  worker processes automatically.

If the new master process exits then the old master process discards
the .oldbin suffix from the file name with the process ID.

If upgrade was successful, then the QUIT signal should be sent to
the old master process, and only new processes will stay:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
36264     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

У меня была та же проблема, и это был тот же источник ошибки: certbot отключал сервер nginx и не мог запустить его снова после обновления.

ПРОБЛЕМА:

Вы можете проверить, не столкнулись ли вы с той же проблемой, проверив следующие журналы. Первые логи nginx:

Tail -n 100 /var/log/nginx/error.log

Результат:

2019/02/05 12:07:37 [notice] 1629#1629: signal process started
2019/02/05 12:07:37 [error] 1629#1629: open() "/run/nginx.pid" failed (2: No such file or directory)
2019/02/05 12:07:38 [emerg] 1655#1655: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/02/05 12:07:38 [emerg] 1655#1655: bind() to 0.0.0.0:443 failed (98: Address already in use)
2019/02/05 12:07:38 [emerg] 1655#1655: bind() to [::]:443 failed (98: Address already in use)
2019/02/05 12:07:38 [emerg] 1655#1655: bind() to 0.0.0.0:444 failed (98: Address already in use)
2019/02/05 12:07:38 [emerg] 1655#1655: bind() to [::]:444 failed (98: Address already in use)
[...]
2019/02/05 12:07:38 [emerg] 1655#1655: still could not bind()
2019/02/05 12:07:41 [alert] 1631#1631: unlink() "/run/nginx.pid" failed (2: No such file or directory)

Мы видим, что nginx безуспешно пытается перезапустить.

Вы также можете проверить системный журнал:

Tail -n 100 /var/log/syslog

И ищите ту же метку времени:

Feb  5 12:07:30 systemd[1]: Starting Certbot...
Feb  5 12:07:31 systemd[1]: Stopping A high performance web server and a reverse proxy server...
Feb  5 12:07:31 systemd[1]: Stopped A high performance web server and a reverse proxy server.
Feb  5 12:07:38 systemd[1]: Starting A high performance web server and a reverse proxy server...

Мы видим, что проблема, по всей видимости, вызывает certbot.

РЕШЕНИЕ:

В моем случае у меня была старая версия certbot. Вы можете проверить свою версию с помощью команды certbot —version. В моем случае у меня был certbot 0.10.2 …

Итак, в первую очередь обновите приложение certbot и добавьте плагин nginx:

sudo apt-get update
sudo apt-get install certbot python-certbot-nginx

Проверьте свою новую версию: certbot —version -> certbot 0.28.0.

Затем вам нужно будет изменить файлы конфигурации обновления в соответствии с новой версией и использовать плагин nginx. Файл конфигурации обновления находится в каталоге /etc/letsencrypt/renewal/*. Обратите внимание, что документация по certbot не рекомендует вам изменять их вручную. …

Я изменяю все файлы конфигурации обновления из:

# renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/yourdomain
cert = /etc/letsencrypt/live/yourdomain/cert.pem
privkey = /etc/letsencrypt/live/yourdomain/privkey.pem
chain = /etc/letsencrypt/live/yourdomain/chain.pem
fullchain = /etc/letsencrypt/live/yourdomain/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = standalone
post_hook = service nginx start
account = yourkey
pre_hook = service nginx stop
installer = nginx

К:

# renew_before_expiry = 30 days
version = 0.28.0
archive_dir = /etc/letsencrypt/archive/yourdomain
cert = /etc/letsencrypt/live/yourdomain/cert.pem
privkey = /etc/letsencrypt/live/yourdomain/privkey.pem
chain = /etc/letsencrypt/live/yourdomain/chain.pem
fullchain = /etc/letsencrypt/live/yourdomain/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = yourkey
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = nginx
installer = nginx

(обратите внимание, что были изменены только строки версия и аутентификатор, строка сервер была добавлена, а строки pre_hook и post_hook были удалены).

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

certbot renew --dry-run

Вы должны получить следующее для каждого сертификата, без красной ошибки:

new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/yourdomain/fullchain.pem