Configure Logrotate on AlmaLinux VPS: Step-by-Step Guide

Why Log Rotation Matters on an AlmaLinux VPS

Logs are useful until they're not. Left unmanaged, Apache access logs, mail logs, and system journals quietly consume gigabytes over weeks. On a VPS with 40–80 GB of storage, that's not theoretical — it's a real problem that causes downtime when /var fills up and your web server can't write anything.

AlmaLinux ships with Logrotate pre-installed, but the default configuration only covers system-level logs. Services you add later — Nginx, Apache, Postfix, your own applications — need their own rotation rules.

This guide walks through how to configure Logrotate on AlmaLinux VPS (versions 8 and 9), covering both global settings and per-service drop-in files. If you're running a Hostperl VPS and haven't touched your log configuration since launch, now is a good time — before storage becomes urgent.

Check What's Already Running

Before writing any new configuration, see what Logrotate is already managing. The main config lives at /etc/logrotate.conf, and per-service configs sit in /etc/logrotate.d/.

ls -lh /etc/logrotate.d/
cat /etc/logrotate.conf

You'll typically find entries for syslog, wtmp, and btmp already in logrotate.conf. The drop-in directory may also have files for nginx or httpd if you installed them through the system package manager.

To confirm Logrotate is triggering automatically, check whether the daily cron job or systemd timer is active:

# For systemd-based scheduling (AlmaLinux 9):
systemctl status logrotate.timer

# Or check cron on AlmaLinux 8:
cat /etc/cron.daily/logrotate

On AlmaLinux 9, Logrotate runs via a systemd timer by default, not a cron job. Both work fine — just know which one your system uses.

Understand the Core Configuration Options

You don't need to memorize every Logrotate directive. A handful of them cover almost every real-world scenario.

• daily / weekly / monthly — How often rotation runs.
• rotate N — How many rotated copies to keep. rotate 7 keeps one week of dailies.
• compress — Gzip older logs. Pair with delaycompress so the most recently rotated file stays uncompressed — useful for services that may still have a handle on it.
• missingok — Don't error if the log file doesn't exist yet.
• notifempty — Skip rotation if the log file is empty.
• create 0640 user group — Create a fresh log file after rotation with the correct permissions.
• postrotate / endscript — Commands to run after rotation, typically to signal a service to reopen its log file.
• sharedscripts — Run the postrotate script once even when multiple log paths match a wildcard.

The postrotate block is what most people skip — then wonder why their service keeps writing to the old rotated file instead of the new one.

Configure Log Rotation for Apache (httpd)

If you installed Apache via dnf install httpd, a basic config usually appears at /etc/logrotate.d/httpd. It may exist but use weak defaults. Here's a solid replacement:

