Logrotate Configuration in Linux: Complete Guide 🔄

Logrotate is a Linux utility that archives, compresses, and removes old log files on a schedule. Its global settings live in /etc/logrotate.conf, while per-service policies normally sit in /etc/logrotate.d/. Write a policy, set frequency and retention, then validate it with sudo logrotate -d before you force anything.

Logrotate Configuration in Linux: The Short Version

Here's a working starting point for a fictional app that writes to /var/log/myapp/app.log:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
}

Don't paste that as-is and walk away. The owner, group, and — more importantly — whether your application reopens its log after rotation all need checking. That's the part most people skip, and it's why logs "rotate" while disk usage keeps climbing.

Read: How to Learn Linux

How Linux Log Rotation Actually Works

Logrotate isn't a daemon. It doesn't watch your files. It gets invoked periodically — by a systemd timer on most current distributions, or by /etc/cron.daily/logrotate on older ones — reads its policies, checks its state file, and decides what's due.

The sequence per log is roughly: rename (or copy) the active file, create a replacement or truncate the original, compress an older generation, then delete anything beyond your retention count.

The state file at /var/lib/logrotate/status records when each log was last rotated. This matters more than beginners expect. A perfectly valid policy will do nothing if the state file says the interval hasn't elapsed. Read it if you're curious — but don't edit or delete it as a "fix."

One more thing: your application holds an open file descriptor. Renaming the file doesn't move that descriptor. Unless the process is told to reopen its log, it happily keeps writing to app.log.1 forever. And journald? That's a separate subsystem with its own retention rules in journald.conf — Logrotate handles text files, not the binary journal.

If you got here because /var/log ate your partition, first check disk space in Linux to see what's actually consuming it.

Install Logrotate and Verify the Schedule

Open an SSH session first — if you need a hand, here's how to connect to your VPS. Then confirm what you have:

command -v logrotate
logrotate --version

Here's a distinction that trips people up constantly. The timer controls how often Logrotate runs. Your policy controls whether a given log is due. A daily invocation does not mean every log rotates daily — a weekly policy still waits a week. If you're fuzzy on the scheduling side, our primer on how cron jobs work fills the gap.

Config File Locations and Syntax

The main file, /etc/logrotate.conf, sets global defaults and then pulls in everything else with a line like include /etc/logrotate.d. Package maintainers drop their policies into that directory. So should you.

Every block follows the same anatomy:

# comments start with a hash
/path/to/log {
    directive
    directive value
}

Directives inside a block override globals for that block only. You can list multiple paths, separated by spaces, and wildcards work fine.

Filename hygiene is worth thirty seconds of attention: keep names simple and alphanumeric. Some packages skip files with suffixes like .bak or dots, and behaviour varies by build. So if you back up a policy before editing, store the copy outside /etc/logrotate.d/. Need editor basics? See edit a file in Linux.

Configure Logrotate for a Custom Application: Five Steps

Step 1 — identify the writer. You need to know which process holds the file open:

ls -l /var/log/myapp/app.log
sudo lsof /var/log/myapp/app.log

That output gives you the owner, group, mode, and the PID. Useful background: inspect running Linux processes.

Step 2 — create the policy file. Something like sudo nano /etc/logrotate.d/myapp. If Nano's new to you, edit the policy with Nano walks through the keystrokes.

Step 3 — write it. Every placeholder below needs replacing with your real values:

/var/log/myapp/*.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    dateext
    create 0640 myapp adm
    su myapp adm
    sharedscripts
    postrotate
        /usr/bin/systemctl kill -s HUP myapp.service >/dev/null 2>&1 || true
    endscript
}

Step 4 — check the reopen mechanism. The HUP signal and the unit name in that snippet are examples. Read your application's documentation. Some apps use USR1, some need a graceful reload, some rotate their own logs and want no help from you at all.

Step 5 — validate, then verify. Run sudo logrotate -d /etc/logrotate.conf and read the output for your block. After a real rotation, confirm the app is writing to the new file — not the renamed one.

Ownership and mode bits are load-bearing here. If create values are wrong, the app may lose write access. Refresher: Linux file permissions.

Essential Directives, With the Caveats

Practical Examples

Size-driven policy. Use when volume is unpredictable rather than daily-steady:

/var/log/myapp/app.log {
    size 100M
    rotate 10
    compress
    missingok
    notifempty
    create 0640 myapp myapp
}

Nginx. Look at /etc/logrotate.d/nginx before you touch anything — the package already ships a correct policy, and Nginx reopens its logs on USR1. Same story for Apache: apache2 on Debian/Ubuntu, httpd on RHEL-family, both with a documented graceful reload. If you're setting up a stack from scratch, our guides on installing Nginx on Ubuntu and hosting a website on a Linux VPS cover the surrounding config.

Roughly 30 days of history: daily plus rotate 30. Approximately — empty or missing logs on some days mean fewer generations than calendar days.

Test Safely, Force Carefully

Start with debug mode. It prints decisions, rotates nothing, and leaves the state file alone:

sudo logrotate -d /etc/logrotate.conf

Verbose mode is not a dry run. It talks more and it will perform rotations that are due:

sudo logrotate -v /etc/logrotate.conf

Forcing is the blunt instrument. Pointing -f at the main config may rotate every included policy on the box — rarely what you want on production. Target one file instead:

sudo logrotate -f /etc/logrotate.d/myapp

Better still, test against a disposable state file so you don't corrupt real timing records:

sudo logrotate -d -s /tmp/logrotate-test.status /etc/logrotate.d/myapp

Then verify: archive exists, permissions match, compression timing matches your directives, and the application is writing to the fresh file. Check sudo journalctl -u logrotate.service for errors.

copytruncate vs create

I reach for copytruncate</code only when there's no alternative. It works, and it's genuinely convenient — but that race window is real, and on a multi-gigabyte log the copy itself hurts.

Logrotate Not Working? Start Here

That last row explains a classic head-scratcher: du says the space is free, df says it isn't. Something is still holding a deleted file open. Reopen or restart the writer. And no — chmod 777 is never the answer. For access errors, see fix permission denied errors.

Retention and Best Practices

There's no universally correct retention period. Base it on incident response needs, legal obligations, and how much storage you can spare. Keep authentication and customer-data logs tight — 0640 is a reasonable default, not a rule. Broader hardening: secure a Linux server.

A few habits worth adopting:

• Keep monitoring disk capacity after rotation is configured — use VPS monitoring tools rather than trusting a policy blindly.
• Ship important logs off the server. Compressed local archives are not a forensic record and they aren't a backup — that's what a proper plan to back up a server or VPS is for.
• Use package-maintained policies where they exist.
• Manage journald through journald.conf (SystemMaxUse, RuntimeMaxUse) and journalctl --vacuum-size — not Logrotate.
• Containers usually log to stdout/stderr; rotation there belongs to the runtime or platform.

If log volume grows with traffic, add storage and monitoring rather than logging less. A Linux VPS with full root access gives you control over Logrotate, systemd units, permissions, and disk headroom as your workload scales.