🧹 Managing systemd-tmpfiles and Temp Directory Cleanup with AI

A surprising number of disk-full incidents trace back to temp files nobody cleans up — a /tmp packed with multi-gigabyte upload scratch files, a /var/tmp full of stale build artifacts, an app’s spool directory that grows forever because nothing ages it out. The modern, declarative answer on systemd Linux is tmpfiles.d, which both creates directories with the right permissions at boot and cleans old files on a timer. The catch is the syntax: a terse line of type codes, mode bits, and age specifiers where one wrong column can mean it deletes the wrong thing or nothing at all. This is exactly the kind of precise, well-documented format where an AI assistant earns its place as a fast junior engineer — it writes and explains the rule, I verify and apply it. Here’s the loop.

Seeing what already runs

systemd-tmpfiles is already managing files on your box; start by seeing the existing config so you don’t conflict with it.

systemd-cat --help >/dev/null 2>&1   # ensure systemd userspace present
cat /usr/lib/tmpfiles.d/tmp.conf
systemd-tmpfiles --cat-config | less

--cat-config merges every fragment in priority order, showing the effective configuration. Paste a slice into an AI and ask it to explain what’s being created and what’s being aged out — it reads the column format fluently and tells you, for instance, that /tmp files are cleaned after 10 days by default.

Understanding the line format

Every tmpfiles line is: type, path, mode, owner, group, age, argument. The type code does the heavy lifting.

d /var/spool/myapp 0750 myapp myapp 7d -

That means: create directory d, mode 0750, owned by myapp, and remove contents older than 7d. The type codes are the part people forget — d creates and cleans, D also wipes on boot, f creates a file, L makes a symlink, r removes. Describe what you want in English and let the AI produce the line with the type-code explanation:

“Write a tmpfiles.d rule to create /var/spool/myapp owned by user myapp mode 0750, and delete files inside it older than 7 days. Explain the type code and the age field.”

That explanation is how you avoid the classic mistake of using D (which wipes at every boot) when you meant d. I keep these tmpfiles prompts in a shared prompt library so cleanup rules are written consistently.

Pro Tip: Always test a cleanup rule with --dry-run before trusting it. tmpfiles deletes files, and a too-broad path or a misplaced age field can remove data you needed. The dry run shows you exactly what would be deleted with zero risk.

Testing before you apply

This is the step that keeps tmpfiles from becoming a self-inflicted data-loss incident.

sudo tee /etc/tmpfiles.d/myapp.conf <<'EOF'
d /var/spool/myapp 0750 myapp myapp 7d -
EOF
sudo systemd-tmpfiles --create --dry-run /etc/tmpfiles.d/myapp.conf
sudo systemd-tmpfiles --clean --dry-run /etc/tmpfiles.d/myapp.conf

--create --dry-run shows what would be created; --clean --dry-run shows what would be deleted. Read both. When the dry-run output surprises you, paste it to the AI and ask why a file matched — it’ll spot that your age specifier is comparing against atime versus mtime, a subtle difference that explains unexpected deletions.

Applying and verifying

Once the dry runs look right, apply for real and confirm.

sudo systemd-tmpfiles --create /etc/tmpfiles.d/myapp.conf
ls -ld /var/spool/myapp
systemctl status systemd-tmpfiles-clean.timer

The directory should now exist with the right ownership, and the systemd-tmpfiles-clean.timer is what runs the cleanup periodically. Verify the timer is active — without it, your 7d aging never actually fires.

Tuning the cleanup schedule

The default clean timer runs daily, but on a fast-filling spool you may want it more often.

sudo systemctl edit systemd-tmpfiles-clean.timer
systemctl list-timers | grep tmpfiles

Ask the AI to write the OnCalendar= override for, say, hourly cleanup; it knows systemd’s calendar syntax and will give you the correct drop-in. Verify with list-timers that the next run is when you expect.

Catching age-out problems before they bite

The failure mode that hurts is a rule that doesn’t clean — disk fills anyway. Watch the directory growth as a signal.

du -sh /var/spool/myapp
journalctl -u systemd-tmpfiles-clean.service -n 50

If the directory keeps growing, the journal for the clean service tells you why. Paste it to the AI — it’s good at spotting that files are being skipped because they’re owned by a different user, or that the age field never matches because the files keep getting touched.

Protecting files you never want cleaned

The flip side of aging files out is protecting ones that must survive cleanup — a lock file, a socket, a marker the app depends on. tmpfiles has an exclusion type for exactly this, and ordering by priority prefix is how you make it win.

# 00-keep.conf runs first; x excludes a path from cleanup
x /tmp/myapp.lock

The x type marks a path as ignore-during-clean, and the X variant also excludes everything under it. Because fragments process in lexical order, a low-numbered file like 00-keep.conf establishes exclusions before later cleanup rules run. Describe the intent to the AI — “keep /tmp/myapp.lock and its directory safe from the default /tmp cleanup” — and it produces the right exclusion line and tells you what prefix to use so it takes precedence. That ordering subtlety is easy to get wrong and easy for the model to get right.

Pro Tip: If the default /tmp cleanup is eating a file your app relies on, don’t disable the whole tmp.conf — add a small x exclusion in a 00-prefixed fragment. You keep the system’s sane defaults and carve out just the one path you need to protect.

Creating files and setting permissions atomically

tmpfiles isn’t only for cleanup — it’s the right place to guarantee a directory or file exists with correct ownership before a service starts, replacing fragile ExecStartPre=mkdir hacks.

d /run/myapp 0755 myapp myapp - -
f /run/myapp/state 0640 myapp myapp - -

Files under /run vanish on reboot, so recreating them via tmpfiles at boot is the clean pattern. Ask the AI to translate an ExecStartPre chain of mkdir/chown/chmod into the equivalent tmpfiles lines; it maps them accurately and the result is more robust because systemd applies it consistently and early.

Keeping it safe

tmpfiles deletes files, so the safety rules are firm. The AI writes and explains rules, but you always run both dry-runs before applying, you double-check the path is exactly what you intend, and the AI never runs systemd-tmpfiles --clean against your servers or gets credentials. It is a fast junior engineer fluent in a format that’s easy to get wrong; the human verifies the dry run and applies the rule. A too-broad cleanup path is one of the few config mistakes that can silently delete production data, so a human reviews every line. Track these changes through our code-review dashboard, which keeps the rule and its dry-run evidence together.

Conclusion

Runaway temp files cause more quiet disk-full incidents than they should, and tmpfiles.d is the clean, declarative fix — once you get past its terse syntax, which is exactly what an AI copilot handles. Read the existing config, let the model draft and explain the rule, dry-run both create and clean, then apply and confirm the timer. The AI writes the syntax; the human owns what gets deleted. For more, see the Linux admin category, and the Linux admin prompt pack bundles the tmpfiles-drafting prompts I use to keep disks from filling.