Purpose

By default, JIRA applications mirror the application log output (atlassian-jira.log) to the Tomcat log file, catalina.out. This file can grow quite large and cannot be rotated by JIRA applications using Log4j configuration.

There is a suggestion to handle this better in product tracked in  JRA-28941 - Getting issue details... STATUS .

For Windows-specific versions, please see this KB: Reduce Tomcat logging for Jira server on Windows

Solution

There are many systems that you can use to rotate logs and each has their pros, cons, and quirks. These methods are noted in the Apache Tomcat documentation:

• Use jsvc to start Tomcat then send a SIGUSR1 signal from a log rotation script (logrotate, mv, or any other method).
• Use 'logrotate' with the 'copytruncate' option
• Modify bin/catalina.sh or bin/catalina.bat to pipe output from the JVM into a piped-logger such as chronolog or Apache httpd's rotate logs.

The simplest option is logrotate with copy truncate so we have documented this method here. This is an excellent option for Linux/Unix installations because logrotate is probably already being used to rotate all your system logs.

Configuration, installation and log file locations differ between operating systems. Do not execute the commands below without checking that the file locations are correct for your system. In this example, we have these locations:

• JIRA Installation Directory: /opt/atlassian/jira
• Logrotate configuration files: /etc/logrotate.d

When you have confirmed the file and directory paths above, follow these steps, inserting the correct locations in the shell commands.

1. Check that your system has logrotate installed:

   which logrotate

   If you don't get a path to the executable, it is likely you do not have logrotate installed and cannot continue. You may be able to install it using your system's package manager.

   Make sure that you install logrotate version 3.8.0 or later as the solution specified below does not work with older logrotate versions.

2. Purge the contents of catalina.out. This is necessary in case the file has grown so large that rotating it would create a problem. JIRA applications will happily continue writing to the file after you run this:

   echo > /opt/atlassian/jira/logs/catalina.out

   This is relatively safe because almost everything is already present in your JIRA application logs. Alternatively, you could copy the file to another location before purging it.

3. Find the user and group that is set for the parent directory:

   ls -la /opt/atlassian/jira/logs

   The user and group listed for "." are the ones you need for the next step.

4. Create a file at /etc/logrotate.d/jira-tomcat.conf with the content below. Use the user/group from the prior step after the "su" directive:

   /etc/logrotate.d/jira-tomcat.conf

   /opt/atlassian/jira/logs/catalina.out {
   	rotate 5
   	size 20M
   	nocompress
   	notifempty
   	missingok
   	copytruncate
   	su THE_USER THE_GROUP
   }

   Note that 'nocompress' will leave the log archives uncompressed, if it is desirable to compress them in order to save filesystem space, omit this parameter.

5. Perform a test rotation:

   logrotate --force /etc/logrotate.d/jira-tomcat.conf

Verify it's working correctly by checking that there are now two files, catalina.out and catalina.out.1:

ls /opt/atlassian/jira/logs | grep catalina.out

Logrotate runs daily, by default, using a cron job - it is generally available under the /etc/cron.daily/logrotate file. To run it more often, a cron job specific to that end would be needed.

For additional details about logrotate refer to the log rotate man page. A feature suggestion to handle this better in JIRA applications is tracked as JRASERVER-28941 - Getting issue details... STATUS .

Alternate Solution

An alternative is to remove the JIRA application-specific logging from catalina.out, drastically reducing its file size. This is done by removing all references to console in the JIRA_INSTALL/atlassian-jira/WEB-INF/classes/log4j.properties file. JIRA applications will continue to log to atlassian-jira.log. This is already configured to be a rolling log by default. It rotates the logs every 20MB.

See the detailed workaround in the JRASERVER-67796 - Getting issue details... STATUS