/var/log/httpd/*log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        /bin/systemctl reload httpd.service > /dev/null 2>&1 || true
    endscript
}

Open the file and paste this in:

sudo nano /etc/logrotate.d/httpd

rotate 14 keeps two weeks of access and error logs — enough for most audits without ballooning your storage. The systemctl reload httpd in postrotate tells Apache to close the old log file and open the new one, without a full service restart.

This pairs well with the approach covered in configuring Apache virtual hosts for multi-site setups, where each virtual host generates its own log file and needs matching rotation rules.

Add Rotation for Nginx Logs

Nginx on AlmaLinux writes to /var/log/nginx/ by default. Create a dedicated drop-in:

sudo nano /etc/logrotate.d/nginx

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 nginx adm
    sharedscripts
    postrotate
        nginx -s reopen 2>/dev/null || true
    endscript
}

The nginx -s reopen signal is Nginx's built-in way to gracefully reopen log files after rotation. It's cleaner than a reload and causes zero downtime.

Rotate Custom Application Logs

Many VPS setups run applications that write their own logs — PHP apps, Node.js processes managed with PM2, background workers. Those don't get automatic Logrotate coverage just because they live on the server.

Say your application writes to /var/www/myapp/logs/app.log. Create a custom rule:

sudo nano /etc/logrotate.d/myapp

/var/www/myapp/logs/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    create 0644 www-data www-data
    postrotate
        # Signal your app to reopen logs if it holds them open
        kill -USR1 $(cat /var/run/myapp.pid) 2>/dev/null || true
    endscript
}

The kill -USR1 approach works for any daemon that handles SIGUSR1 as a log-reopen signal. If your application doesn't support that, consider writing logs to a directory and letting the app open a new file per session — then rotation just handles cleanup.

Test Your Configuration Before Relying on It

Don't assume a config file is correct just because it parses without errors. Logrotate has a dry-run flag that shows exactly what it would do without touching anything:

sudo logrotate --debug /etc/logrotate.d/nginx

To force an actual rotation right now — including the postrotate script — run:

sudo logrotate --force /etc/logrotate.d/nginx

Check the output carefully. You want to see lines like rotating log /var/log/nginx/access.log and confirmation that your postrotate script ran.

If the log file is empty and you have notifempty set, Logrotate will skip it. That's expected behavior, not a bug.

Logrotate keeps a state file at /var/lib/logrotate/logrotate.status (the path may vary slightly by AlmaLinux version). It records when each file was last rotated. If a log hasn't rotated despite the schedule, check here first:

cat /var/lib/logrotate/logrotate.status | grep nginx

Handle Mail and System Logs

Postfix mail logs on AlmaLinux go to /var/log/maillog, and the default syslog rotation rule in /etc/logrotate.d/syslog usually covers it. But on a busy mail server — handling newsletters, transactional email, or relaying for multiple domains — weekly rotation may not be enough.

Open /etc/logrotate.d/syslog and change the frequency to daily with a higher rotate count if mail volume warrants it. High-volume Postfix setups can generate 100 MB of mail logs per day without much effort.

For more context on keeping Postfix healthy, the guide to setting up a Postfix mail relay covers the service structure you'll be rotating logs for.

Monitor Disk Usage After Rotation

Setting up Logrotate is only half the job. You also want to confirm it's actually reducing disk pressure over time. A quick check before and after your first forced rotation tells you a lot:

du -sh /var/log/*
df -h /var

If /var/log keeps growing after you've set up rotation, the likely culprits are:

• A service not covered by any Logrotate rule — check with find /var/log -name "*.log" -newer /var/lib/logrotate/logrotate.status
• A postrotate script failing silently, leaving the service writing to the old rotated file
• systemd journal logs accumulating separately — check with journalctl --disk-usage and trim with journalctl --vacuum-size=500M

Disk monitoring alerts are worth setting up alongside this. The tutorial on monitoring VPS disk usage with alerts covers automated alerting so you're not checking manually every week.

Common Pitfalls and How to Avoid Them

Wrong file ownership after rotation. If Apache or Nginx can't write to the new log file, it's almost always a permissions mismatch. Always include a create directive with the correct user and group.

Duplicate rules. If a log file matches both /etc/logrotate.conf and a file in /etc/logrotate.d/, Logrotate will complain or behave unpredictably. Check for overlap with grep -r "access.log" /etc/logrotate*.

Postrotate not running. When using a wildcard path like /var/log/nginx/*.log, you must include sharedscripts. Without it, Logrotate runs the postrotate block once per matched file, which can break commands that don't handle multiple invocations cleanly.

systemd journal eating space separately. Logrotate doesn't touch journald logs. If your system uses Storage=persistent in /etc/systemd/journald.conf, journal logs accumulate in /var/log/journal/ independently. Set a size cap with SystemMaxUse=500M in that same file.

Frequently Asked Questions

Does Logrotate on AlmaLinux use cron or systemd?

AlmaLinux 9 uses a systemd timer (logrotate.timer) by default. AlmaLinux 8 typically uses a daily cron job at /etc/cron.daily/logrotate. Both trigger once per day. Run systemctl status logrotate.timer to confirm which is active on your system.

How do I know if a log file wasn't rotated when it should have been?

Check /var/lib/logrotate/logrotate.status for the last rotation timestamp per file. Then run sudo logrotate --debug /etc/logrotate.d/yourconfig to see what Logrotate thinks should happen next.

Can I rotate logs for a custom application running as a non-root user?

Yes. Use the su user group directive inside your Logrotate config block to tell Logrotate to switch to that user during rotation. This lets you rotate files that root wouldn't normally have write access to.

What's the difference between compress and delaycompress?

compress on its own compresses the rotated file immediately. delaycompress holds off by one cycle, so the most recently rotated file stays uncompressed. This matters when a service might still have a file handle open to the rotated log shortly after rotation.

My disk is already full. Can I use Logrotate to fix it immediately?

Not directly — you need to free space first. Find the largest log files with du -sh /var/log/* | sort -h, then manually truncate safe targets with truncate -s 0 /var/log/somefile.log. Once you have breathing room, set up Logrotate properly so it doesn't happen again. Also see our post on what to monitor on a VPS to catch disk pressure before it becomes an emergency.