Practical Notes on Minimizing ram and disk used by systemd-journald | Trisquel GNU/Linux - Run free!

When configuring a lean Linux environment—whether a distribution like Trisquel GNU/Linux paired with a lightweight window manager, or a small virtual private server—discovering that the system logging service consumes 60 MB of resident memory and nearly a gigabyte of storage can come as an unwelcome surprise. Modern Linux distributions default to configurations intended for multi-user servers or workstations with dozens of gigabytes of disk space and generous memory. For environments where every megabyte counts, understanding how systemd-journald uses resources lets you reclaim disk space and memory without blinding yourself to critical system failures. In hosting support and systems administration, resource starvation frequently traces back to default daemon behaviors that were never tuned for minimal footprints. When a small virtual machine runs out of memory, administrators often search for runaway applications while overlooking basic background services that quietly claim generous portions of RAM for caches and indexing.

The desk clerk and the ledger: building an intuition

To understand why systemd-journald behaves the way it does, imagine a dedicated office clerk whose job is to record every event that occurs inside a building. Whenever a service starts, a user logs in, or a hardware error occurs, the clerk writes down the event on an indexed index card. If you tell the clerk, "Keep these logs, and organize them so I can find any event instantly by date, process ID, or service name," the clerk sets up a massive desk organizer right next to them. Instead of stuffing old cards into a filing cabinet down the hall, the clerk keeps the most recent several thousand cards spread across the desk surface (system RAM) so they can answer your inquiries without delay. Furthermore, if you never tell the clerk how many filing cabinets they are allowed to occupy, they will keep acquiring storage space until the room is ten percent full. Older logging utilities like rsyslog or syslogd acted like a clerk who simply wrote lines into a continuous paper roll and immediately pushed it into a bin. That approach consumed barely any memory—often just a couple of megabytes—because it performed no binary indexing or structured memory caching. In contrast, systemd-journald creates structured, searchable binary logs. That indexing provides fast querying via journalctl, but it comes at the cost of memory and disk overhead unless you explicitly draw boundaries.

How systemd-journald manages storage and memory

The systemd-journald service does not simply write flat text to /var/log/messages. It stores log events in specialized binary files with the .journal extension. These files contain index tables that map message fields—such as unit names, priority levels, and boot IDs—directly to log entries. This structure allows queries like journalctl -u nginx.service --since yesterday to return results quickly without reading the entire log file line by line. To achieve this performance, the daemon relies on memory-mapped files (mmap). When the journal writes or reads log files, the Linux kernel maps portions of those files into the process's virtual address space. Because the journal frequently accesses indexing data, pages remain resident in RAM. Under default settings, systemd-journald allows its log collection to scale with the size of your filesystem and the capacity of your RAM. The service defines two distinct operational targets for log storage: persistent storage on disk and volatile storage in memory. When logs are persistent, they reside on your root or /var filesystem (typically inside /var/log/journal/). If disk limits are left unset, systemd-journald defaults to claiming up to 10% of the filesystem volume, up to a built-in ceiling (often 4 GB on standard builds). On a 20 GB disk, that default allows up to 2 GB of storage just for system logs. When logs are volatile, or when the daemon buffers runtime data before writing it to disk, it places them in /run/log/journal/. The /run directory is mounted on tmpfs, which is a filesystem residing directly in virtual memory (RAM and swap). If you do not limit runtime storage, the daemon will use up to 10% of available RAM for runtime logs by default. On a small server or minimal desktop running on 1 GB or 2 GB of RAM, letting runtime logs claim even 100 MB to 200 MB can trigger memory pressure. If you are already managing tight hardware, checking background memory usage alongside active workloads is essential, as detailed in our guide on how to spot memory pressure on a VPS before the OOM killer hits.

The five parameters that control footprint

All journal resource consumption is managed through its primary configuration file, located at /etc/systemd/journald.conf, or via drop-in configuration snippets placed inside /etc/systemd/journald.conf.d/. Five directives in this file determine how much storage and RAM the service can claim:

