Modern Linux distributions and high-throughput server workloads continuously generate ephemeral data, including application cache files, IPC Unix domain sockets, lockfiles, and process runtime directories under /tmp and /run. Without an automated lifecycle management system, unmonitored temporary files can rapidly exhaust storage volumes, consume inode tables, or leave obsolete lockfiles that prevent background daemons from restarting cleanly after an unexpected system restart.
In Ubuntu, the native systemd-tmpfiles service provides a declarative, unified framework for managing temporary and volatile files and directories. Instead of relying on brittle custom shell scripts or fragmented cron jobs, administrators define declarative configuration rules in tmpfiles.d files. These rules instruct systemd to create runtime directories with strict permissions on boot, clean files based on age thresholds, or remove stale resources automatically during scheduled maintenance cycles.
Understanding How systemd-tmpfiles Functions
The systemd-tmpfiles infrastructure separates configuration declarations from runtime execution. System administrators specify declarative rules in .conf files placed within standardized configuration directories. Systemd processes these files across three dedicated service units:
systemd-tmpfiles-setup-dev.service: Executes during early system boot to create initial device nodes and symlinks before the full filesystem hierarchy is mounted.systemd-tmpfiles-setup.service: Runs during standard system initialization to create, adjust permissions on, and populate runtime directories under/runand/tmp.systemd-tmpfiles-clean.timer: A systemd recurring timer that triggerssystemd-tmpfiles-clean.serviceevery 24 hours to delete files that exceed configured age thresholds.
Configuration File Locations and Precedence Order
Like other systemd configuration subsystems, systemd-tmpfiles scans directories in a strict hierarchy of precedence:
/etc/tmpfiles.d/*.conf: Local system administrator configurations. Files here take absolute precedence over vendor rules./run/tmpfiles.d/*.conf: Dynamic, runtime configurations created programmatically by daemons./usr/lib/tmpfiles.d/*.conf: Upstream package and distribution default configurations provided by Ubuntu.
If two configuration files share the same file name across different directories, the file in /etc/ completely masks the file in /usr/lib/. This architecture allows administrators to customize system behavior without editing package files directly.
Deconstructing the tmpfiles.d Configuration Syntax
Each line in a tmpfiles.d configuration file consists of seven positional fields separated by whitespace:
Type Path Mode User Group Age Argument
Understanding the common action types is critical for defining accurate lifecycle policies:
d: Creates a directory if it does not already exist. If it exists, ownership and permissions are updated. Existing directory contents are preserved.D: Creates a directory or empties its contents if--removeis specified.f: Creates a regular empty file if it does not exist. Existing files are not truncated.F: Creates or truncates a regular file to zero bytes.z: Adjusts permissions and ownership on an existing path without creating it.Z: Recursively adjusts permissions, ownership, and SELinux/AppArmor context on an entire directory tree.e: Cleans the contents of an existing directory based on the configured age parameter, without touching the directory itself.r: Removes an existing file or empty directory.R: Recursively removes a directory and all nested contents.
Creating a Custom Runtime Directory with Automatic Aging
To demonstrate a practical production deployment, consider a background analytics service named report-worker that requires a dedicated spool directory under /run/report-worker on every boot, alongside an archival directory under /var/log/report-spool where temporary CSV exports older than 7 days must be purged automatically.
Create a custom configuration file in /etc/tmpfiles.d/:
sudo nano /etc/tmpfiles.d/report-worker.conf
Add the following declarative directives:
# Create volatile daemon runtime socket directory with strict permissions
d /run/report-worker 0750 www-data www-data -
# Create persistent report spool directory and clean files older than 7 days
d /var/log/report-spool 0770 www-data adm 7d
Save and close the configuration file. The hyphen (-) in the Age field for /run/report-worker indicates that files within that runtime folder should never be deleted by the aging timer.
Validating and Applying Rules Manually
Before waiting for a system reboot or timer trigger, you can execute systemd-tmpfiles directly to test your configuration.
To create missing directories and enforce declared ownership and permissions, run the creation command:
sudo systemd-tmpfiles --create
You can target your specific configuration file to isolate testing:
sudo systemd-tmpfiles --create /etc/tmpfiles.d/report-worker.conf
Verify that the directory was created with the intended attributes:
ls -ld /run/report-worker /var/log/report-spool
Simulating and Executing Cleanup Operations
To clean directories based on age thresholds without waiting for the daily timer, invoke the cleanup action. You can append the --dry-run flag to inspect which files would be deleted without making modifications:
sudo systemd-tmpfiles --clean --dry-run /etc/tmpfiles.d/report-worker.conf
To execute the actual cleanup pass immediately, run:
sudo systemd-tmpfiles --clean /etc/tmpfiles.d/report-worker.conf
During the cleanup run, systemd-tmpfiles evaluates the modification time (mtime), access time (atime), and change time (ctime) of each file against the 7-day age threshold (7d) before safely unlinking expired files.
Auditing Active Timers and Services
To verify that the automated daily cleanup service is scheduled and running correctly in Ubuntu, query the systemd timer status:
systemctl status systemd-tmpfiles-clean.timer
You can inspect when the next cleanup pass will execute using systemctl list-timers:
systemctl list-timers systemd-tmpfiles-clean.timer
By leveraging systemd-tmpfiles, system administrators maintain clean, predictable operating system environments, eliminate runaway spool directories, and ensure that required application sockets are provisioned reliably on every system start.