Hello!

On Mon, Feb 05, 2024 at 09:56:54PM +0200, Gena Makhomed wrote:

[...]

> Потому что если программа, которая читает данные из unix socket`а
> отвалится - тогда произойдет переполенение буфера и nginx тогда
> заблокируется на операции записи в unix socket, и как следствие
> этого - перестанет выполнять свою основную функцию - перестанет
> отвечать на запросы клиентов по http / https протоколу.

Нет, если в сокет syslog'а не получается писать - nginx [логгирует
ошибку в error log и] дропает сообщение. Я об этом, собственно,
писал в начале треда - судя по всему, исходная проблема была
именно в том, что syslog-сервер не успевал выгребать сообщения, и
они осыпались на пол.

(А если вернуться к основам, то в syslog через стандартную
библиотеку nginx не пишет именно потому, что там запись в сокет в
случае чего блокируется, и так, конечно, жить нельзя.)

[...]

> Так же не понятно, в чем для Вас проблема переименовать
> log-файл и отправить сигнал USR1 мастер-процессу nginx,
> для того, чтобы он переоткрыл log-файл и продолжил запись.
>
> Особенно, если учесть, что директива https://nginx.org/r/access_log
> имеет дополнительные параметры [buffer=size] [flush=time] [if=condition]

+1

Нет никаких проблем вращать файловые логи в nginx'е, переоткрытие
логов по USR1 - дешёвая и быстрая операция.

При этом запись в файловые логи, во-первых, куда эффективнее
записи в syslog, в силу отсутствия лишних context switch'ей, а
во-вторых, позволяет дополнительно и существенно снизить затраты
за счёт буферизации и даже gzip-сжатия на лету.

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

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru