The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Use systemd-tmpfiles to declare directories and other filesystem entries that should be created, assigned attributes, or cleaned when the utility runs. For a system-wide runtime directory such as /run/example-app, add a rule under /etc/tmpfiles.d/ and apply it with the appropriate systemd-tmpfiles operation. Because /run is volatile, a path needed after reboot must be recreated by a boot-time mechanism; a rule alone does not run itself.
What systemd-tmpfiles does—and when to use it
The systemd project describes systemd-tmpfiles as a utility that creates, deletes, and cleans files and directories using the configuration format and locations documented in its manual. A rule records the desired filesystem action and relevant attributes; a system or user service invokes the utility to perform that action.
This is especially useful for paths beneath /run, which is volatile and is cleared across reboot. A comment in systemd’s implementation source describes the original practical purpose as creating properly owned directories beneath volatile locations such as /tmp, /var/tmp, and /run. That comment explains the design intent, not a guarantee that any particular rule runs at a particular time on every distribution.
Choose the mechanism to match the lifecycle:
- Boot/setup filesystem state: tmpfiles rules are a good fit for declaring paths that should be created or cleaned when the relevant tmpfiles operation runs.
- Service-specific runtime state: consider service-manager runtime-directory directives or application logic when the directory should exist only with a service, or when its lifecycle is tightly coupled to that service.
- Mounts and persistent application data: tmpfiles is not a substitute for mount configuration, service lifecycle management, or application-level state handling.
Write a rule for a runtime directory
Each rule describes one path. The documented fields are type, path, mode, user, group, age, and optional argument. The tmpfiles.d(5) manual documents the syntax, escapes, quoting, and configuration locations. A dash marks a field that is unused; when there is no argument, use - as the empty argument marker.
Recommended Free Tools
#1 Best Overall
# /etc/tmpfiles.d/example-app.conf
d /run/example-app 0750 example example - -This illustrative rule declares a directory at /run/example-app with mode 0750, owned by user and group example. The account names must exist when the rule is applied. /etc/tmpfiles.d/ is the administrator-managed system configuration location; confirm the configuration directories and precedence in the manual for the systemd version installed on your machine.
The type matters: it determines the action performed for a rule. For example, the manual’s syntax examples include a directory rule and a symlink rule:
d /run/user 0755 root root 10d -
L /tmp/foobar - - - - /dev/nullThese are documentation examples, not recommendations to copy unchanged onto every host. The first specifies a directory rule with a 10d age field; the second specifies a symlink. In general, do not assign an age merely because a field exists: age-based cleanup is a policy decision, and it is acted on by --clean.
Understand create, clean, and remove
The operations are distinct. Pick the one that matches the rule’s purpose rather than treating the command options as interchangeable.
| Operation | What it does | Typical reason to use it |
|---|---|---|
--create |
Creates or writes entries and applies ownership, mode, and related settings for applicable rule types. | Set up declared filesystem state, including a required directory. |
--clean |
Processes entries with an age parameter. | Apply age-based cleanup policy. |
--remove |
Removes entries marked for removal, subject to the documented lock behavior. | Perform removal actions specified by applicable rules. |
Boot-time setup and cleanup are handled through system units. The --boot option enables rules marked for boot-only execution; it is not a synonym for all three operations. Check the installed systemd-tmpfiles manual and local unit configuration to see which invocation applies to your intended rule.
Apply and test a rule safely
On systemd version 256 and later, --dry-run can show intended operations without changing the filesystem. On older versions, the option may not be available. Check systemd-tmpfiles --help or the local manual before relying on it.
- Review the rule and its scope. Check the path, type, ownership, mode, age, and argument. Inspect other applicable rules as well; path-selection options do not replace understanding the rule contents.
- Preview when supported. For example, use
systemd-tmpfiles --create --dry-run --prefix=/run/example-appto preview creation-related actions within that prefix on a version that supports dry-run. Use the operation you intend to perform; a preview of--createdoes not test cleanup behavior. - Limit or exclude paths if needed.
--prefix=/run/example-appselects applicable rules under that path prefix.--exclude-prefixignores rules under specified prefixes. These are scope controls, not safety guarantees for rules you have not inspected. - Run the intended operation. Once the rule and its effects are understood, invoke the relevant operation with the appropriate privileges for system configuration. Do not run broad cleanup or removal operations casually.
The upstream manual says settings safe to execute at runtime can be reapplied by restarting systemd-tmpfiles-clean.service. Do not assume that restart is a universal reload procedure: inspect the local service configuration and manual, particularly for boot-only actions or rules that belong to a different operation.
How /tmp cleanup works—and what to check locally
Cleanup depends on rules with age fields and an invocation of --clean. There is no single retention age or timer cadence established for all Linux distributions. Installed rules and systemd timer or service configuration can differ, so inspect your host rather than assuming that files in /tmp are kept for a particular number of days.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Best Value
- New
- Mint Condition
- Dispatch same day for order received before 12 noon
- Guaranteed packaging
- No quibbles returns
- Review the active system and user tmpfiles configuration directories documented for your installed systemd version.
- Inspect the relevant systemd cleanup service and timer to understand when cleanup is invoked.
- Read each applicable rule’s age field and path before running cleanup, especially when rules cover broad shared locations.
- Use dry-run where available to preview the intended operation; on older versions, do not assume an unsupported preview option exists.
System and user tmpfiles configuration are separate. User services can read user-controlled locations such as ~/.config/user-tmpfiles.d/ and ~/.local/share/user-tmpfiles.d/, alongside administrator-provided user rules. But system-level cleanup of shared /tmp is not controlled by a user’s tmpfiles settings: a system cleanup rule can affect files created by user processes.
Configuration scope and operational cautions
The tmpfiles.d(5) configuration directories, precedence rules, and available details have evolved. Follow the manual matching the systemd version installed on the target machine, rather than relying on precedence instructions copied from an older distribution guide.
Before applying a rule or cleanup operation, check these points:
Quick Recap
- Privilege and ownership: system rules are for system-wide filesystem state; user rules run in a distinct user configuration context. Ensure requested users and groups exist.
- Lifecycle: a declared path is only acted upon when an appropriate tmpfiles operation runs. Identify the unit or command responsible for the timing you need.
- Cleanup risk: understand age behavior and inspect applicable paths before cleanup. The upstream manual describes system-wide
--purgeas usually not the desired command; if considering it, first pair it with dry-run on a version that supports that option. - Version support: verify newer command options locally. In particular, dry-run was added in systemd version 256.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
