DANFA

(104: Connection reset by peer) while reading response header from upstream

Я уже писал про эту ошибку в теме: 502 Bad Gateway -> [pool www] child 30723 exited on signal 7 (SIGBUS - core dumped) after 408.834692 seconds from start, плюс еще одна тема...
Сегодня опять получаю ошибку 502 Bad Gateway, открываю лог: "/var/www/httpd-logs/site.error.log" и вижу кучу ошибок:
2018/09/01 14:59:31 [error] 20197#20197: *233343 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xx.xxx.xxx.xxx, server: danfa.net, request: "GET /page/url/ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "danfa.net"

Лог начал заполнятся с сегодняшнего дня (первое сентября), до этого, с прошлого раза нет ни одной записи. Ни каких изменений в настройки сервера внесено не было.

Я пробовал добавить в "etc/nginx/nginx.conf" параметр:
fastcgi_read_timeout 300s;

И в файле: "etc/php/7.2/fpm/pool.d/www.conf", менял строку:
;request_terminate_timeout = 0

На:
request_terminate_timeout = 300

Это не помогло... Кроме этого, многое, что было найдено в интернете, тоже не помогло...

На всякий случай, моя конфигурация Nginx выглядит так:
user www-data;
worker_processes 2;

error_log /var/log/nginx/error.log warn;
pid       /var/run/nginx.pid;

events {
	worker_connections 4096;
}

