Scheduling temp file and cache directory cleanup
Age-based deletion of stale temp/cache files, and why /tmp itself is probably already handled.
The problem
On most systemd-based distros, /tmp is already cleaned up by systemd-tmpfiles (see /etc/tmpfiles.d/tmp.conf, typically clearing files untouched for 10 days), so a cron job that also purges /tmp is redundant at best and, if its age threshold is shorter than tmpfiles.d's, can delete files another process is still relying on sooner than the OS-level default would.
What's left is application-specific scratch or cache directories that nothing else cleans: upload staging directories, rendered-PDF caches, build artifact directories. The classic bug there is a `find -delete` age filter with the wrong comparison (`-mtime -7` matches everything modified in the last 7 days, the opposite of what's intended), or a filter that matches directories as well as files and removes something still in use.
Check systemd-tmpfiles before adding a cron job for /tmp itself.
Run `cat /etc/tmpfiles.d/tmp.conf` (or `systemd-tmpfiles --cat-config`) to see the existing age-based cleanup rule before writing your own for the same directory. Reserve a cron job for directories systemd-tmpfiles doesn't manage, usually somewhere under your application's own data path, not /tmp.
Recommended schedule
0 3 * * *
Once daily, off-peak, is enough for most scratch-directory cleanup. Faster-filling directories (high-volume upload staging) may need hourly. See /cron for other intervals.
Check any expression at the cron parser, or browse more at the cron guide.
Example crontab entry
# norc: cleanup-scratch Purge stale upload staging files
0 3 * * * /usr/bin/find /var/lib/myapp/staging -type f -mtime +7 -delete >> /var/log/cleanup.log 2>&1Failure modes to watch for
- Inverted -mtime sign (`-mtime -7` instead of `+7`) deleting everything recent instead of everything stale.
- Duplicating a systemd-tmpfiles rule with a shorter threshold, deleting files an OS-level cleanup pass would have left alone longer.
- Deleting a file another process currently has open. This is usually harmless on Linux (the inode stays until the handle closes) but confusing when df doesn't reflect freed space until that process exits or restarts.
- No `-type f`, so the same find also matches and removes directories the application expects to exist, breaking it on next write.
How norc helps
norc lists the jobs it manages next to your hand-written entries, which it leaves untouched, so it is clear which cleanup is one of the OS's and which is yours. Run history and missed-run detection show when yours stopped.