Назад | Перейти на главную страницу

Служба ротации NGINX не использует новые файлы журналов

У меня проблемы с любыми командами, которые говорят nginx использовать новые файлы журнала. Я использую Ubuntu 18.04, nginx / 1.14.0, logrotate 3.11.0

Если я создам новый access.log или error.log файлы в / var / log / nginx, вручную или через logrotate, они не используются, и вместо этого служба использует старые файлы журналов (которые я переименовал в access.log.1 для этого теста имитирует то, что делает logrotate.)

Я пробовал следующие команды (отдельно). Ни один из них не выдает никаких сообщений об ошибках, все они дают ожидаемый результат. Но nginx отказывается прекращать использование старых журналов.

service nginx rotate

invoke-rc.d nginx rotate

kill -USR1 `cat /var/run/nginx.pid`

Я также подтвердил, что указанное выше .pid файл находится в правильном месте.

Единственный способ заставить работать ротацию журналов - это service nginx reload, который выполняет свою работу, но также перезагружает файлы конфигурации. Я знаю, что при перезагрузке нет простоев, но я все же предпочел бы перезагружать как можно меньше, поэтому я хочу получить service nginx rotate работает.

Я почти уверен, что это связано с проблемами разрешения в /var/log. Недавно мы настроили cronjob, чтобы файлы журналов имели безопасные разрешения. Это было сделано для аудита, поскольку компания, проводившая тестирование на проникновение, предложила различные меры безопасности в отношении ведения журнала. Настроенное нами задание cron запускается при загрузке:

#!/bin/bash
  
setfacl -Rm u::rwx,g::r--,o::--- /var/log
find /var/log -type f -exec chmod g-wx,o-rwx "{}" + -o -type d -exec chmod g-w,o-rwx "{}" +
chmod g+wx /var/log

chown -R www-data:adm /var/log/nginx

Вот права доступа соответствующих каталогов и файлов после запуска cronjob:

Сам каталог / var / log:

drwxrwx--- 14 root syslog  4096 Aug 27 10:01 log

Сам каталог / var / log / nginx:

drwxr-----  2 www-data  adm               4096 Aug 24 02:25  nginx

И содержимое / var / log / nginx (мы используем собственные именованные журналы в нашей конфигурации nginx):

-rwxr----- 1 www-data adm     0 Aug 24 02:24 access.log
-rwxr----- 1 www-data adm   108 Aug 24 02:24 error.log
-rwxr----- 1 www-data adm 49317 Aug 27 10:11 x3nr0s.access.log
-rwxr----- 1 www-data adm   798 Aug 27 10:02 x3nr0s.error.log

Если мы бежим logrotate --force /etc/logrotate.d/nginx -v (многословно) или даже руководство touch для создания новых файлов они создаются с 640 разрешениями (согласно конфигурационному файлу logrotate). Из того, что я прочитал, достаточно 640:

-rwxr----- 1 www-data adm     0 Aug 24 02:24 access.log
-rw-r----- 1 www-data adm     0 Aug 27 10:13 error.log
-rwxr----- 1 www-data adm  1972 Aug 27 10:13 error.log.1
-rw-r----- 1 www-data adm     0 Aug 27 10:13 x3nr0s.access.log
-rwxr----- 1 www-data adm 51521 Aug 27 10:13 x3nr0s.access.log.1
-rw-r----- 1 www-data adm     0 Aug 27 10:13 x3nr0s.error.log
-rwxr----- 1 www-data adm   798 Aug 27 10:02 x3nr0s.error.log.1

Как видите, новые файлы остаются пустыми, а ведение журнала продолжается в старый файл. Я также проверил подробный вывод logrotate, и, похоже, все работает нормально в отношении раздела postrotate. (Который работает invoke-rc.d nginx rotate. Как я упоминал ранее, похоже, что эта команда ничего не вращает ...)

В качестве последнего теста я попытался дать пользователю права на выполнение для новых файлов и сделал service nginx rotate. Тем не менее, nginx использует старые файлы. В некоторых других ответах упоминается, чтобы проверить, заполнено ли дисковое пространство. Это не.

Был бы признателен за помощь в этом! Спасибо.

Дополнительная информация

Вот моя конфигурация /etc/logrotate.d/nginx:

/var/log/nginx/*.log {
        daily
        missingok
        rotate 14
        compress
        delaycompress
        notifempty
        create 0640 www-data adm
        sharedscripts
        prerotate
                if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
                        run-parts /etc/logrotate.d/httpd-prerotate; \
                fi \
        endscript
        postrotate
                invoke-rc.d nginx rotate >/dev/null 2>&1
        endscript
}

Как упоминалось выше, единственный способ заставить logrotate и nginx правильно работать с новыми файлами журнала - это заменить postrotate раздел с service nginx reload.

Вот результат ps -ef | grep nginx:

root      1367     1  0 10:45 ?        00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data  1368  1367  0 10:45 ?        00:00:00 nginx: worker process
www-data  1369  1367  0 10:45 ?        00:00:00 nginx: worker process
www-data  1370  1367  0 10:45 ?        00:00:00 nginx: worker process
www-data  1371  1367  0 10:45 ?        00:00:00 nginx: worker process
root     15247 14835  0 11:19 pts/0    00:00:00 grep --color=auto nginx

Здесь getfacl в / var / log:

# file: var/log
# owner: root
# group: syslog
user::rwx
group::rwx
other::---

А вот и getfacl на / var / log / nginx:

# file: var/log/nginx
# owner: www-data
# group: adm
user::rwx
group::r--
other::---

В /etc/logrotate.d/nginx по умолчанию и должен работать.

Однако изменение postrotate.d команда, чтобы заставить nginx перезагрузить свою конфигурацию (и использовать новый файл журнала)

  service nginx reload >/dev/null 2>&1

может быть быстрым решением.

Часто, когда обычно работающая служба не может создать / открыть / переименовать / изменить файл, возникают права доступа.

Здесь доступы были изменены (в целях безопасности), но acl по умолчанию также должен работать / безопасно, без участия setfacl который мощный, но не появляется сразу при использовании по умолчанию ls параметры.

По умолчанию acl для /var/log

drwxrwxr-x 18 root syslog 4096 Aug 27 07:25 /var/log/

а по умолчанию nginx (на самом деле)

drwxr-x--- 2 www-data adm 4096 Aug 27 07:25 /var/log/nginx/

nginx Это хорошо, /var/log может быть немного жестче

drwxrwx--x 18 root syslog 4096 Aug 27 07:25 /var/log/

что позволяет others чтобы посетить каталог (и ниже), но запретить им выводить содержимое.

Что касается факта, то getfacl команда перечислит фактические добавленные ACL для /var/log, /var/log/nginx и /var/log/nginx/*, это может выявить проблему.

Кстати, сделайте также

dpkg-statoverride --list

чтобы проверить, какие ACL установщик установит после обновления или установки, и, возможно, при необходимости измените или добавьте строку (человек dpkg-statoverride)