Configure Logrotate on cPanel Servers: Keep Logs Manageable

Why Log Files Quietly Fill Up cPanel Servers

Most cPanel servers run fine for months — until one morning you get a support alert or your site throws a 500 error and disk usage is sitting at 98%. Nine times out of ten, log files are the culprit. Apache access logs, error logs, email logs, MySQL slow query logs: they accumulate fast on a busy shared or VPS server, and the default rotation settings aren't always enough.

Logrotate is the standard tool for keeping this under control. It ships on every RHEL-family Linux system — which is what cPanel runs on, whether that's AlmaLinux 8/9, Rocky Linux, or CloudLinux. The catch is that cPanel installs its own rotation rules, and those sometimes conflict with or override system-level ones. This guide covers how to configure Logrotate on cPanel servers correctly, without stepping on anything cPanel manages itself.

Before You Start: Understand What cPanel Already Rotates

cPanel ships with its own rotation config at /etc/logrotate.d/cpanel and handles some logs through WHM's built-in log management. Before writing your own rules, find out what's already covered.

List the existing rotation configs:

ls /etc/logrotate.d/

You'll typically see entries for cpanel, apache, mysql, and syslog. Open the cPanel file to see what it covers:

cat /etc/logrotate.d/cpanel

cPanel handles rotation for /usr/local/cpanel/logs/access_log, /usr/local/cpanel/logs/error_log, and its stats logs. Don't write duplicate rules for these — you'll end up with conflicts or double-compressed archives wasting disk space.

What you'll likely need to manage yourself: per-domain Apache logs, custom application logs, and MySQL slow query logs if you've enabled them.

Understanding the Logrotate Config Format

Every Logrotate config follows the same structure. Here's a minimal working example:

/var/log/httpd/*access_log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/httpd/httpd.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

What each directive does:

• daily / weekly / monthly — How often rotation runs.
• rotate 14 — Keep 14 rotated copies before deleting. Adjust based on your disk budget.
• compress — Gzip old log files. A busy Apache log can shrink to 5–10% of its original size.
• delaycompress — Skip compression on the most recently rotated file. Useful if a process still has the file handle open.
• missingok — Don't error if the log file doesn't exist yet.
• notifempty — Skip rotation if the file is empty.
• sharedscripts — Run the postrotate script once, even when multiple files match the glob.
• postrotate — Command to run after rotating. Apache needs a HUP signal to reopen its log file handles.

Step 1: Locate the Per-Domain Apache Logs

On a cPanel server, Apache logs for individual domains live at:

/home/USERNAME/logs/

Each domain gets its own access and error log. On a shared server with dozens of accounts, those directories can hold hundreds of files — some untouched for months.

Check how much space they're consuming across all accounts:

du -sh /home/*/logs/ | sort -rh | head -20

This gives you a ranked list of the worst offenders. Any single account's logs directory over 500MB needs attention immediately — especially on a Hostperl VPS with a fixed disk allocation.

Step 2: Create a Custom Logrotate Config for Domain Logs

Create a new file under /etc/logrotate.d/. Don't edit the cPanel-managed files — they get overwritten during cPanel updates.

nano /etc/logrotate.d/cpanel-domain-logs

Add the following:

/home/*/logs/*log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    sharedscripts
    su root root
    postrotate
        /usr/sbin/apachectl graceful > /dev/null 2>&1 || true
    endscript
}

The su root root directive matters on cPanel servers running AlmaLinux or CloudLinux with strict permission checking. Without it, Logrotate may refuse to rotate files owned by other users.

Save and exit.

Step 3: Test the Configuration Without Actually Rotating

Always dry-run before applying. The --debug flag shows exactly what Logrotate would do:

logrotate --debug /etc/logrotate.d/cpanel-domain-logs

Scan the output for any error or warning lines. Common problems at this stage:

• Permission denied errors — check the su directive and file ownership
• "Glob pattern matched no files" — verify the log path with ls /home/*/logs/
• Postrotate script failures — test the Apache graceful command manually first

If the debug output looks clean, trigger a one-off rotation to verify the full process:

logrotate --force /etc/logrotate.d/cpanel-domain-logs

Then confirm compressed archives appeared:

ls -lh /home/someuser/logs/

You should see .gz files alongside the current log.

Step 4: Handle MySQL Slow Query Logs

If you've enabled MySQL's slow query log — which you should on any busy server for performance troubleshooting — it needs its own rotation rule. On cPanel systems the slow query log is typically in /var/lib/mysql/, or set explicitly in /etc/my.cnf.

Find the exact path with:

mysql -e "SHOW VARIABLES LIKE 'slow_query_log_file'"

