Comprehensive Guide to Log File Management with Logrotate on Ubuntu 20.04/22.04

Posted on

Comprehensive Guide to Log File Management with Logrotate on Ubuntu 20.04/22.04

Comprehensive Guide to Log File Management with Logrotate on Ubuntu 20.04/22.04

Log File Management with Logrotate on Ubuntu

In any production server environment, managing log files is a crucial aspect of system administration. Log files contain valuable information about system events, application behavior, and potential issues, making them indispensable for troubleshooting and monitoring purposes. However, if left unchecked, log files can grow rapidly, consuming significant disk space and potentially leading to performance degradation or even system crashes.

Logrotate is a powerful utility designed to address this issue by automatically rotating, compressing, and pruning log files based on predefined rules and schedules. By regularly compressing and archiving old log files, and removing obsolete ones, Logrotate ensures that disk space is used efficiently and that log files remain manageable.

This comprehensive guide will explore Logrotate’s functionality, its default configuration on Ubuntu 20.04 and 22.04, and walk through the process of setting up custom log rotation rules for a fictional application. Effective Log File Management with Logrotate on Ubuntu 20.04/22.04 ensures that servers run smoothly.

Prerequisites

Before proceeding, ensure that you have the following:

  • An Ubuntu 20.04 or 22.04 server.
  • Sudo privileges.

Logrotate is pre-installed on Ubuntu, but if you need to install it manually, you can do so by running the following commands:

$ sudo apt update
$ sudo apt install logrotate

Step 1: Verifying the Logrotate Version

Although Logrotate comes pre-installed on Ubuntu, it’s a good practice to verify the installed version and its default settings. You can do this by running the following command:

$ logrotate --version

This command will display the version number, as well as information about default settings such as the mail command, compression command, and state file path. Here’s an example output:

logrotate 3.19.0
    Default mail command:       /usr/bin/mail
    Default compress command:   /bin/gzip
    Default uncompress command: /bin/gunzip
    Default compress extension: .gz
    Default state file path:    /var/lib/logrotate/status
    ACL support:                yes
    SELinux support:            yes

If you’re using a non-Ubuntu distribution or have a significantly different version of Logrotate, some configuration options covered in this guide may not apply. In such cases, consult the man pages (man logrotate) or online documentation for your specific Logrotate version. Proper Log File Management with Logrotate on Ubuntu 20.04/22.04 is essential.

Step 2: Exploring the Default Configuration

On Ubuntu systems, Logrotate’s configuration is primarily managed through two locations:

  1. /etc/logrotate.conf: This is the main configuration file, defining global settings and including other configuration files.
  2. /etc/logrotate.d/: This directory contains configuration files for individual applications or services.

Let’s examine the default configuration in the /etc/logrotate.conf file:

$ sudo cat /etc/logrotate.conf

This file sets up weekly log rotations for log files owned by the root user and the syslog group. It keeps four rotated log files (rotate 4) and creates new empty log files after rotation (create). Additionally, it includes configuration files from the /etc/logrotate.d directory.

Next, let’s look at an example configuration file from the /etc/logrotate.d directory for the apt package:

$ sudo cat /etc/logrotate.d/apt
/var/log/apt/term.log {
  rotate 12
  monthly
  compress
  missingok
  notifempty
}
/var/log/apt/history.log {
  rotate 12
  monthly
  compress
  missingok
  notifempty
}

This file contains configuration blocks for two log files: term.log and history.log, located in the /var/log/apt/ directory. The configuration options used here are:

  • rotate 12: Keeps 12 rotated log files.
  • monthly: Rotates the log files monthly.
  • compress: Compresses the rotated log files using gzip.
  • missingok: Does not report an error if the log file is missing.
  • notifempty: Does not rotate the log file if it is empty.

Any options not specified in these configuration blocks will inherit the default values from /etc/logrotate.conf.

Step 3: Setting Up a Custom Configuration

While the default configuration is sufficient for most system logs, you may need to set up custom log rotation rules for your applications. Logrotate offers two main approaches for this:

  1. Adding a configuration file to /etc/logrotate.d/.
  2. Creating an independent configuration file and setting up a cron job.

Adding Configuration to /etc/logrotate.d/

This approach involves creating a new configuration file in the /etc/logrotate.d/ directory. The configuration defined in this file will be run daily as the root user, along with all the other default Logrotate jobs.

