Configure Logrotate on Ubuntu VPS: Keep Logs Under Control

Why Log Rotation Matters on a VPS

Left unchecked, log files grow. Slowly at first, then fast enough to fill your disk completely — and when that happens, your web server stops accepting connections, your database refuses writes, and your mail queue stalls. For VPS customers running live sites, a full disk is rarely a dramatic event. It just quietly breaks everything at once.

Logrotate is the standard tool for managing this on Ubuntu. It ships pre-installed and handles rotation for most system services automatically — but the default configuration often isn't enough for a busy hosting environment. This tutorial walks you through understanding what's already running, tuning it for your workload, and adding custom rules for services like Nginx, Apache, and MySQL.

If you're already tracking disk usage with alerts (which you should be), this pairs well with monitoring Ubuntu VPS disk usage with alerts — the two together give you both prevention and early warning.

How Logrotate Works: The Short Version

Logrotate runs daily via a cron job or systemd timer. It reads a main configuration file at /etc/logrotate.conf, then processes any additional files dropped into /etc/logrotate.d/. Each file in that directory defines rotation rules for one or more log paths.

The tool supports rotation by size, by age, or both. After rotating, it can compress old logs, delete logs beyond a certain count, send a signal to reload a service, or run a custom script. Most of the complexity lives in those post-rotation actions — getting them right is what separates a working setup from one that rotates logs but breaks your application in the process.

Check What's Already Configured

Before adding anything, see what Logrotate is already managing on your server.

ls /etc/logrotate.d/

On a freshly provisioned Ubuntu 24.04 VPS you'll typically see entries for apt, dpkg, rsyslog, ufw, and a few others. If you've installed Nginx or Apache via apt, their configs are usually added automatically — but open them anyway to confirm the settings match your actual traffic load.

To preview what Logrotate would do without actually rotating anything, run a dry-run against the full configuration:

sudo logrotate -d /etc/logrotate.conf

This outputs every decision it would make. Look for warnings about missing files or permission errors — those point to configs referencing log paths that don't exist yet, or logs owned by a different user than Logrotate expects.

The Global Configuration File

Open /etc/logrotate.conf to review your global defaults:

sudo nano /etc/logrotate.conf

A sensible baseline for a VPS hosting one or more websites looks like this:

# Rotate weekly by default
weekly

# Keep 4 weeks of logs
rotate 4

# Create new (empty) log file after rotation
create

# Compress rotated logs
compress

# Delay compression one cycle (so the current log isn't compressed immediately)
delaycompress

# Don't throw an error if the log file is missing
missingok

# Don't rotate empty log files
notifempty

# Include per-service configs
include /etc/logrotate.d

delaycompress is worth calling out. Without it, the just-rotated file gets compressed immediately — which matters for services like Nginx that may still have it open briefly after receiving the signal to reopen logs. Keeping compression one cycle behind avoids that edge case.

Configure Logrotate on Ubuntu VPS for Nginx

If Nginx's config was installed automatically, check it first:

cat /etc/logrotate.d/nginx

The default is often fine for low-traffic sites, but on a busier server you'll want to rotate by size rather than by day — a 100 MB access log is a lot to sift through when something goes wrong. Here's a production-ready version:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 $(cat /var/run/nginx.pid)
        fi
    endscript
}

The postrotate block sends a USR1 signal to Nginx, telling it to close the old log file handle and open a fresh one. Without this, Nginx keeps writing to the already-rotated file. The sharedscripts directive ensures the postrotate script runs once even when multiple log files match the glob.

Apache Log Rotation

Apache on Ubuntu usually manages its own log rotation via a pipe to rotatelogs, but if you're running a custom Apache setup — configured manually rather than through a control panel — you'll want a Logrotate config that covers your vhost logs too.

