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