Let’s set up a configuration for a fictional web application called “your-app” that generates access.log and error.log files in the /var/log/your-app/ directory. The application runs as the www-data user and group.

First, create a new configuration file:

$ sudo nano /etc/logrotate.d/your-app

Add the following configuration to the file:

/var/log/your-app/*.log {
    daily
    missingok
    rotate 14
    compress
    notifempty
    create 0640 www-data www-data
    sharedscripts
    postrotate
        systemctl reload your-app
    endscript
}

Here’s what each option does:

  • /var/log/your-app/*.log: Specifies the log files to be rotated.
  • daily: Rotates the log files daily.
  • missingok: Does not report an error if the log file is missing.
  • rotate 14: Keeps 14 rotated log files.
  • compress: Compresses the rotated log files using gzip.
  • notifempty: Does not rotate the log file if it is empty.
  • create 0640 www-data www-data: Creates a new empty log file after rotation, with the specified permissions, owner, and group.
  • sharedscripts: Indicates that the prerotate and postrotate scripts should only be run once for all log files that match the pattern.
  • postrotate: Specifies a script to be run after the log file has been rotated. In this case, it reloads the your-app service.
  • endscript: Marks the end of the postrotate script.

Save and close the file. You can test the configuration by running a dry run:

$ sudo logrotate /etc/logrotate.conf --debug

This command executes Logrotate with the standard configuration file and enables debug mode, printing information about which log files would be handled and the actions that would be taken.

Creating an Independent Configuration

In some cases, you may need to run Logrotate as a non-root user or rotate logs more frequently than the default daily schedule. In such situations, you can create an independent Logrotate configuration and set up a cron job to run it at the desired interval.

Suppose you have an application running as the bob user, generating logs in the /home/bob/logs/ directory. You want to rotate these logs hourly.

First, create a configuration file in your home directory:

$ nano /home/bob/logrotate.conf

Add the following configuration:

/home/bob/logs/*.log {
    hourly
    missingok
    rotate 24
    compress
    create
}

This configuration will rotate the logs hourly, keeping 24 old rotated log files, compressing them, and creating a new empty log file after rotation.

Save and close the file.

Next, create a log file for testing purposes:

$ cd ~
$ mkdir logs
$ touch logs/access.log

Now, run Logrotate with the new configuration and specify a state file location:

$ logrotate /home/bob/logrotate.conf --state /home/bob/logrotate-state --verbose

The --state option specifies the location of the state file, which records information about the logs processed during each run. The --verbose flag displays detailed output about Logrotate’s actions.

You should see output similar to the following:

reading config file /home/bob/logrotate.conf
Handling 1 logs
rotating pattern: /home/bob/logs/*.log  hourly (24 rotations)
empty log files are rotated, old logs are removed
considering log /home/bob/logs/access.log
  log does not need rotating

Logrotate recorded information about the logs it encountered in the state file. You can view the contents of the state file with:

$ cat /home/bob/logrotate-state

If you run the same command an hour later, the log file should be rotated as expected.

To force Logrotate to rotate the log file immediately (for testing purposes), use the --force flag:

$ logrotate /home/bob/logrotate.conf --state /home/bob/logrotate-state --verbose --force

Finally, set up a cron job to run Logrotate hourly. Open your user’s crontab with:

$ crontab -e

Add the following line to the crontab file:

14 * * * * /usr/sbin/logrotate /home/bob/logrotate.conf --state /home/bob/logrotate-state

This will run the logrotate command on the 14th minute of every hour, using the full path to the logrotate binary and specifying the configuration file and state file locations.

Save and exit the crontab file. The cron job will now run at the specified schedule. Understanding Log File Management with Logrotate on Ubuntu 20.04/22.04 will help keep your systems running smoothly.

Advanced Configuration Options

While the examples covered in this guide demonstrate some common Logrotate options, there are many more advanced options available for fine-tuning log rotation behavior. Here are a few notable options:

  • size: Rotates the log file when it reaches a specific size (e.g., size 100k, size 10M).
  • dateext: Appends a date to the rotated log file name.
  • dateformat: Specifies the format of the date appended to the rotated log file name (e.g., dateformat -%Y%m%d).
  • maxage: Removes rotated logs older than a certain number of days.
  • prerotate: Specifies a script to be run before the log file is rotated.

You can explore these and other options by consulting the Logrotate manual page (man logrotate) or the online documentation.

Conclusion

Effective log file management is crucial for maintaining a healthy server environment and ensuring that valuable log data is preserved and accessible when needed. Logrotate is a powerful tool that simplifies this task by automating log rotation, compression, and pruning based on customizable rules and schedules. The article details how to achieve efficient Log File Management with Logrotate on Ubuntu 20.04/22.04.

By following the examples and best practices outlined in this guide, you can effectively manage log files for your applications, ensuring optimal disk space utilization and easy access to historical log data when needed.

Alternative Solutions to Log File Management

While Logrotate is a solid choice, let’s explore two alternative approaches to log file management on Ubuntu.

1. Using systemd-journald with Size Limits

systemd-journald is the default logging system for systemd-based Linux distributions like Ubuntu. While it primarily stores logs in a binary format, it offers features for managing log size and retention. This approach avoids the traditional file-based rotation, instead relying on journald’s built-in capabilities.

Explanation:

Instead of relying on external tools to rotate files, we configure systemd-journald to automatically manage the size and retention of log data. This can simplify the setup process, especially for system-level logs already handled by journald.

Configuration:

Edit the /etc/systemd/journald.conf file to set size limits:

[Journal]
SystemMaxUse=500M
RuntimeMaxUse=50M
  • SystemMaxUse: Sets the maximum disk space that journald can use for system logs (logs written to /var/log/journal). In this example, it’s set to 500MB.
  • RuntimeMaxUse: Sets the maximum disk space used for logs in /run/log/journal (logs stored in memory before being written to disk). Here, it’s set to 50MB.

After modifying the configuration, restart the journald service:

sudo systemctl restart systemd-journald

Advantages:

  • Simplified configuration for system logs.
  • Leverages existing systemd infrastructure.

Disadvantages:

  • Less flexible for application-specific logs that aren’t integrated with systemd.
  • Binary log format requires using journalctl for analysis.

2. Implementing a Custom Log Rotation Script with find and gzip

For more control and flexibility, you can create a custom log rotation script using standard Unix utilities like find, gzip, and mv. This approach is useful for applications that require specific rotation logic or are not easily integrated with Logrotate or systemd-journald.

Explanation:

This method involves writing a shell script that identifies old log files based on their age or size, compresses them, and optionally moves them to an archive directory. This gives you complete control over the rotation process.

Code Example:

#!/bin/bash

LOG_DIR="/var/log/my-app"
ARCHIVE_DIR="/var/log/my-app/archive"
MAX_AGE="+7" # Keep logs for 7 days
COMPRESS_EXTENSION=".gz"

# Ensure archive directory exists
mkdir -p "$ARCHIVE_DIR"

# Find log files older than MAX_AGE, compress them, and move them to the archive directory
find "$LOG_DIR" -name "*.log" -type f -mtime "$MAX_AGE" -print0 | while IFS= read -r -d $'' file; do
  gzip "$file"
  mv "${file}${COMPRESS_EXTENSION}" "$ARCHIVE_DIR/"
done

# Optional: Delete logs older than a certain period (e.g., 30 days) in the archive
find "$ARCHIVE_DIR" -name "*.log${COMPRESS_EXTENSION}" -type f -mtime +30 -delete

Explanation of the script:

  • LOG_DIR: Specifies the directory containing the log files.
  • ARCHIVE_DIR: Specifies the directory where rotated logs will be archived.
  • MAX_AGE: Specifies the maximum age (in days) of log files to be rotated.
  • COMPRESS_EXTENSION: Sets the extension for compressed files.
  • The find command locates log files matching the criteria.
  • The while loop iterates through the found files, compresses them using gzip, and moves them to the archive directory.
  • The final find command (optional) deletes archived logs older than 30 days.

Scheduling the script:

Make the script executable:

chmod +x /path/to/your/rotation_script.sh

Then, add it to cron to run it periodically (e.g., daily):

0 0 * * * /path/to/your/rotation_script.sh

Advantages:

  • Highly customizable.
  • Uses standard Unix utilities, minimizing dependencies.

Disadvantages:

  • Requires writing and maintaining a script.
  • More complex to configure than Logrotate.

These alternative solutions offer different approaches to log file management, providing flexibility to choose the method that best suits your specific needs and technical expertise.

Leave a Reply

Your email address will not be published. Required fields are marked *