У меня проблемы с любыми командами, которые говорят 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)