Log files have a bad habit of growing in the background. One day they are harmless. A week later they are eating disk space and turning simple troubleshooting into a mess.
Logrotate on Linux fixes that with a small, steady routine. It rotates old logs, compresses archives, removes stale files, and creates fresh ones automatically. The setup is not hard, but the moving parts matter, especially if the goal is a clean, reliable system.
What Logrotate does on Linux
Logrotate manages log files that live on disk. It checks the rules, decides whether to rotate the log, renames the current file, and starts a new one. Older copies can be compressed and deleted after a set number of rotations.
That matters for Linux log rotation because server logs do not stop growing on their own. System logs, web logs, and app logs can fill storage slowly, then all at once. Logrotate keeps that buildup under control.
How log rotation keeps server logs under control
A rotated log usually becomes something like myapp.log.1. Older copies move down the chain, such as .2 and .3, until the configured limit is reached. If compression is enabled, those older copies are stored as smaller archive files.
The active log is then recreated as a fresh file, so the service can keep writing without building a giant single file.
When Logrotate is the right tool, and when it is not
Logrotate works best for services that write to normal files under /var/log another disk path. That still covers a large share of Linux systems.
It is less useful when a service sends logs to a journal, a container runtime, or a remote logging system with its own retention rules. Even then, many mixed environments still keep file-based logs, and that is where Logrotate fits best. For a broader look at the basics, Dash0’s guide to Linux log rotation gives a good background.
Before you start, check whether Logrotate is already installed
On many Linux systems, Logrotate is already there. Checking first avoids pointless package changes and shows which version is installed.
Install Logrotate on Ubuntu, Debian, RHEL, Fedora, and Arch
This quick table covers the common install commands:
| Distribution | Command |
|---|---|
| Ubuntu and Debian | sudo apt update && sudo apt install logrotate |
| RHEL and Fedora | sudo dnf install logrotate |
| Arch Linux | sudo pacman -S logrotate |
Many systems will report that the package is already installed, which is normal.
Confirm the package and find the main files
Run logrotate --version to confirm the tool is available. As of April 2026, the current upstream release is 3.22.0, though distro packages can lag a bit.
Three paths matter most:
/etc/logrotate.confis the main config file./etc/logrotate.d/holds separate rules for apps and services./var/lib/logrotate/statusstores the last rotation time for each tracked log.
On some distros, the state file is named /var/lib/logrotate.status, so a small path difference is not unusual.
How Logrotate works, from the main config file to app-specific rules
Logrotate uses a layered setup. Global defaults live in /etc/logrotate.conf, and app-specific rules sit in /etc/logrotate.d/. A local rule can override a global default when needed.
That split is why Logrotate is easy to maintain. One service can rotate daily, another weekly, and both can still inherit the same compression or file-creation behavior. Baeldung’s walkthrough on rotating logs shows the same additive structure in a clear way.
What to look for in /etc/logrotate.conf
Common directives are plain once the names click. daily, weekly, and monthly set the schedule. rotate 4 keeps four old copies. compress shrinks archives, while delaycompress waiting one cycle before compressing the newest rotated file.
create makes a new log after rotation. missingok skips a missing file without error. notifempty avoids rotating an empty file. include loads rules from /etc/logrotate.d/. su root adm tells Logrotate which user and group to use for some operations.
Defaults vary by distro, but the meaning stays the same.
SEE ALSO: How to Use Google Gemini Mini Without Google Account: The Easiest Method Explained
Why It /etc/logrotate.d/ is usually the safest place for custom rules
Editing the main file works, but it makes later troubleshooting harder. A dedicated file in /etc/logrotate.d/ is cleaner and easier to inspect.
Package updates also tend to leave custom files alone. That keeps local changes separate from distro-managed defaults, which is usually the safer path.
How to create a Logrotate config for your own log file
A simple custom example is enough to build from. Suppose an app writes to /var/log/myapp.log. A dedicated rule file at /etc/logrotate.d/myapp keeps the setup contained.
A simple Logrotate config example you can adapt
Use a rule like this:
/var/log/myapp.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 0640 root root
}
Each line has a clear job. daily checks the file once per day. rotate 7 keeps a week’s worth of old copies. compress saves space, and delaycompress keeps the most recent archive uncompressed for one cycle, which can help with quick checks. missingok prevents errors if the log is absent. notifempty skips blank files. create 0640 root root creates a fresh file with sane permissions and ownership.
For most beginner setups, that is a solid starting point. This step-by-step log rotation example shows similar patterns for application logs.
When to use create, copytruncate, and It postrotate
create is usually the better default. It works well when the app can reopen the new log file after rotation.
copytruncate is different. It copies the current log to a rotated file, then truncates the original in place. That can help when an app keeps the file open and never reopens it. The trade-off is simple: a few log lines can be missed during the copy-and-truncate window.
postrotate runs commands after rotation. A common use is reloading a service so it starts writing to the new file:
postrotate
systemctl reload myapp >/dev/null 2>&1 || true
endscript
If a service stops writing after rotation, the first thing to check is whether it needs a reload or signal.
How to test Logrotate safely before you trust it
A config that looks right can still fail on a live system. Testing saves time and avoids surprises.
Use debug mode to catch mistakes early
Run sudo logrotate -d /etc/logrotate.conf. Debug mode shows what Logrotate would do, which files match, and which rules are skipped. It does not rotate files.
Look for bad paths, syntax errors, and skipped logs. If a rule looks valid but nothing matches, the path is often the problem.
Force a rotation and check the status file
Run sudo logrotate -f /etc/logrotate.conf to force a real rotation. This changes files, so it is best used on a test log or during a safe window.
Then check the state file with sudo cat /var/lib/logrotate/status. That file shows when a log was last rotated. If rotation is not happening on schedule, the status file helps separate a rule problem from a scheduling problem. For more troubleshooting examples, Shell & Coin’s practical guide has useful real-world cases.
How logs rotate automatically, and what to check if they do not
Logrotate usually runs once a day through the system scheduler. On many systems, that comes from a cron job such as /etc/cron.daily/logrotate. On others, a systemd timer handles it.
Where automatic runs usually come from on Linux
The rule’s frequency and the scheduler are not the same thing. A rule may say weekly, but Logrotate still needs the system to launch it regularly, usually once per day.
That daily run gives Logrotate a chance to decide which logs are due.
How to check cron or crond if rotation stopped
On Debian and Ubuntu, check systemctl status cron. On RHEL and Fedora, check systemctl status crond.
If that service is inactive or failed, auto-rotate jobs will not run, even if the config file is perfect.
Common Logrotate problems and the fixes that save time
Most Logrotate failures fall into a few buckets. The pattern matters more than the exact distro.
Permission errors, missing files, and wrong paths
System logs often need root access. If a rule targets files owned by another user or group, su inside the rule can help.
A missing log file is usually harmless if missingok is set. A wrong path is worse because the rule looks fine but never matches a real file.
Syntax mistakes, insecure directories, and failed scripts
When a rule fails, debug mode is the first place to look. Typos in directives, missing braces, or bad indentation are common enough.
Another frequent warning involves insecure parent directories, especially world-writable locations. That is a sign to review the log path and ownership, not to blindly change permissions. This note on insecure log paths and copytruncate covers the warning well.
Broken postrotate Commands also cause trouble. If the script fails, the rotation may complete but the service may keep writing to the old file.
Do not “fix”
/var/logpermissions by guesswork. Check the system’s defaults first, then change only what the warning points to.
Quick answers to common Logrotate questions
Is Logrotate installed by default?
Often, yes. Many Linux distributions ship it already.
How often does it run?
Usually once a day through cron or a systemd timer.
Does it delete old logs?
Yes, if the rule says to keep only a set number, such as rotate 7.
What does the status file do?
It records the last time each log was rotated.
Why would a valid rule still not rotate a log?
Common reasons include a bad path, permission issues, an inactive scheduler, or a service that never reopens its log file.
Conclusion
A working Logrotate setup is not complicated once the pieces line up. Check the package, review the main config, and add a focused rule in /etc/logrotate.d/, test with debug mode, and confirm the scheduler is still running.
That small bit of setup pays off later. Logrotate on Linux is one of those quiet tools that keeps disk space problems from becoming midnight problems.
