0

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.

fireandfuel
  • 101
  • 3

0 Answers0