systemd tmpfiles applies supported rules for creating and managing selected filesystem objects, including cleanup under configured conditions. It can help maintain temporary directories and expected paths, but a cleanup rule is a potentially consequential filesystem operation. A familiar directory name is not enough evidence that every item beneath it is disposable.
This guide explains how to design and verify rules on systems you administer. Start with ownership, lifecycle, and the installed platform’s semantics. Avoid deploying an age-based cleanup policy to important application data without a controlled test and recovery plan.
Define the systemd tmpfiles purpose
Identify which objects the rule should create or maintain and why cleanup is appropriate. Temporary exports, service runtime files, and persistent application records can have different lifecycles. Do not group them solely because they share a directory.
Record the owning service and whether files may remain in active use. An age threshold is not a universal proof that content is no longer needed. The application may have its own supported cleanup mechanism.
Keep the path and action explicit. A broad wildcard can affect more material than intended, especially after another service begins using the same location.
Review the deployed rule model
Use the tmpfiles.d reference for supported types, fields, precedence, and age behavior. Match the documentation to the installed systemd version.
Distinguish creation, removal, and age-based cleaning actions. They are not interchangeable operations. A rule accepted by the parser should still be reviewed for the filesystem effects it requests.
Inspect the effective configuration, including vendor and local rules. A local file can interact with existing policy, so do not assume the new line is the only rule affecting a path.
Choose ownership and permissions deliberately
When creating directories or other supported objects, select the owner, group, and mode required by the service. Avoid permissive settings merely to make several unrelated processes share one path.
Review parent-directory access and the identity that uses the object. A correctly created final directory can still be unreachable or writable by an unintended user through another part of the path.
Keep creation policy aligned with application behavior. If the application replaces files or directories with different settings, a one-time rule may not maintain the desired state indefinitely.
Understand the cleanup age semantics
The documented age behavior depends on rule and timestamp semantics. Do not summarize it as delete anything last modified long ago without checking the relevant fields and supported options.
Consider how reading, writing, and application lifecycle affect eligibility. A file may have old content but still be required, or a temporary artifact may remain fresh because another process touches it.
Test representative cases with controlled timestamps and synthetic files. The actual selected objects matter more than a human interpretation of the age string.
Protect boundaries involving links and changing paths
Review symbolic links, mounts, and untrusted writable directories according to the platform’s supported handling. Cleanup should not escape the intended ownership boundary or affect another service’s state.
Avoid introducing broad recursive operations outside the documented rule model. If the requirement needs a custom script, it deserves its own validation and least-privilege review rather than being hidden behind a generic cleanup label.
Keep the target tree controlled. Another process that can reshape the directory during cleanup can complicate assumptions about which objects the rule will encounter.
Test before enabling production cleanup
Use an isolated test tree with files that should remain and files that should be eligible. Run the supported test or inspection workflow for the installed version, then inspect the filesystem outcome.
Confirm that the rule does not remove unrelated content and that expected paths retain correct ownership and permissions. Include a failure or interrupted-run case where the platform and task require it.
Do not test by deliberately placing important production records at risk. A validated synthetic example and an approved rollout provide better evidence than discovering an overly broad rule through data loss.
Coordinate with service-specific retention
Some applications require their own bookkeeping when removing data. Databases, queues, package stores, and managed logs can have internal relationships that a generic age rule does not understand.
Our journal retention guide illustrates why supported service-level maintenance matters. Use the appropriate owner mechanism rather than treating every large or old directory as generic temporary content.
Document which service is responsible for each lifecycle. Overlapping cleanup policies can make a later incident difficult to explain.
Monitor and maintain the policy
Record the rules, owner, expected effects, tests, and recovery assumptions. Revisit them when application paths or data retention requirements change. A temporary directory can become operationally important after a feature update.
Use safe logs and observations to verify cleanup activity and storage behavior. Avoid retaining private filenames unnecessarily in a broadly accessible monitoring system.
Keep rollback realistic. Removing a rule prevents future activity but does not restore content already deleted. Important data needs its own tested recovery path before any risky lifecycle change.
A practical verification scenario
Consider a service that writes temporary exports and persistent recovery files into nearby directories. Before creating a cleanup rule, separate ownership and lifecycle for those paths. An old recovery file may remain important while a recent temporary export is already disposable under the application’s supported process.
Build a synthetic directory tree with files that should remain and files that should be eligible. Test the installed platform’s rule semantics and inspect the actual result, including ownership and permissions of retained objects. Avoid proving the rule by risking a real recovery artifact.
Record the effective configuration, timestamp assumptions, owning service, test evidence, and expected maintenance behavior. Check for overlapping application cleanup and vendor rules. Define how the policy is reviewed when the directory’s use changes. Removing the rule later cannot restore deleted data, so rollback planning must acknowledge that limit and rely on a separate tested recovery path where important content could be affected.
Frequently asked questions
Does old age mean a file is safe to remove?
No. It must match the application’s lifecycle and the documented rule behavior. Files can remain important long after their content changes.
Can generic cleanup replace a database’s maintenance tool?
Not safely as a general rule. Use the owning service’s supported process when its state and bookkeeping require it.
What should I verify first?
The exact path, ownership, action, age semantics, and effective rule set. Then prove the expected result with synthetic files before production rollout.