Storage: Governs where log data is stored. It accepts four values: persistent, volatile, auto, and none. In persistent mode, logs are stored on disk under /var/log/journal/. In volatile mode, logs stay entirely within /run/log/journal/ in memory and disappear upon reboot. The default is usually auto, where systemd logs to disk if /var/log/journal/ exists, and falls back to volatile memory if the directory is missing. Setting this to none turns off logging entirely, disabling the service from storing records.
SystemMaxUse: Dictates the maximum disk space that persistent journals can occupy under /var/log/journal/. You can specify sizes using standard units like 50M or 500M.
SystemMaxFileSize: Defines how large an individual archived journal file can grow before the daemon rotates it and creates a new one. Setting this ensures that a single runaway process logging thousands of lines per minute does not bloat an individual file beyond manageable bounds.
RuntimeMaxUse: Sets the upper limit for log data kept in volatile memory under /run/log/journal/. This setting is critical for systems with small memory footprints, as it places a hard cap on how much tmpfs space the journal can claim.
RuntimeMaxFileSize: Specifies the maximum size of an individual volatile journal file before rotation occurs inside /run/log/journal/.

To restrict systemd-journald so that it uses predictable, minimal resources, create a drop-in configuration file that explicitly sets caps for these values.

INI

# /etc/systemd/journald.conf.d/00-low-resource.conf
[Journal]
Storage=persistent
SystemMaxUse=64M
SystemMaxFileSize=16M
RuntimeMaxUse=16M
RuntimeMaxFileSize=4M

After creating or modifying this file, restart the daemon using systemctl restart systemd-journald. The daemon will evaluate its existing archive files against the new SystemMaxUse ceiling, immediately unlinking and removing older archived files until total disk usage falls within your defined threshold.

Common pitfalls when restricting journald

Restricting log size is straightforward, but taking an overly aggressive approach introduces subtle operational risks that can complicate troubleshooting later.

Disabling logging entirely with Storage=none

In an effort to achieve the absolute lowest memory footprint, some users set Storage=none. While this eliminates journal overhead, it leaves the system blind. When a system service crashes on boot, or when a network interface fails to acquire a DHCP lease, the kernel and init system have nowhere to write diagnostics. Unless you run an alternative daemon such as rsyslog or busybox-syslogd, troubleshooting a boot failure or authentication issue becomes nearly impossible.

Relying on Storage=volatile to save disk space

Setting Storage=volatile avoids writing log files to an SSD or mechanical hard drive, which seems appealing on flash storage or minimal setups. However, because volatile logs live in /run/log/journal/, they reside in tmpfs. Every log message written directly consumes RAM that could otherwise be used by running programs or the kernel filesystem cache. Furthermore, all logs are erased the moment the machine reboots or suffers a kernel panic, depriving you of post-crash forensic data.

Setting file sizes too close to maximum usage

If you configure SystemMaxUse=50M and set SystemMaxFileSize=45M, systemd-journald has almost no room to perform orderly file rotation. The daemon keeps the active journal open while archiving filled files. If the maximum individual file size is nearly equal to the overall limit, archiving a file will immediately push total storage past the limit, forcing the daemon to delete the archived file almost instantly. A practical rule of thumb is to set SystemMaxFileSize to roughly one-fourth or one-eighth of SystemMaxUse. This allows the journal to maintain several rotated historical files before older entries are purged.

Misinterpreting memory-mapped cache as active RAM leaks

Administrators inspecting systemd-journald via tools like top or ps often look at the virtual memory (VIRT) column and assume the daemon is consuming gigabytes of RAM. Virtual memory in journald reflects mapped journal files on disk, not physical RAM allocation. To gauge actual footprint, observe Resident Set Size (RSS). Even then, much of the resident memory consists of clean cached pages that the kernel can drop if other processes demand memory. Restricting RuntimeMaxUse ensures that dirty, unevictable tmpfs pages do not accumulate in physical memory. Tuning systemd-journald is not about disabling logging, but about aligning logging defaults with your actual hardware constraints. By explicitly setting persistent bounds on disk use and capping volatile memory buffers, you retain structured log searchability while keeping the daemon within a predictable, modest footprint.