logrotate и nginx. Permission denied у новых логов

а с какими правами создаётся новый лог?

Возможно, с /run/nginx.pid что-то не то? Также можно посмотреть вывод

lsof | grep '(deleted)$'

как и прописано в logrotate: 644 nginx:nginx

creating new /srv/log/www_access.log mode = 0664 uid = 988 gid = 984
set default create context to system_u:object_r:httpd_log_t:s0

uid и gid те самые от nginx:nginx context тот, что надо

nginx     155279                          nginx   17w      REG                8,4    36182  269013842 /srv/log/archive/www_access.log-20201106 (deleted)
nginx     155279                          nginx   18w      REG                8,4      770  269016321 /srv/log/archive/www_error.log-20201106 (deleted)
nginx     155280                          nginx   17w      REG                8,4    36182  269013842 /srv/log/archive/www_access.log-20201106 (deleted)
nginx     155280                          nginx   18w      REG                8,4      770  269016321 /srv/log/archive/www_error.log-20201106 (deleted)

Хмм.. А он тут есть, после исполнения команды. Это и есть причина? Как решить это?

а после

service nginx reload

процессы ушли из deleted

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

Обе команды от рута запускаешь, то?

Да, конечно, мастер процесс nginx от рута запускается, логротате тоже. А вот группа может быть разная.. Я не знаю с какой группой запускается мастер процесс nginx, подскажите, как посмотреть?. А вот logrotate запускается kill похоже как root:nginx

Исходя из выложенного конфига logrotate, у меня сложилось впечатление, что инсталляция NGinx сильно допиливалась в части логов-конфигурации, поэтому ожидать можно всего, что угодно. Согласен с мнением выше, что возможны конфликты разных экземпляров NGinx, или что-то в этом роде.

Предлагаю собрать больше фактуры (для себе, или сюда тоже), и всё это дело сопоставить:

1а) выполнить service nginx reload, который перебросит этот легаси-метод на штатные systemctl status nginx (кстати, что мешает его использовать-то?) В статусе фиксируем: А) строку вида loaded (/usr/lib/systemd/system/nginx.service Б) PID-ы 2) Смотрим настройки сервиса, по пути из предыдущего шага Тут обращаем внимание на overrid-ы - может, конфигурация в другом месте лежит, может pid в другой место пишется, может с юзер-группой что. В общем, все навороты оцениваем. Хорошо бы это сравнить со стоковым оригиналом. Возможно, тут выяснится, что конфиг лежит по нестандартному пути, например (стандартный конфиг можно увидеть, запросив содержимое пакета, как вариант) 3) Сопоставляем /run/nginx.pid с выводами выше, плюс можно ещё с такого разворота оценить:

ss -tulpne | cat -A | grep nginx
ps -efZ | grep nginx

В общем, я бы подобным образом поискал аномалии и нестыковки - задвоение инстансов nginx, неверный PID-файлы, или ещё что-нибудь.

Что-то не даёт отредактировать комментарий. Вот так правильней: 1а) выполнить service nginx status….

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

Но потом нжинкс меняет юзера и группу толи перед форком, толи после, не суть важно.

А важно то, что поменять может и не получиться, если система не позволит.

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