Ubuntu 16.04 Server: Install and Configure logrotate

logrotate is a tool that replaces log files based on frequency or size conditions and manages previous files by storing, compressing, or deleting them. On Ubuntu, it can manage continuously growing logs, but the actual replacement timing depends on the logrotate execution schedule and configuration conditions.

Support and preparation for Ubuntu 16.04

General security maintenance for Ubuntu 16.04 LTS and general extended security maintenance (ESM) for Ubuntu Pro have ended. Canonical offers separate Legacy additional services, so check the coverage and cost at Ubuntu 16.04 Support Guide, and plan to upgrade to a supported Ubuntu version if possible. The basic principles below apply to other versions as well, but detailed behavior can vary depending on the installed logrotate version and execution schedule.

First, check whether it is installed, and if the package is not present on Ubuntu, install it. Before changing the settings of the production server, make sure to check the backup and recovery methods for existing settings and necessary logs.

logrotate --version
sudo apt update
sudo apt install logrotate

Check the default settings and execution schedule

Global settings are generally in /etc/logrotate.conf, and individual settings are read if the file is configured to include /etc/logrotate.d/. Check the actual files on the server. In environments where the Apache package is installed, /etc/logrotate.d/apache2 may exist, but the log path and settings vary depending on the installation environment.

cat /etc/logrotate.conf
ls -l /etc/logrotate.d/
cat /etc/logrotate.d/apache2

On systems without Apache configuration files, the last command may fail. Do not manage the same log path redundantly in two configurations. logrotate does not run continuously by itself or schedule its own execution. On Ubuntu 16.04, it is usually executed periodically through /etc/cron.daily/logrotate, so check that file and whether it is executed via cron. In other versions, actual schedules may differ, such as with systemd timers.

Create independent test logs and settings

The following exercise uses a new temporary directory rather than production logs. Execute in order in the same shell and check the output paths. It uses a temporary directory and separate state files, so it does not modify the system's existing logrotate settings or state.

demo_dir=$(mktemp -d)
printf 'first log line\n' > "$demo_dir/app.log"
cat > "$demo_dir/logrotate.conf" <<EOF
$demo_dir/app.log {
    daily
    rotate 3
    missingok
    notifempty
    compress
    delaycompress
    create 0600
}
EOF
printf 'Test directory: %s\n' "$demo_dir"
cat "$demo_dir/logrotate.conf"

daily is a daily rotation condition, and rotate 3 is a setting that retains previous logs for up to three rotations. missingok avoids errors when a file does not exist, and notifempty does not rotate empty logs. compress compresses previous logs, and delaycompress delays the compression of the most recently rotated log until the next rotation. create 0600 sets permissions when creating new log files after rotation.

The configuration file in this example is not registered in the system schedule, and no actual application writes to the test log. Setting daily does not create a schedule for execution itself. Refer to the official logrotate manual to check options and conditions appropriate for your installed version.

Checking trial runs and actual rotations

First, check the settings and expected behavior in debug mode. -d does not change logs or update state files. With a new state file, the output may indicate that it is not yet time for rotation.

logrotate -d -s "$demo_dir/state" "$demo_dir/logrotate.conf"

Force a rotation only in the practice file and check the results. -f forces rotation even if conditions are not met, so it should not be used carelessly on actual operation logs.

logrotate -v -f -s "$demo_dir/state" "$demo_dir/logrotate.conf"
ls -l "$demo_dir"
cat "$demo_dir/app.log.1"

If successful, the original content is in app.log.1 and a new app.log is created. The most recent rotated portion is not yet compressed because of delaycompress. After adding content to the new log and forcing a rotation one more time, the previous rotated portion is usually compressed as app.log.2.gz.

printf 'second log line\n' >> "$demo_dir/app.log"
logrotate -v -f -s "$demo_dir/state" "$demo_dir/logrotate.conf"
ls -l "$demo_dir"
gzip -cd "$demo_dir/app.log.2.gz"

You can check the first log line from the last command. This exercise does not reproduce a running service that records logs. When the practice is finished, check the temporary path where output was saved and clean up any files you no longer need.

When applying to a production service

A running program can continue writing to the previous log file even after the file has been renamed. Check the procedure provided to have the service reopen the log file and review the postrotate script from the existing package, and verify whether the owner, group, and permissions of the new file are appropriate for the service. Before changing the existing Apache rules, review the distribution and service documentation and back up your configuration.

copytruncate copies the log and then truncates the original in place; it can be used for programs that cannot reopen their log files, but logs may be lost between the copy and truncation. Whenever possible, first check if the service has a way to reopen the log. rotate 3 refers to the number of rotations to keep, not a limit in days or size, so retention policy and disk usage should be checked separately.

Check when it is not rotating

• Verify that the configuration file is included in the global settings and that the target path matches the actual log. Empty files do not rotate in notifempty.
• Check whether the cron or timer is actually running and whether rotation is required based on the state file and periodic conditions. daily does not guarantee rotation at the exact time daily in environments checked once per day.
• Look for issues with permissions, ownership, syntax, and duplicate paths in the debug output and scheduler error logs. Review results and recovery plans before applying -f to the operational logs.