I tried to fix a log rotation problem with log4j2 in a webapp running on Apache Tomcat/8.0.32 (Ubuntu)
on Ubuntu 16.04.4
(see related stackoverflow question).
Tomcat runs on OracleJRE 1.8.0_181
.
I switched the complete Apache Tomcat installation von Tomcat's implementation of java.utils.logging
(Tomcat JULI) to log4j2: Log4j App Server Integration.
It works fine, but I have the issue that affected the webapp now affects Tomcat too. The log files seems to be rotated and packed with gzip at midnight, but no new log files are created. The log files are written at /var/log/tomcat8/
.
I expect that it's rather a system process that rotates the log files than a Tomcat bug. The server uses systemd
, with systemd-tmpfiles-clean.timer
activated and rsyslog.service
enabled and running.
Does systemd-tmpfiles-clean.timer
rotates the log files or does another system process rotate the logs? If yes, how I can exclude the directory /var/log/tomcat8/
from the process's log rotation?
EDIT: logrotate config files
/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
}
Edit: The administrator reconfigured logrotate (unfortunately without an explanation what he has done) and this issue disappeared.