http {
	include      /etc/nginx/mime.types;
	default_type application/octet-stream;

	log_format main '$remote_addr - $remote_user [$time_local] "$request" '
					'$status $body_bytes_sent "$http_referer" '
					'"$http_user_agent" "$http_x_forwarded_for"';

	access_log /var/log/nginx/access.log main;

	sendfile on;
	keepalive_timeout 65;

	reset_timedout_connection on;

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/vhosts/*/*.conf;

	client_body_buffer_size 8m;
	client_max_body_size    128m;

	server {
		server_name      localhost;
		disable_symlinks if_not_owner;

		include /etc/nginx/vhosts-includes/*.conf;

		location @fallback {
			error_log /dev/null crit;

			proxy_pass http://127.0.0.1:8080;
			proxy_redirect http://127.0.0.1:8080 /;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;

			access_log off ;
		}

		listen 80;
		listen [::]:80;
	}
}
Что в логе: "/var/log/php7.2-fpm.log"?

Для получения информации открыть: "/etc/php/7.2/fpm/php-fpm.conf", найти:
;log_level = notice

Заменить на:
log_level = debug
Лог до включения отладчика (то же самое: 502 Bad Gateway -> [pool www] child 30723 exited on signal 7 (SIGBUS - core dumped) after 408.834692 seconds from start):
[02-Sep-2018 06:29:42] WARNING: [pool www] child 2392 exited on signal 7 (SIGBUS - core dumped) after 392.810012 seconds from start
[02-Sep-2018 06:29:42] NOTICE: [pool www] child 2844 started

Записи лога с включенным дебагом:
[02-Sep-2018 15:08:52.312715] DEBUG: pid 1093, fpm_pctl_perform_idle_server_maintenance(), line 379: [pool www] currently 0 active children, 3 spare children, 3 running children. Spawning rate 1

Такие строчки плодятся с бешенной скоростью.

Протестировал Nginx (nginx -t), получил предупреждение:
[warn] 4096 worker_connections exceed open file resource limit: 1024

Сразу исправил:
	worker_connections 4096;

На:
	worker_connections 1024;
Значение worker_connections в конфиге Nginx на данный момент у меня 1024, такое же значение задал для listen.backlog (fpm) и net.core.somaxconn (sysctl). Еще поэкспериментировал с pm.max_children (fpm), остановился на 7. Поправил свой конфиг Nginx:
user www-data;
worker_processes 1;

error_log /var/log/nginx/error.log crit;
pid       /var/run/nginx.pid;

events {
	worker_connections 1024;
}

http {
	server_tokens off;

	include /etc/nginx/ip.conf;
	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	log_format main '$remote_addr - $remote_user [$time_local] "$request" '
					'$status $body_bytes_sent "$http_referer" '
					'"$http_user_agent" "$http_x_forwarded_for"';

	access_log /var/log/nginx/access.log main;

	sendfile   on;
	tcp_nopush on;

	keepalive_timeout 20;

	reset_timedout_connection on;

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/vhosts/*/*.conf;

	client_body_buffer_size 2m;
	client_max_body_size    4m;

	server {
		server_name      localhost;
		disable_symlinks if_not_owner;

		include /etc/nginx/vhosts-includes/*.conf;

		location @fallback {
			error_log /dev/null crit;

			proxy_pass http://127.0.0.1:8080;
			proxy_redirect http://127.0.0.1:8080 /;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;

			access_log off ;
		}

		listen 80;
		listen [::]:80;
	}
}

И со вчерашнего дня не было ни одной ошибки: recv() failed (104: Connection reset by peer) while reading response header from upstream, client. Возможно, я рано радуюсь, как это обычно бывает, и ошибка еще вылезет, но пока ее нет... Наблюдаю за новыми ошибками...
После перехода на PHP 7.3 ошибка: recv() failed (104: Connection reset by peer) while reading response header from upstream снова дала о себе знать, правки что выше, не помогли... За одни сутки, в логе можно найти до восьми записей, с данной ошибкой.

В интернете нашел совет: изменить значение fastcgi_read_timeout до 600 секунд:
	fastcgi_read_timeout 600s;
	# Задаёт таймаут при чтении ответа FastCGI-сервера.
	# Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями чтения.
	# Если по истечении этого времени FastCGI-сервер ничего не передаст, соединение закрывается.

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

Мой конфигnginx.conf ("etc/nginx/"):
user www-data;
worker_processes auto;
# Оптимальное значение зависит от множества факторов, включая (но не ограничиваясь ими) число процессорных ядер, число жёстких дисков с данными и картину нагрузок.
# Если затрудняетесь в выборе правильного значения, можно начать с установки его равным числу процессорных ядер (значение “auto” пытается определить его автоматически).

worker_priority -10;
# Задаёт приоритет планирования рабочих процессов подобно тому, как это делается командой nice: отрицательное число означает более высокий приоритет.
# Диапазон возможных значений, как правило, варьируется от -20 до 20.

error_log /var/log/nginx/error.log crit;
pid       /var/run/nginx.pid;

events {
	worker_connections 1024;
	# Задаёт максимальное число соединений, которые одновременно может открыть рабочий процесс.
	# Следует иметь в виду, что в это число входят все соединения (в том числе, например, соединения с проксируемыми серверами), а не только соединения с клиентами.
	# Стоит также учитывать, что фактическое число одновременных соединений не может превышать действующего ограничения на максимальное число открытых файлов, которое можно изменить с помощью worker_rlimit_nofile.

	multi_accept on;
	use epoll;
}

http {
	server_tokens off;
	# Разрешает или запрещает выдавать версию nginx’а на страницах ошибок и в поле “Server” заголовка ответа (on | off).

	reset_timedout_connection on;
	# Разрешает или запрещает сброс соединений по таймауту (on | off).
	# Сброс делается следующим образом. Перед закрытием сокета для него задаётся параметр SO_LINGER с таймаутом 0.
	# После этого при закрытии сокета клиенту отсылается TCP RST, а вся память, связанная с этим сокетом, освобождается.
	# Это позволяет избежать длительного нахождения уже закрытого сокета в состоянии FIN_WAIT1 с заполненными буферами.

	keepalive_timeout 60s;
	# Первый параметр задаёт таймаут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера.
	# Значение 0 запрещает keep-alive соединения с клиентами.
	# Второй необязательный параметр задаёт значение в поле “Keep-Alive: timeout=время” заголовка ответа. Два параметра могут отличаться друг от друга.

	sendfile on;
	# Разрешает или запрещает использовать sendfile() (on | off).

	tcp_nopush on;
	# Разрешает или запрещает использование параметра сокета TCP_NOPUSH во FreeBSD или TCP_CORK в Linux (on | off).
	# Параметр включаются только при использовании sendfile. Включение параметра позволяет:
	# - Передавать заголовок ответа и начало файла в одном пакете в Linux и во FreeBSD 4.*.
	# - Передавать файл полными пакетами.

	client_body_buffer_size 1m;
	# Задаёт размер буфера для чтения тела запроса клиента.
	# Если тело запроса больше заданного буфера, то всё тело запроса или только его часть записывается во временный файл.
	# По умолчанию размер одного буфера равен двум размерам страницы.
	# На x86, других 32-битных платформах и x86-64 это 8K. На других 64-битных платформах это обычно 16K.

	client_header_buffer_size 256k;
	# Задаёт размер буфера для чтения заголовка запроса клиента.
	# Для большинства запросов достаточно буфера размером в 1K байт.
	# Однако если в запросе есть длинные cookies, или же запрос пришёл от WAP-клиента, то он может не поместиться в 1K.
	# Поэтому, если строка запроса или поле заголовка запроса не помещаются полностью в этот буфер, то выделяются буферы большего размера, задаваемые директивой "large_client_header_buffers".

	client_max_body_size 12m;
	# Задаёт максимально допустимый размер тела запроса клиента, указываемый в поле “Content-Length” заголовка запроса.
	# Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).
	# Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку.
	# Установка параметра размер в 0 отключает проверку размера тела запроса клиента.

	fastcgi_buffers 12 1m;
	# Задаёт число и размер буферов для одного соединения, в которые будет читаться ответ, получаемый от FastCGI-сервера.
	# По умолчанию размер одного буфера равен размеру страницы.
	# В зависимости от платформы это или 4K, или 8K.

	fastcgi_buffer_size 1m;
	# Задаёт размер буфера, в который будет читаться первая часть ответа, получаемого от FastCGI-сервера.
	# В этой части ответа находится, как правило, небольшой заголовок ответа.
	# По умолчанию размер одного буфера равен размеру страницы памяти.
	# В зависимости от платформы это или 4K, или 8K, однако его можно сделать меньше.

	fastcgi_busy_buffers_size 1m;
	# При включённой буферизации ответов FastCGI-сервера, ограничивает суммарный размер буферов, которые могут быть заняты для отправки ответа клиенту, пока ответ ещё не прочитан целиком.
	# Оставшиеся буферы тем временем могут использоваться для чтения ответа и, при необходимости, буферизации части ответа во временный файл.
	# По умолчанию размер ограничен двумя буферами, заданными директивами "fastcgi_buffer_size" и "fastcgi_buffers".

	fastcgi_temp_file_write_size 1m;
	# Ограничивает размер данных, сбрасываемых во временный файл за один раз, при включённой буферизации ответов FastCGI-сервера во временные файлы.
	# По умолчанию размер ограничен двумя буферами, заданными директивами "fastcgi_buffer_size" и "fastcgi_buffers".
	# Максимальный размер временного файла задаётся директивой "fastcgi_max_temp_file_size".

	fastcgi_send_timeout 1500s;
	# Задаёт таймаут при передаче запроса FastCGI-серверу.
	# Таймаут устанавливается не на всю передачу запроса, а только между двумя операциями записи.
	# Если по истечении этого времени FastCGI-сервер не примет новых данных, соединение закрывается.

	fastcgi_read_timeout 1500s;
	# Задаёт таймаут при чтении ответа FastCGI-сервера.
	# Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями чтения.
	# Если по истечении этого времени FastCGI-сервер ничего не передаст, соединение закрывается.

	proxy_buffers 12 12k;
	# Задаёт число и размер буферов для одного соединения, в которые будет читаться ответ, получаемый от проксируемого сервера.
	# По умолчанию размер одного буфера равен размеру страницы.
	# В зависимости от платформы это или 4K, или 8K.

	proxy_buffer_size 12k;
	# Задаёт размер буфера, в который будет читаться первая часть ответа, получаемого от проксируемого сервера.
	# В этой части ответа находится, как правило, небольшой заголовок ответа.
	# По умолчанию размер одного буфера равен размеру страницы памяти.
	# В зависимости от платформы это или 4K, или 8K, однако его можно сделать меньше.

	proxy_busy_buffers_size 12k;
	# При включённой буферизации ответов проксируемого сервера, ограничивает суммарный размер буферов, которые могут быть заняты для отправки ответа клиенту, пока ответ ещё не прочитан целиком.
	# Оставшиеся буферы тем временем могут использоваться для чтения ответа и, при необходимости, буферизации части ответа во временный файл.
	# По умолчанию размер ограничен величиной двух буферов, заданных директивами "proxy_buffer_size" и "proxy_buffers".

	include /etc/nginx/ip.conf;         # Работа с IP адресами
	include /etc/nginx/mime.types;
	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/vhosts/*/*.conf;

	default_type application/octet-stream;
	# Задаёт MIME-тип ответов по умолчанию. Соответствие расширений имён файлов MIME-типу ответов задаётся с помощью директивы "types".

	log_format main '$remote_addr - $remote_user [$time_local] "$request" '
					'$status $body_bytes_sent "$http_referer" '
					'"$http_user_agent" "$http_x_forwarded_for"';

	access_log /var/log/nginx/access.log main;

	server {
		server_name      localhost;
		disable_symlinks if_not_owner;

		include /etc/nginx/vhosts-includes/*.conf;

		location @fallback {
			error_log /dev/null crit;

			proxy_pass http://127.0.0.1:8080;
			proxy_redirect http://127.0.0.1:8080 /;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Proto $scheme;

			access_log off ;
		}

		listen 80;
		listen [::]:80;
	}
}

И www-root.conf ("opt/php73/etc/php-fpm.d/"):
pm = dynamic
pm.start_servers     = 2
pm.min_spare_servers = 1
pm.max_children      = 100
pm.max_spare_servers = 65
pm.max_requests      = 1000
После того, как я уменьшил количество запросов в БД (подробнее тут: Журнал пользователя движка phpFOX 3 (Сообщение отдельно: #3775)) не было ни одной 502 ошибки, уже четвертый день без этого: recv() failed (104: Connection reset by peer) while reading response header from upstream. Очень надеюсь, что решил проблему окончательно.
Зарегистрировался, чтобы добавить сюда ещё одну возможную причину появления этой ошибки, чтобы такие же как я, пришедшие по ссылке с Тостера.

У меня такая ошибка возникала из-за расширения xdebug. После того, как я его отключил всё вернулось на круги своя.