Systemd is software that has sparked much debate in the Linux community for many years. Despite this, it has become a standard and essential part of nearly all Linux distributions.
Besides its well-known role as a system and service manager for Linux, it also provides many other possibilities. One such feature is the systemd-tmpfiles command. According to its man page, it briefly states, “Creates, deletes and cleans up volatile and temporary files and directories.“
“Great opportunity to clean up the /var/tmp directory” is probably what one Linux user thought, using a recently released systemd 256, before running systemd-tmpfiles --purge and the following happened:
“A lot of warning messages started appearing, which included paths in /home (it couldn’t restore modification times…?). What’s a temp-cleaning tool doing in my home directory? That’s no good. My heart started beating faster and I hit Ctrl-C as fast as I could.”
Despite his quick reaction, some of the files were permanently lost. Of course, the first reaction was to alert systemd devs on GitHub’s project page about the problem.
Immediately afterward, a response was received from a systemd developer, a Microsoft employee, stating:
“So an option that is literally documented as saying “all files and directories created by a tmpfiles.d/ entry will be deleted”, that you knew nothing about, sounded like a “good idea”? Did you even go and look what tmpfiles.d entries you had beforehand?
Maybe don’t just run random commands that you know nothing about, while ignoring what the documentation tells you? Just a thought eh”
I’ll let you all draw your own conclusions about this attitude. The upside is that the issue has been given the attention it deserves, leading to significant debate involving Lennart Poettering, a Microsoft employee and the mastermind behind systemd.
To clarify the issue, discussing it in detail would involve turning the explanation into a long, complex technical document. To keep it simple, the main issues stem from how systemd-tmpfiles processes the configuration files located in “/usr/lib/tmpfiles.d/“, particularly the “home.conf” file.
The critical part is that users, particularly those unfamiliar with the deep intricacies of systemd’s configuration, might not be aware of this command’s extensive reach, extending far beyond mere temporary file cleanup.
Furthermore, the command’s documentation exacerbated this situation, failing to adequately warn about the potential consequences of using the --purge option without detailed knowledge of the configured paths. Last but not least, let’s face it—systemd-tmpfiles is a very misleading name for the functions it has.
This oversight led to calls for improvements in the documentation to prevent such dangerous misuses in the future.
The GitHub discussions suggest adding clearer warnings and possibly modifying the command’s behavior to prevent execution without explicit configuration paths being specified. Such changes could help mitigate risks and clarify the system tool’s operation to end users, preventing accidental data loss incidents.
The good news is that following the reports of this issue, systemd’s devs and personal Lennart Poettering rapidly proposed changes to the systemd-tmpfiles configuration and its handling of directory cleaning operations.
A key pull request was submitted to refine the command’s operational scope, ensuring it explicitly excludes home directories or any critical areas unless specified by system administrators in a controlled manner.
The result of all this is the rapid release of systemd 256.1 with the necessary changes made. You can follow the whole discussion here and find comments on the topic on X (Twitter) and Mastodon.
