CasaOS journald Disk Usage: Limit Logs Without Breaking Logging

Bottom Line: Cap journald Before It Fills a Small CasaOS System Disk

The original CasaOS system had more than 5 GB under /var/log/journal. The durable fix is not to delete journal files by hand. Set a size ceiling, optionally keep a minimum amount of free space, and vacuum old archived logs once. After that, journald enforces the policy automatically.

Measure the Journal Before Changing Anything

journalctl --disk-usage
du -sh /var/log/journal 2>/dev/null
df -h /var

If logs are consuming several gigabytes on a small boot disk, decide how much recent history you actually need. For a home server, a fixed ceiling is usually more predictable than letting defaults consume a percentage of the filesystem.

Set Size and Retention Limits in journald.conf

[Journal]
SystemMaxUse=1G
SystemKeepFree=1G
MaxRetentionSec=14day

SystemMaxUse limits persistent journal storage, while SystemKeepFree preserves free space for the rest of the OS. MaxRetentionSec is optional if you also want a time-based ceiling. The journald size limits defines how these limits interact.

Vacuum Old Logs Once After Setting the Policy

sudo journalctl --rotate
sudo journalctl --vacuum-size=1G

Vacuuming removes archived journal files; it does not replace the configuration. If you only vacuum and never set a limit, the directory can grow again. The journalctl vacuum controls covers the supported cleanup commands.

Do Not Stop journald Just to Replace the Config File

The 2024 post stopped the service, removed the config and copied a replacement file. That worked, but it is more disruptive than necessary. Edit the file safely, keep a backup, then restart the service:

sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.bak
sudo nano /etc/systemd/journald.conf
sudo systemctl restart systemd-journald

Can journald Store Logs on Another Disk?

Not through a simple arbitrary path in journald.conf. Storage=persistent targets /var/log/journal; Storage=volatile uses /run/log/journal. If you need longer retention elsewhere, forward logs to another syslog/journal host instead of bind-mounting critical system paths casually.

Find the Service Creating Excessive Logs

journalctl -p warning..alert --since "24 hours ago"
journalctl --since "24 hours ago" | tail -200
systemctl --failed

A disk limit protects the OS, but it does not cure a service that is logging the same error thousands of times. Fix the noisy service once the system has breathing room.

If you are considering moving from an older CasaOS install to a more appliance-style server, the ZimaBoard 2 platform and ZimaOS backup provide a safer migration context.

Prevent One Service From Flooding the Journal

If one container or daemon is emitting the same warning continuously, global storage limits only contain the damage. Check the noisiest units and then fix the source:

journalctl --since "1 hour ago" -o short-unix | tail -500
journalctl -u SERVICE_NAME --since "1 hour ago"

For services managed by systemd, per-unit log rate controls can reduce bursts without discarding every other system log. Use rate limiting only after you understand what is being suppressed; repeated storage, filesystem or network errors may be the evidence you need to solve the underlying problem.

FAQ

How large should SystemMaxUse be?

There is no universal value. On a small OS disk, 500 MB to 2 GB is a practical starting range if you rarely need long log history. Leave enough free space for updates and application metadata.

Will journalctl --vacuum-size delete current logs?

It removes archived journal files until the target size is approached. Rotate first if you want the active journal moved into the archived set.

Should I use logrotate for /var/log/journal?

No. Binary journal files are managed by systemd-journald itself. Use journald size/retention settings and journalctl vacuum operations.

Can I keep logs on another HDD?

Yes through log forwarding or a deliberately designed mount, but journald does not provide an arbitrary custom path setting. Remote logging is usually safer than moving a core OS directory.

Why did the journal reach several gigabytes?

The default policy may allow substantial storage, and one noisy service can generate entries quickly. Check both the configured ceiling and the service producing the volume.