{"id":4289,"date":"2026-09-12T15:40:44","date_gmt":"2026-09-12T10:10:44","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/how-to-configure-logrotate-systemd-journalctl-linux\/"},"modified":"2026-09-12T15:40:44","modified_gmt":"2026-09-12T10:10:44","slug":"how-to-configure-logrotate-systemd-journalctl-linux","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/how-to-configure-logrotate-systemd-journalctl-linux\/","title":{"rendered":"How to Configure Logrotate and Manage systemd Journalctl to Prevent Full Disks"},"content":{"rendered":"
\n Quick Technical Answer:<\/strong><\/p>\n

\n To immediately reclaim disk space from bloated logs on Linux, vacuum the systemd journal using sudo journalctl --vacuum-size=200M<\/code>. Then, cap future growth permanently by setting SystemMaxUse=250M<\/code> in \/etc\/systemd\/journald.conf<\/code> and restarting with sudo systemctl restart systemd-journald<\/code>. For application logs in \/var\/log\/<\/code>, create a rule in \/etc\/logrotate.d\/myapp<\/code> specifying daily<\/code>, rotate 7<\/code>, compress<\/code>, delaycompress<\/code>, and copytruncate<\/code>.\n <\/p>\n<\/div>\n

The Silent Server Killer: How Unchecked Logs Crash Production Applications<\/h2>\n

One of the most frequent causes of sudden web server downtime, MySQL database corruption, and crashed Nginx instances is running out of disk space (No space left on device<\/code>). On a budget cloud VPS with 20GB to 50GB of NVMe disk storage, chatty web servers, security scanners, and container outputs can easily generate gigabytes of log entries every single week.<\/p>\n

When the root partition reaches 100% capacity, MySQL cannot allocate temporary tables, PHP cannot write session files, and SSH login attempts may fail because PAM cannot create session tokens. Even worse, if millions of tiny log files are created, the filesystem can exhaust available inodes<\/strong> even when physical gigabytes appear free.<\/p>\n

By pairing logrotate<\/strong> (for file-based application logs) with systemd-journald retention caps<\/strong> (for binary system logs), you ensure a self-cleaning server that maintains predictable, fixed disk usage indefinitely.<\/p>\n

Step 1: Emergency Diagnosis: Finding What Is Consuming Your Disk<\/h2>\n

When investigating high disk consumption, inspect both physical block storage and filesystem inode allocation:<\/p>\n

# Check physical disk space usage\ndf -h \/\n\n# Check filesystem inode consumption\ndf -i \/\n\n# Identify the largest log files in \/var\/log\nsudo du -ah \/var\/log | sort -rh | head -n 15<\/code><\/pre>\n
Step 2: Reclaiming Space from systemd journalctl<\/h2>\n
Modern Linux stores system daemon logs in binary format under \/var\/log\/journal\/<\/code>. On high-traffic systems, this directory frequently balloons to 4GB or more.<\/p>\n
# Check current disk space consumed by systemd journal\njournalctl --disk-usage\n\n# Immediately prune logs older than 7 days\nsudo journalctl --vacuum-time=7d\n\n# Or prune logs down to a strict size limit (e.g. 200 Megabytes)\nsudo journalctl --vacuum-size=200M<\/code><\/pre>\n
To enforce this size cap permanently so logs never exceed your threshold again, edit the journal configuration:<\/p>\n
sudo nano \/etc\/systemd\/journald.conf<\/code><\/pre>\n
Uncomment and configure the following directives:<\/p>\n
[Journal]\nStorage=persistent\nSystemMaxUse=250M\nSystemKeepFree=1G\nMaxRetentionSec=1month<\/code><\/pre>\n
Apply the changes by restarting the journal daemon:<\/p>\n
sudo systemctl restart systemd-journald<\/code><\/pre>\n
Step 3: Configuring Custom logrotate Rules for Applications<\/h2>\n
While systemd manages binary unit logs, web services like Nginx, Apache, Redis, and custom Python\/Node applications write plain text files directly into \/var\/log\/<\/code>. logrotate<\/strong> runs automatically via a daily cron\/timer job to compress and rotate these files.<\/p>\n
Let us create an optimized rotation rule for a custom web application:<\/p>\n
sudo nano \/etc\/logrotate.d\/mywebapp<\/code><\/pre>\n
Insert the following production configuration:<\/p>\n
\/var\/log\/mywebapp\/*.log {\n    daily\n    missingok\n    rotate 14\n    compress\n    delaycompress\n    notifempty\n    create 0640 www-data adm\n    sharedscripts\n    copytruncate\n}<\/code><\/pre>\n
Step 4: Understanding Critical logrotate Directives<\/h2>\n\n\n\n\n\n\n\n\n\n
Directive<\/th>\nOperational Purpose & Effect<\/th>\n<\/tr>\n<\/thead>\n
daily \/ weekly<\/code><\/td>\nRotates the log file once every calendar day or week.<\/td>\n<\/tr>\n
rotate 14<\/code><\/td>\nKeeps 14 historical log files before deleting the oldest archive.<\/td>\n<\/tr>\n
compress & delaycompress<\/code><\/td>\nGzips rotated logs to save ~90% disk space; delays compression on the newest rotated file so active daemons can finish writing without errors.<\/td>\n<\/tr>\n
copytruncate<\/code><\/td>\nCopies the active log and truncates it in place without closing the file handle. Essential for Node\/Python apps that don’t support log reopen signals.<\/td>\n<\/tr>\n
missingok & notifempty<\/code><\/td>\nSuppresses error alerts if the log file is missing, and skips rotation if the file is 0 bytes.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Step 5: Testing & Forcing logrotate Execution<\/h2>\n
Do not wait until midnight to discover a syntax error in your logrotate configuration. Test it safely in debug mode:<\/p>\n
# Perform dry-run dry debug test (no files changed)\nsudo logrotate -d \/etc\/logrotate.d\/mywebapp\n\n# Force immediate execution of all logrotate rules\nsudo logrotate -f \/etc\/logrotate.conf\n\n# Verify compressed .gz files were successfully created\nls -lh \/var\/log\/mywebapp\/<\/code><\/pre>\n
Frequently Asked Questions (FAQ)<\/h2>\n
\n
Why did my disk space not decrease after deleting a huge log file with rm?<\/h3>\n
In Linux, if an active process still holds an open file descriptor to a deleted file, the operating system retains the disk blocks until the process terminates. Run sudo lsof | grep deleted<\/code> to find the offending process, and restart it (e.g. sudo systemctl restart nginx<\/code>) to release the freed disk space.<\/p>\n
How can I truncate a massive log file without deleting it or restarting the service?<\/h3>\n
Use shell truncation: sudo truncate -s 0 \/var\/log\/bloated.log<\/code>. This instantly zeroes out the file content while preserving the active file descriptor, preventing application crashes.<\/p>\n<\/div>\n
\n
\ud83d\udd17 Recommended Related Technical Guides<\/h3>\n