У меня проблемы с любыми командами, которые говорят 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, чтобы гарантировать, что файлы журналов имеют безопасные разрешения. Это было сделано для аудита, так как компания, проводящая пентест, предложила различные меры безопасности в отношении ведения журналов. Настроенный нами cronjob запускается при загрузке:
#!/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(verbosely) или даже руководство 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::---
решение1
Это /etc/logrotate.d/nginxзначение по умолчанию, и оно должно работать.
Однако, изменив postrotate.dкоманду, можно заставить nginx перезагрузить свою конфигурацию (и использовать новый файл журнала)
service nginx reload >/dev/null 2>&1
может быть быстрым решением.
Часто, когда обычно работающий сервис не может создать/открыть/переименовать/изменить файл, речь идет о правах доступа.
Здесь доступы были изменены (в целях безопасности), но список контроля доступа по умолчанию также должен быть рабочим/безопасным, без задействования 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посещать каталог (и ниже), но не позволяют просматривать его содержимое.
Что касается facl, getfaclкоманда выведет список фактически добавленных ACL для /var/log, /var/log/nginxи /var/log/nginx/*, которые могут выявить проблему.
Кстати, сделайте также
dpkg-statoverride --list
чтобы проверить, какие списки управления доступом (ACL) установит установщик после обновления или установки, и, возможно, изменить или добавить строку, если это необходимо (man dpkg-statoverride)