/var/log/apache2/*.log
/var/log/apache2/sites/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        if invoke-rc.d apache2 status > /dev/null 2>&1; then
            invoke-rc.d apache2 reload > /dev/null 2>&1
        fi
    endscript
}

The second path — /var/log/apache2/sites/*.log — covers per-domain logs organised into a subdirectory, which is common on servers running multiple client sites.

MySQL and MariaDB Log Rotation

MySQL's slow query log and general query log can balloon quickly if you've enabled them for debugging and then forgotten to turn them off. A dedicated config for MySQL should use a flush command rather than a simple process signal:

/var/log/mysql/*.log {
    daily
    rotate 7
    missingok
    compress
    delaycompress
    notifempty
    create 640 mysql adm
    postrotate
        test -x /usr/bin/mysqladmin || exit 0
        MYADMIN="/usr/bin/mysqladmin --defaults-extra-file=/etc/mysql/debian.cnf"
        if [ -f /var/run/mysqld/mysqld.pid ]; then
            $MYADMIN flush-error-log flush-engine-log flush-general-log flush-slow-log 2>/dev/null || true
        fi
    endscript
}

This uses the Debian maintenance credentials stored in /etc/mysql/debian.cnf — no hardcoded passwords required.

Rotating Application Logs Outside /var/log

Many PHP applications, Node apps, and custom scripts write logs to paths like /var/www/mysite/logs/ or /home/user/app/storage/logs/. Logrotate handles these just as easily — you just need to create a config file for them.

sudo nano /etc/logrotate.d/mysite

/var/www/mysite/logs/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    su www-data www-data
    create 0644 www-data www-data
}

The su directive matters here. If Logrotate runs as root but the log is owned by www-data, it needs explicit permission to touch it. The su line tells Logrotate to switch to that user before doing anything with the file.

On servers running multiple sites, it's also worth reviewing your Apache virtual host configuration to confirm each domain logs to its own file — rotating one large shared log is far less useful than per-domain rotation.

Size-Based Rotation for High-Traffic Sites

Daily rotation works for most sites, but if a single endpoint gets hammered — a product page going viral, a bot scraping your sitemap — your access log can hit several gigabytes in hours. Use size to trigger rotation on file size rather than age:

/var/log/nginx/access.log {
    size 100M
    rotate 10
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        kill -USR1 $(cat /var/run/nginx.pid 2>/dev/null) 2>/dev/null || true
    endscript
}

Size-based rotation runs outside the normal daily schedule. Logrotate only checks file sizes when it's triggered — so for size limits to be responsive, you'll need to run it more frequently. Add an hourly cron entry:

sudo crontab -e

0 * * * * /usr/sbin/logrotate /etc/logrotate.conf

Test and Force a Manual Rotation

After writing or editing any config, always test before relying on it. The -d flag runs a dry-run against a specific file:

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

To force a rotation right now — useful for verifying that the postrotate script actually works — add --force:

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

Then confirm the old log was compressed, a new empty file was created with the right permissions, and the service is writing to it:

ls -lh /var/log/nginx/
tail -f /var/log/nginx/access.log

If tail shows nothing after a test request, the postrotate signal didn't work. Double-check the PID file path — on some Ubuntu builds it's at /run/nginx.pid rather than /var/run/nginx.pid.

Check the Logrotate Status File

Logrotate tracks when each log was last rotated in /var/lib/logrotate/status. This is useful for auditing, especially after a server migration.

cat /var/lib/logrotate/status

Each line shows the log path and the last rotation date. If a log you expected to rotate daily hasn't changed in a week, the config probably isn't being picked up — check for syntax errors with the -d flag, or look for permission issues on the log directory.

The hosting migration guide covers what to audit post-move, and log rotation state is one of those things that regularly gets overlooked.

Common Mistakes and How to Avoid Them

• No postrotate signal: The log gets rotated but the service keeps writing to the old (now renamed) file. Always include a reload or signal step for running services.
• Wrong file ownership: Logrotate can't create the new log file because it lacks permission. Use the su directive or ensure the create directive specifies the correct owner and group.
• Missing missingok: If a log file doesn't exist yet — maybe a service hasn't generated any traffic — Logrotate will error without this directive.
• Compressing the active log: Omitting delaycompress can cause services that still have the file open to write to a gzip-compressed handle, producing garbage logs.
• Overlapping glob patterns: Two config files matching the same log path causes unpredictable behaviour. Run logrotate -d /etc/logrotate.conf to spot duplicates.

Frequently Asked Questions

How often does Logrotate run by default on Ubuntu?

Once per day, triggered by a systemd timer or cron job in /etc/cron.daily/logrotate. For size-based rotation to respond quickly, add an hourly cron entry as shown above.

Will Logrotate restart my web server or database automatically?

Only if you include a postrotate block in the config. Logrotate itself just renames files — the postrotate script is what signals the running service to reopen its log file handle.

How do I know if Logrotate is actually running?

Check /var/lib/logrotate/status for recent timestamps, or search your system logs directly: grep logrotate /var/log/syslog | tail -20.

Can I use Logrotate for logs not in /var/log?

Yes. Any absolute path works in a Logrotate config. Use the su directive if the log is owned by a non-root user, or you'll run into permission errors.

What happens if Logrotate runs and my service is down?

If the postrotate script tries to signal a PID that doesn't exist, it will error. Use conditional checks in your postrotate block — as shown in the Nginx example — to handle this gracefully.