Служба ротации 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 находится в правильном месте.

Единственный способ заставить работать ротацию журналов осуществляется через службу nginx reload , которая выполняет эту работу, но также перезагружает файлы конфигурации. Я знаю, что с перезагрузкой нет простоев,но я бы предпочел перезагружать как можно меньше, поэтому я хочу, чтобы служба 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

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

Сам каталог / 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 conf):

-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 (подробно) или даже вручную коснитесь для создания новых файлов, они создаются с 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 . Как я упоминал ранее, эта команда, похоже, ничего не вращает ...)

В качестве последнего теста я попытался дать пользователю права на выполнение для новые файлы и сервис nginx повернул . Тем не менее, 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::---
2
задан 27 August 2020 в 15:36
1 ответ

/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/

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

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

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

dpkg-statoverride --list

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

2
ответ дан 27 August 2020 в 13:18

Теги

Похожие вопросы