How to rotate Tomcat catalina.out
If catalina.out becomes 2GB in size, tomcat crashes and fails to start without any error message. To avoid this scenario you should rotate catalina.out frequently. This article describes how to setup auto rotation of catalina.out on a linux/unix machine.
How to automatically rotate catalina.out daily or when it becomes bigger than 5M
1. Create this file
/etc/logrotate.d/tomcat
2. Copy the following contents into the above file
/var/log/tomcat/catalina.out {
copytruncate
daily
rotate 7
compress
missingok
size 5M
}
About the above configuration:
- Make sure that the path /var/log/tomcat/catalina.out above is adjusted to point to your tomcat’s catalina.out
- daily - rotates the catalina.out daily
- rotate – keeps at most 7 log files
- compress – compresses the rotated files
- size – rotates if the size of catalina.out is bigger than 5M
- copytruncate – truncates the original log file in place after creating a copy, instead of moving the old log file and optionally creating a new one, It can be used when some program can not be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place.
You don’t need to do anything else.
How it works
- Every night the cron daemon runs jobs listed in the /etc/cron.daily/ directory
- This triggers the /etc/cron.daily/logrotate file which is generally shipped with linux installations. It runs the command “/usr/sbin/logrotate /etc/logrotate.conf“
- The /etc/logrotate.conf includes all scripts in the /etc/logrotate.d/ directory.
- This triggers the /etc/logrotate.d/tomcat file that you wrote in the previous step.
Run logrotate manually
Run the following command to run the cron job manually
/usr/sbin/logrotate /etc/logrotate.conf
Is it completely safe?
See the description of copytruncate method above. There is a slight chance of a small amount of logging data loss between copy and truncate steps, usually it is acceptable but sometimes its not.
More logrotate options
To see all logrotate options on your system, see the manual:
man logrotate
Related posts:
I don’t agree that this will work. catalina.out is open all the time so after the logrotate happens once, nothing else will be logged because you won’t have a handle to the inode that standard out is writing to.
The only way to fix this is to either restart tomcat or modify catalina.sh so it doesn’t do a > redirect.
It does work for me.
See the documentation of “copytruncate” option of logrotate:
Truncate the original log file in place after creating a copy,
instead of moving the old log file and optionally creating a new
one, It can be used when some program can not be told to close
its logfile and thus might continue writing (appending) to the
previous log file forever. Note that there is a very small time
slice between copying the file and truncating it, so some log-
ging data might be lost. When this option is used, the create
option will have no effect, as the old log file stays in place.
I never knew about the copytruncate option. Seems nicer than modifying catalina.sh + logging configs.
Very powerful, thanks
Why is the log going to catalina.out? We should use log4j or some logging api to pipe it to a log file instead of using stdout.
hi, i couldn’t find logrotate in my OS. i use fedora-linux. where to download this app ?
Install the logrotate rpm using the following command:
1) login as root
2) rpm -Uvh ‘rpm path or rpm URL’
A simple solution for a great problem: thanks vineet!!!
Vineet, Thanks for sharing your conf. Any specific reason for using logrotate and not log4J? Just curious to know Pros/Cons of both configurations if you have tried both. I found log4J DailyRollingFileAppender and RollingFileAppender pretty useful. One drawback being of DailyRollingFileAppender being no out of the box option to specify max. days to keep log files (Log4J ver. 1.2). I guess this can be handled using cron and find commands.
Interesting that you are getting crashes at 2GB. Sounds like it may not be a Tomcat issue and it may be an issue with large file support in your Linux distribution.
http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html