systemd 256.1: Now slightly less likely to delete /home

Fixes catastrophic data loss, er, bug, er poorly documented feature... user error

Following closely after systemd version 256 comes 256.1, which fixes a handful of bugs. One of these is emphatically not systemd-tmpfiles recursively deleting your entire home directory. That's a feature.

The 256.1 release is now out, containing some 38 minor changes and bugfixes. Among these are some changes to the help text around the systemd-tmpfiles command, which describes itself as a tool to "create, delete, and clean up files and directories." Red Hat's RHEL documentation describes it as a tool for managing and cleaning up your temporary files.

That sounds innocuous enough, right?

It isn't, as GitHub user jedenastka discovered on Friday. He filed bug #33349 and the description makes for harrowing reading, not just because of the tool's entirely intended behavior, but also because of the systemd maintainers' response, which could be summarized as "you're doing it wrong."

The systemd-tmpfiles command manages files according to a specification file called tmpfiles.d, and, among many others, it has an option called --purge, which sounds quite handy according to its own manual page:

–purge

If this option is passed, all files and directories created by a tmpfiles.d/ entry will be deleted.

Among the issues fixed in version 256.1 are that even as long as five years ago, systemd-tmpfiles had moved on past managing only temporary files – as its name might suggest to the unwary. Now it manages all sorts of files created on the fly … such as things like users' home directories. If you invoke the systemd-tmpfiles --purge command without specifying that very important config file which tells it which files to handle, version 256 will merrily purge your entire home directory.

That fun little nugget of info broke over on Mastodon and has attracted considerable attention. Some of this has been directed at the first response to the bug report, from systemd team member Luca Boccassi:

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.

If Boccassi's name is unfamiliar to you, he is the chap who came up with the pithy line "now with 42% less Unix philosophy" which we reported in our story on the release of systemd 256 last week.

No, it did not originate with systemd daddy Lennart "Agent P" Poettering. We do note, however, that Boccassi is Poettering's colleague at Microsoft. And we used the line not only for its Hitchhiker's Guide reference, but because it genuinely made us chuckle. In the delicate world of open source politics, though, perhaps a smidgen more diplomacy is sometimes needed.

Thus, despite an initially rather hostile response along the lines that the command was only doing what it said on the tin, always read the label, may contain nuts, etc, this command has now sprouted a few more warnings. Now, the --purge subcommand insists on a specification file, the command summary is more explicit and admonishes care, there's a warning in the man page, and the description of the systemd-tmpfiles tool no longer contains the word "temporary". It isn't much, but it's something. This is among other modest changes, of course.

It's a useful reminder to all concerned. We're all busy, and nobody has time to read the docs in full every time. Names matter, and the wider world probably won't notice when you change what a tool does if its name still refers to a now-obsolete definition.

A small joke can ricochet around the world in the time that it takes one erroneous command to wipe all your data, which – thanks to SSDs – happens more quickly than ever. These tools are written and maintained by small teams of mere humans, and humans mess up occasionally. And if your command can potentially do something really dangerous, then don't let people just run it without warning them and checking. ®

More about

More about

More about

TIP US OFF

Send us news


Other stories you might like