Set log retention for each system that writes logs. The system journal, application files and container logging can have separate limits. Reducing one does not necessarily stop another from filling the disk.
Measure before choosing a limit
journalctl --disk-usage
sudo journalctl -u example.service --since "1 hour ago" --no-pagerThe first command reports journal storage. The second inspects one service over a recent interval; replace the example name. Look for repeated errors that explain rapid growth. Fixing a tight error loop is more useful than continually deleting its output.
Choose size and time requirements
systemd-journald supports storage and retention settings, including size controls for persistent and runtime journals. Review the manual for your installed version and use a configuration drop-in rather than silently replacing distribution defaults. Decide whether logs must survive a reboot.
| Question | Reason |
|---|---|
| How quickly is an incident noticed? | Logs need to cover the investigation interval |
| How fast does the service write? | A size limit can remove history before a time limit |
| Do logs contain personal data or secrets? | Access and collection should be limited |
| Is off-host evidence needed? | Local logs disappear with the machine |
| How are application files rotated? | Applications may need to reopen their output |
Verify rotation in the actual application
- Save logs needed for an active incident before cleanup.
- Set the supported retention mechanism for each log source.
- Confirm that the application continues writing after rotation.
- Check that new entries are timestamped and attributable to the right service.
- Monitor disk growth and confirm the retained history meets your requirement.
Avoid indiscriminate truncation or deletion of files still in use. It can remove evidence without solving the producer problem. Scrub tokens from application output at the source rather than relying on short retention to protect them.
Use disk-full diagnostics to locate the actual growth and monitoring to alert before the next capacity incident.
Sources and references
Hosting documentation. Publication and update dates reflect this edition.
Related articles
- Linux Disk Full: Checking Space, Inodes and the Right FilesystemFind the exhausted filesystem before removing data or expanding a VPS disk.2 min read
- Diagnosing a Linux Service That Will Not StartUse systemd status and the service journal to find the first failure before changing restart settings.2 min read
- VPS Monitoring: CPU, Memory, Disk and Useful AlertsConnect operating-system metrics to application symptoms and test the alert path before relying on it during an outage.3 min read
