Managing Log Files
100%

Logging · Lesson 6

Managing Log Files

Learn how to configure, test, and verify safe text-log rotation with logrotate.

Unbounded text logs can exhaust a filesystem, while overly aggressive deletion can remove evidence required for operations or compliance. logrotate applies configured size, time, compression, ownership, and retention policies to file-based logs.

Understanding Rotation

A typical rotation renames the active file, creates a replacement, optionally asks the application to reopen it, compresses older generations, and removes files beyond retention. These steps depend on configuration; rotation is not a backup because retained copies can still be deleted, corrupted, or lost with the same host.

Why is log rotation not a substitute for backup or archival?

Finding Configuration

The main file is commonly /etc/logrotate.conf, with package or application snippets under /etc/logrotate.d/. A simplified policy can look like:

/var/log/example/app.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 example adm
}

This requests daily evaluation, seven retained rotations, compression delayed by one generation, tolerance for a missing or empty log, and a newly created file with explicit mode and ownership. Actual rotation also depends on recorded state and how the scheduler invokes logrotate.

What does rotate 7 specify?

Coordinating with the Writer

After renaming a log, a daemon can continue writing through its still-open file descriptor. A postrotate script often sends a documented reload or reopen signal. Validate the exact application behavior and keep the script narrowly scoped.

copytruncate copies a file and truncates the original in place when an application cannot reopen logs. Writes can be lost or duplicated during the copy-and-truncate window, so it is a compromise rather than a universally safe default.

Why might an application need a reopen signal after rotation?

Testing Before Activation

Use debug mode to inspect decisions without rotating files:

$ sudo logrotate -d /etc/logrotate.conf

Debug output does not prove that permissions, scripts, free space, or application reopening will succeed during a real run. Test a new rule in a controlled environment, then inspect the active file, rotated generation, ownership, compression, application output, and logrotate status after execution. -f forces rotation and is state-changing; do not confuse it with a dry run.

What does logrotate -d provide?

Accounting for Other Stores

Logrotate manages files named by its policies. The systemd journal has its own size and retention configuration, while databases and remote logging services have separate lifecycle controls. Monitor filesystem capacity and logging health so a stuck writer or failed rotation is detected before space is exhausted.

Does a logrotate rule automatically enforce systemd journal retention?

Lesson complete

You finished Managing Log Files

You can now design and verify a file-log rotation policy without mistaking it for archival.

  • Balance space, operational, and retention requirements.

  • Define generations, compression, ownership, and empty-file behavior.

  • Coordinate safely with applications that keep descriptors open.

  • Debug configuration before a controlled real rotation.

  • Manage journal and external-store retention separately.

Keep your learning progress

Create a free account to save this lesson and continue learning on any device.

Create a free account
Back to Logging