Doesn't 'etc/logrotate.d/tomcat-run.daily' take effect: Manual trigger?

You can manually trigger the log rotation for Tomcat by executing the logrotate command with the specific configuration file path and the force flag. This bypasses the scheduled cron job, ensuring that catalina.out is rotated immediately without waiting for the next daily cycle, which is essential for managing disk space during high-traffic periods or after debugging sessions.

Understanding the Log Rotation Mechanism

Tomcat typically writes its console output to the catalina.out file. Unlike standard log files, this file is often not rotated automatically by default configurations because Tomcat keeps the file descriptor open even after the file is moved or truncated. The system relies on logrotate to handle the rotation, but the timing is usually controlled by a cron daemon running once a day. When you encounter a situation where the log file has grown excessively large and you need immediate relief, relying on the scheduler is insufficient. You must intervene directly using the command-line interface provided by the logrotate utility. The configuration file mentioned in your query, etc/logrotate.d/tomcat-run.daily, defines how the rotation should occur. It specifies the target file, the frequency, the number of backups to keep, and the post-rotation script that signals Tomcat to reopen the log file. If this file exists in /etc/logrotate.d/, it is recognized by the global logrotate service. However, simply having the file there does not mean it runs instantly. The manual trigger is required to execute the instructions within that file right now.

Executing the Manual Trigger

To force the rotation, you need to use the terminal. Open your SSH session or local console and navigate to a directory where you have write permissions, though the command itself requires root privileges. The core command involves calling logrotate and pointing it to the specific configuration file. You must also include the --force argument. This argument tells logrotate to rotate the logs regardless of the time criteria defined in the configuration file. Without this flag, logrotate might check the timestamp and decide that no action is needed, leaving your large catalina.out file untouched. The command structure looks like this:

sudo logrotate --force /etc/logrotate.d/tomcat-run.daily

Note that the path in the title etc/logrotate.d/tomcat-run.daily is likely a relative reference or a typo in the original context. The absolute path on most Linux distributions, including Debian and Ubuntu, starts with a slash. Therefore, the correct path is /etc/logrotate.d/tomcat-run.daily. If your configuration file has a different name, such as tomcat or catalina, replace the filename accordingly. Always verify the exact name of the file in the /etc/logrotate.d/ directory before running the command. If the command executes successfully, it will produce no output if everything goes according to plan. If there are errors, such as permission issues or syntax errors in the configuration file, logrotate will print error messages to the standard error stream. It is advisable to run this command with sudo to ensure that the rotation process has the necessary permissions to move, compress, and delete old log files in the Tomcat directory.

Verifying the Rotation

After running the manual trigger, you should verify that the rotation actually occurred. Check the Tomcat logs directory, typically located at $CATALINA_BASE/logs/. You should see that catalina.out has been renamed, possibly to catalina.out.1 or compressed as catalina.out.1.gz, depending on your configuration. A new, empty catalina.out file should be created so that Tomcat can continue writing to it seamlessly. You can also check the system log for any entries related to logrotate. On many systems, these logs are found in /var/log/syslog or /var/log/messages. Look for lines containing logrotate and the name of your configuration file. This provides an audit trail confirming that the manual intervention was processed correctly by the system.

Troubleshooting Common Issues

Sometimes, the manual trigger fails silently or produces unexpected results. One common issue is that the post-rotation script within the logrotate configuration might fail. This script usually sends a signal to the Tomcat process to reopen its log files. If Tomcat does not receive this signal, it may continue writing to the old, rotated file descriptor, causing duplicate logs or confusion about which file contains the current output. To diagnose this, check if the Tomcat process ID (PID) file is accessible and if the kill command in the post-rotate section is valid. Another potential problem is disk space. If the disk is completely full, logrotate cannot create new files or compress old ones. In such cases, you must first free up some space by deleting unnecessary temporary files or old archives before attempting to rotate the active logs. Additionally, ensure that the user running the logrotate command has read and write access to both the configuration file and the log directory. If permissions are too restrictive, the rotation will fail. For users who manage multiple services, it is worth noting that other services might rely on similar logging structures. For instance, if you are setting up complex environments like Geoserver on top of Tomcat, ensuring consistent log management is crucial. You can find more details on setting up robust environments in our guide on Setting up Geoserver with Debian 12 and Tomcat 9: A Tech Support Guide. Similarly, if your Tomcat instance is not starting properly due to service management issues, checking your systemd configuration is vital. Refer to Tomcat runs from the command line, but will not start as a systemd service for troubleshooting startup failures.

Frequently Asked Questions

Why doesn't logrotate rotate catalina.out automatically?

Tomcat keeps the file descriptor open for catalina.out even after the file is rotated. Standard logrotate moves the file, but Tomcat continues writing to the moved file unless a post-rotate script signals it to reopen the new file.

What happens if I forget the --force flag?

If you omit the --force flag, logrotate checks the age of the log file against the schedule defined in the config. If the file is not yet due for rotation based on time, nothing happens, and the large log file remains unchanged.

Can I use logrotate to compress old logs?

Yes, you can add the compress directive to your logrotate configuration file. This instructs logrotate to gzip the rotated log files, saving significant disk space compared to keeping uncompressed copies.

How do I check if logrotate ran successfully?

You can check the system logs in /var/log/syslog for entries from logrotate. Additionally, verify that the new catalina.out file is empty and that older versions exist in the logs directory with the expected naming convention.

Is it safe to rotate logs while Tomcat is running?

Yes, it is safe and recommended to rotate logs while the service is active. The key is ensuring the post-rotate script correctly signals Tomcat to switch file descriptors, preventing data loss or duplication during the transition.