Putting /var/log on tmpfs on embedded — when does it make sense?

On read-only root or flash-backed boards, teams often mount /var/log as tmpfs (RAM). Logs accumulate at runtime and vanish on reboot. This post covers only an fstab example · post-reboot logs · using journald alongside. No invented board benchmarks, affiliates, or C++ samples.

Grounding: fstab(5) table syntax, tmpfs in-memory mounts, and Storage= in journald.conf(5) (volatile / persistent / auto / none).

What does an fstab example look like?

One-line answer: Add a line like tmpfs /var/log tmpfs … size=…,mode=0755 to /etc/fstab, then recreate required subdirectories with tmpfiles.d after each boot.

Typical skeleton (tune size/options to measured usage on your image):

# /etc/fstab — keep /var/log in RAM (tmpfs)
# size= is a ceiling (lazy allocation). Set from observed usage + margin.
tmpfs  /var/log  tmpfs  defaults,nosuid,nodev,noexec,mode=0755,size=50M  0  0

Notes:

1. Both source and type are tmpfs — not a block UUID.
2. size= caps the mount. tmpfs usually consumes RAM only for what you write, but hitting the cap can make writes fail. Pick from field usage, not a random board headline number.
3. mode=0755 is common; do not casually reuse /tmp-style 1777 on /var/log.
4. nosuid,nodev,noexec is a usual harden for a log tree (adjust if you must).
5. Right after mount, /var/log is nearly empty. Daemons that require their log directory (nginx, httpd, …) may fail until paths exist.

Prefer tmpfiles.d(5) over ad-hoc mkdir in rc.local:

# /etc/tmpfiles.d/var-log-dirs.conf skeleton
d /var/log/nginx   0750 root adm -
d /var/log/journal 2755 root systemd-journal -
# add only paths your image actually needs

Verify:

findmnt /var/log
df -h /var/log

What happens to logs after reboot?

One-line answer: Everything under that tmpfs — files and subdirs — is gone after reboot or power loss. Less flash wear; no local post-mortem history unless you ship logs elsewhere.

Topic	Meaning
Before reboot	Text logs (and journal files if placed under /var/log) live in RAM
After reboot	Fresh empty tmpfs mount
Crash / power cut	Unsynced data is not recoverable by default
Debug escape hatch	Document how to comment out the fstab line (or point logs elsewhere) when you need persistence

Anything created under /var/log is in scope: app dirs, rotate state, empty trees services expect. Keep the tmpfiles list next to your package/service set.

Remote retention (syslog/journal remote, serial console, collectors) is a separate design. Here we only describe local /var/log on RAM.

Tip: Mounting /var/log as tmpfs “for flash life” without tmpfiles often yields boot loops of missing log paths. Validate mount → tmpfiles → services as one unit.

How do you use this with journald?

One-line answer: journald’s Storage= chooses the tree. volatile → /run/log/journal, persistent → /var/log/journal. If /var/log itself is tmpfs, calling it persistent still does not survive reboot.

From journald.conf(5):

Value	Where (per man)
volatile	In memory under /run/log/journal (created if needed)
persistent	Prefer /var/log/journal (created if needed); fall back to /run/log/journal early / if not writable
auto	Like persistent if /var/log/journal exists, else like volatile
none	Do not store (forwarding can still apply)

Common embedded pairings:

1. /var/log tmpfs + Storage=volatile
   Journal under /run, classic logs under /var/log tmpfs. Both wiped on reboot. Cap runtime use with RuntimeMaxUse= etc. after measurement.

2. /var/log tmpfs + Storage=persistent / auto (dir present)
   Files may appear under /var/log/journal, but the parent mount is RAM, so they still disappear on reboot. Do not read the word “persistent” as flash durability here.

3. Keep journal on flash, text logs in RAM
   Often better not to tmpfs all of /var/log; keep journal on a writable persistent path with Storage=persistent, and isolate noisy text logs another way. That is a different design than “whole /var/log is tmpfs.”

# /etc/systemd/journald.conf.d/volatile.conf example
[Journal]
Storage=volatile
# tune RuntimeMaxUse= from observation — not a board marketing number

systemd-analyze cat-config systemd/journald.conf
journalctl --header
findmnt /run /var/log

Man page notes: switching to volatile does not delete existing persistent files; the other direction may involve journalctl --flush. Early boot may start volatile until flush moves to persistent when configured.

Caution: Storage=auto keys off whether /var/log/journal exists. Recreating that dir every boot via tmpfiles on a tmpfs /var/log can select persistent-behavior while still not surviving reboot.

Frequently asked questions

Does a large size= reserve that much RAM up front?
It is a ceiling. Consumption usually tracks written data, but you still contend with other workloads. Size from measurement.

Is mode=1777 OK so every daemon can mkdir?
It papers over missing dirs at a security cost. Prefer tmpfiles for required paths only.

If journal is volatile, do I still need /var/log on tmpfs?
Journal and classic text / app log files are separate. Apps writing under /var/log/... still hit flash unless that tree is RAM or redirected.

Does this pair with read-only root?
Often yes: RO root plus tmpfs (or other rw volumes) for runtime writes. This article only covers the /var/log tmpfs piece.

What should you remember?

/var/log on tmpfs volatilizes local logs for flash/RO-root embedded systems. fstab tmpfs line, empty after reboot, tmpfiles.d for subdirs, journald Storage=volatile (/run) vs persistent (/var/log/journal) — and if /var/log is tmpfs, persistent is still not reboot-durable. Sources: fstab(5), tmpfs, journald.conf(5), tmpfiles.d(5). No affiliates.

Where are the official sources?

• fstab(5) — mount table fields
• tmpfs — The Linux Kernel documentation — in-memory filesystem
• journald.conf(5) — Storage=, Runtime/System limits
• tmpfiles.d(5) — create dirs at boot