Linux log rotation and retention are easiest to manage when you treat them as a storage policy, not just a cleanup task. The goal is to preserve enough history for troubleshooting while ensuring that a busy service or unexpected error burst cannot consume the space needed by the operating system.
That means checking both systemd-journald and traditional log files, setting realistic storage limits, and deciding which records should be forwarded elsewhere. The right settings depend on log volume, available disk space, operational needs, and any applicable organizational or contractual requirements.
Start by measuring log use and available headroom
Before changing settings, find out what is using space and whether /var is a separate filesystem. Check filesystem capacity with df -h /var, the journal’s current usage with journalctl --disk-usage, and the size of traditional logs with du -sh /var/log. If a directory is unusually large, inspect it further before deleting or rotating files.
Look at usage over time, not just once. A service that writes logs steadily has a different storage profile from one that produces a large burst during a failure. Estimate normal daily growth and consider how much free space must remain for package operations, temporary files, and other services. Leave headroom rather than setting log limits equal to all available space.
If you are reviewing broader storage needs, the Linux server capacity planning guide can help put filesystem limits in context.
Set a bounded systemd journal policy
Systemd-journald manages records queried with journalctl. Its limits are separate from rules for files such as application logs under /var/log. Persistent journal data is commonly stored under /var, so an unlimited or poorly bounded journal can contribute to filesystem pressure.
In the journald configuration, set a maximum journal size, preserve free space, and optionally specify a maximum retention age. For example, a host with sufficient capacity might start with [Journal] SystemMaxUse=500M; SystemKeepFree=1G; MaxRetentionSec=14day. These are illustrative values, not universal recommendations. Choose values based on measured log growth, the size of /var, and how much local history administrators need.
SystemMaxUse caps journal disk use, while SystemKeepFree asks journald to keep a specified amount of space available. The effective limit can be constrained by whichever setting is more restrictive for the filesystem. MaxRetentionSec sets an age limit, but an age target does not replace a size ceiling when log volume spikes. Check the journald configuration reference for supported options and behavior on your installed systemd version.
Configuration may be placed in the main file or a drop-in, depending on the distribution and local configuration practice. After changing it, apply the configuration using the method supported by the host, then recheck journal usage and available space. Use journalctl --vacuum-size=500M or an age-based vacuum command only when you intentionally want to remove archived journal data; vacuuming is not a substitute for setting ongoing limits.
Use logrotate for traditional log files
Logrotate handles files managed by its configuration, often including application logs and logs written through syslog. It does not set the systemd journal’s storage limit. Review the global configuration and the application-specific rules so you know which files are actually covered.
A sample rule could use daily; rotate 14; maxsize 100M; compress; missingok; notifempty. Here, daily is the regular check interval, rotate sets how many archived files to retain, and maxsize can trigger rotation when the file exceeds the specified size. These example settings should be adapted to the log’s activity and the organization’s history needs.
Logrotate runs when its scheduled job or timer invokes it, so a size condition does not necessarily rotate a file at the instant it crosses the threshold. Also, size-based and time-based options can interact; check the installed version’s behavior and the logrotate manual before combining directives. Some applications need a reload or a specific post-rotation action to reopen their log files. Confirm the application’s requirements instead of assuming that every file can be handled identically.
Reviewing Linux monitoring approaches can also help you alert on filesystem usage before a log problem becomes an outage.
Choose retention based on operational needs
There is no single correct number of days for every Linux server. A short local window may be suitable for a small system whose important records are forwarded and verified elsewhere. A longer local window may help a server that is intermittently connected or needs more history available during investigation. In either case, pair a time target with a storage ceiling so unusually noisy logs cannot grow without limit.
As a starting point, an administrator might retain a week or two of selected local logs on a tightly constrained host, or several weeks where space and troubleshooting needs support it. Treat these as examples to evaluate, not prescribed periods. Confirm retention expectations with the people responsible for incident response and organizational requirements before setting a policy.
Forward important logs, then verify delivery
Centralized logging keeps selected records beyond the local server’s storage window and can make it easier to investigate events across systems. With rsyslog, forwarding can be configured for the records your operations or security teams need. The rsyslog forwarding guide describes the basic approach.
Do not treat forwarding as a reason to remove all local safeguards. Network interruptions, receiver problems, or configuration errors can interrupt delivery. Decide what should happen during a connection outage, whether messages can be buffered, and how the team will notice a forwarding failure. Then confirm that records arrive at the destination and that timestamps, host identity, and useful fields remain intact.
Apply a tiered policy: keep a bounded troubleshooting window locally, forward selected logs to a managed destination, and periodically verify both local limits and remote receipt. If backups are part of your continuity plan, consider how log archives fit into the wider process described in Linux server backup planning.
Check the result after changes
- Confirm that /var has adequate free space and that journal use stays within the intended ceiling.
- Run logrotate in debug mode to review the actions it would take before relying on a new rule.
- Check that rotated files are compressed and that applications continue writing to their active logs.
- Verify that the central logging destination receives the expected records, including after a connectivity interruption or service restart where practical.
- Set an alert for filesystem pressure early enough to investigate before services are affected.
Frequently asked questions
How do I check how much space systemd journal logs are using?
Run journalctl --disk-usage to see the journal’s reported disk use. Compare it with df -h /var to understand the filesystem’s overall capacity and free space.
What is the difference between journald retention and logrotate?
Journald limits apply to the systemd journal queried with journalctl. Logrotate manages configured log files, such as many application and syslog files. Both may need policies if both types of logs use space under /var.
How do I rotate logs based on size instead of time?
Use a size-based logrotate rule and ensure the scheduled logrotate job runs often enough for your needs. Check how size options interact with time-based directives on your installed version, and test the configuration before depending on it.
What should I check after changing log rotation settings?
Check filesystem headroom, journal usage, logrotate’s debug output, application logging after rotation, and successful delivery to any central logging destination. Keep monitoring in place so you can catch unexpected growth or forwarding failures.
Conclusion
Keeping /var healthy requires separate, bounded policies for the systemd journal and traditional log files, plus a plan for preserving important records off-host. Measure actual growth, test changes, and verify that local cleanup and centralized delivery work as intended. Linux Consulting Services offers Linux consulting, monitoring, and technical support; contact the team at (904) 658-0777 to discuss your Linux logging and operations needs.