Я попытался исправить проблему ротации журнала с помощью log4j2 в веб-приложении, запущенном на Apache Tomcat/8.0.32 (Ubuntu)
на Ubuntu 16.04.4
(видеть связанный вопрос о переполнении стека). Tomcat работает на OracleJRE 1.8.0_181
.
Я переключил полную установку Apache Tomcat на реализацию Tomcat java.utils.logging
(Tomcat JULI) в log4j2: Интеграция с сервером приложений Log4j.
Он работает нормально, но у меня проблема, которая затронула веб-приложение, теперь влияет и на Tomcat. Кажется, что в полночь файлы журнала поворачиваются и упаковываются с помощью gzip, но новые файлы журнала не создаются. Файлы журнала записываются в /var/log/tomcat8/
.
Я полагаю, что это скорее системный процесс, вращающий файлы журнала, чем ошибка Tomcat. Сервер использует systemd
, с участием systemd-tmpfiles-clean.timer
активирован и rsyslog.service
включен и работает.
Делает systemd-tmpfiles-clean.timer
выполняет ротацию файлов журнала или другой системный процесс меняет журналы? Если да, то как я могу исключить каталог /var/log/tomcat8/
из ротации журнала процесса?
РЕДАКТИРОВАТЬ: файлы конфигурации logrotate
/etc/logrotate.conf
# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
#compress
# packages drop log rotation information into this directory
include /etc/logrotate.d
# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
missingok
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0660 root utmp
rotate 1
}
/etc/logrotate.d/tomcat8
/var/log/tomcat8/catalina.out {
copytruncate
weekly
rotate 52
compress
missingok
create 640 tomcat8 adm
}
Изменить: администратор перенастроил logrotate (к сожалению, без объяснения того, что он сделал), и эта проблема исчезла.