Then create a rotation config:

nano /etc/logrotate.d/mysql-slow-query

/var/lib/mysql/*-slow.log {
    weekly
    rotate 4
    compress
    delaycompress
    missingok
    notifempty
    su mysql mysql
    postrotate
        if [ -f /var/lib/mysql/mysql.pid ]; then
            mysqladmin flush-logs
        fi
    endscript
}

mysqladmin flush-logs tells MySQL to close and reopen its log files after rotation. Without it, MySQL keeps writing to the old file descriptor even after Logrotate has moved the file.

Step 5: Check the Logrotate Cron Schedule

Logrotate runs via cron, typically once a day. Confirm the cron entry exists:

cat /etc/cron.daily/logrotate

You should see a script calling /usr/sbin/logrotate /etc/logrotate.conf. The main config at /etc/logrotate.conf includes the /etc/logrotate.d/ directory, so your custom files get picked up automatically.

To run rotation at a specific time rather than as part of the general daily cron batch, add a dedicated crontab entry:

0 2 * * * root /usr/sbin/logrotate /etc/logrotate.conf > /dev/null 2>&1

2am is a sensible default — low traffic for most sites, and it means fresh logs are ready at the start of the business day.

Step 6: Verify Disk Recovery After First Full Rotation

After the first automated rotation runs, check disk usage again:

df -h /
du -sh /home/*/logs/ | sort -rh | head -10

Compare against your baseline from Step 1. On servers where log rotation has never been configured properly, recovering several gigabytes on the first pass is common. That headroom can buy you weeks or months before a capacity upgrade becomes necessary.

If you're already tracking disk usage proactively, our tutorial on monitoring disk usage with automated alerts covers how to get notified before logs become a crisis rather than after.

Ongoing Maintenance: Reviewing Rotation State

Logrotate keeps a state file at /var/lib/logrotate/logrotate.status (sometimes /var/lib/logrotate.status depending on the distribution). This tracks when each log was last rotated.

cat /var/lib/logrotate/logrotate.status

If a log shows a date from several months ago despite a daily config, something is blocking rotation — usually a permission issue or a path mismatch. Cross-check the file path in your config against what's actually on disk.

Once rotation is working cleanly, pairing it with a daily digest gives you visibility into what the server is doing without manually checking every log. Our guide on setting up Logwatch digests on cPanel is a natural next step.

Common Pitfalls on cPanel Servers

A few things that catch people out specifically in cPanel environments:

• cPanel rewrites logrotate configs on updates. Never edit files in /etc/logrotate.d/ that cPanel owns. Create new files with distinct names for your custom rules.
• CloudLinux CageFS. If CageFS is enabled, log file paths inside user environments may differ from system-level paths. Test rotation targets carefully.
• EasyApache and log paths. After an EasyApache 4 update, Apache's log paths can shift. Verify that /etc/logrotate.d/httpd still points to the right location after major cPanel or EA4 updates.
• WHM's log retention settings. WHM has its own bandwidth and statistics log retention controls under WHM > Server Configuration > Statistics Software Configuration. These run separately from Logrotate — make sure the two aren't working against each other.

If you're managing multiple client sites on a single VPS and log hygiene keeps becoming a recurring problem, it may be worth asking whether the setup itself still makes sense. That kind of recurring operational friction is often one of the earlier signals that shared hosting is holding you back.

Frequently Asked Questions

Will configuring Logrotate break my cPanel installation?

Not if you create your own config files in /etc/logrotate.d/ rather than editing files cPanel owns. cPanel updates can overwrite its own rotation files, but they won't touch files with different names that you've created.

How many rotated copies should I keep?

Seven days is a reasonable default for most hosting environments. If you need logs for compliance or auditing, increase the rotate value and make sure you have enough disk to match. Gzip compression typically reduces log files to 5–15% of their original size, so keeping 30 compressed copies is usually feasible.

My Apache log files aren't shrinking after rotation. What's wrong?

The most common cause is a missing or failing postrotate script. Apache needs a HUP signal or graceful restart to close its old file handle and start writing to the new log file. Run logrotate --force --debug /etc/logrotate.d/cpanel-domain-logs and look for postrotate errors in the output.

Can I run Logrotate manually to test it without waiting for the cron job?

Yes. Use logrotate --force /etc/logrotate.d/your-config-file to trigger an immediate rotation regardless of schedule. Use --debug first to preview what would happen without making any changes.

Does this work on CloudLinux as well as standard AlmaLinux cPanel installs?

Yes, Logrotate works the same way on CloudLinux. The main difference is CageFS file path visibility. Always verify the actual paths on your specific server rather than assuming standard locations apply.