systemd version the issue has been seen with

256

Used distribution

Debian Unstable

Linux kernel version used

6.8.12-amd64

CPU architectures issue was seen on

x86_64

Component

systemd-tmpfiles

Expected behaviour you didn't see

I noticed my /var/tmp directory grew quite a bit and wanted to manually clean it. Since I was about to log off for the day, I skimmed through the manual for systemd-tmpfiles(8).

--clean
If this command is passed, all files and directories with an age parameter configured will be cleaned up.

--remove
If this command is passed, the contents of directories marked with D or R, and files or directories themselves marked with r or R are removed unless an exclusive or shared BSD lock is taken on them (see flock(2)).

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

Added in version 256.

Not knowing much about the systemd-tmpfiles architecture, other than that it's being used to clean up temp files, --purge seemed like a good idea. So, I ran sudo systemd-tmpfiles --purge, expecting it to clean my temp files.

Unexpected behaviour you saw

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.

Turns out, a good portion of my home directory got deleted. Thankfully, it seems like it started from the config files and not the actual data, though I am still not sure if I lost anything important. I turned off the machine to recover the data later with extundelete (it didn't work btw, it instantly crashes for some reason; I do have backups, but they are a bit outdated, I'm filling drives way too fast).

I talked about this on #debian-next, and seems that this is not a bug, but a feature, as systemd-tmpfiles also handles autocreating data directories such as /home, and the --purge flag is meant to wipe them clean. I am unsure what's the utility of that, but I assume there is a good reason.

What I do have an issue with is the documentation. It does explain what the options do, technically speaking (well, I assume so - I don't know a lot about the architecture here), but it doesn't explain why they do what they do. As someone just browsing the documentation, the three options seem to do the same thing - cleaning temp files, though --purge seems "more throughout" as it does mention it removes all files (including user data).

This kinda wraps back to the "Expected behaviour you didn't see" section, but sometimes the rigid form of the issue templates doesn't fit everything - so, what I would want to see is:

1. An explanation of why a given option does something, for example:

   --clean
   Cleans temporary files. [More in depth explanation follows...]

   --remove
   Cleans temporary files that [I don't know what's the difference with --clean, but explain it]. [...]

   --purge
   Removes all user data. [...]

   As a user, I don't know what those are actually intended to be used for, but as the developers, you probably do, and can describe them better than I did ;) I don't think this is specific to systemd-tmpfiles, it probably should be used as a guideline on how to write manuals project-wide (and honestly, industry-wide).

2. A huge warning next to --purge. This option is dangerous, so it should be made clear that it's dangerous. hdparm(8) is a great example:

   --dco-restore
   Reset all drive settings, features, and accessible capacities back to factory defaults and full capabilities. This command will fail if DCO is frozen/locked, or if a -Np maximum size restriction has also been set. This is EXTREMELY DANGEROUS and will very likely cause massive loss of data. DO NOT USE THIS COMMAND.

   --drq-hsm-error
   VERY DANGEROUS, DON'T EVEN THINK ABOUT USING IT. This option causes hdparm to issue an IDENTIFY command to the kernel, but incorrectly marked as a "non-data" command. This results in the drive being left with its DataReQust(DRQ) line "stuck" high. This confuses the kernel drivers, and may crash the system immediately with massive data loss. The option exists to help in testing and fortifying the kernel against similar real-world drive malfunctions. VERY DANGEROUS, DO NOT USE!!

For me, this would be sufficient, as I check the options I'm using in the manual. Not sure if it should have a confirmation or anything, I don't think it's necessary, even if you do have a confirmation, some people will blindly confirm anyways. Having a confirmation would also be API breakage I assume.

Steps to reproduce the problem

1. Run systemd-tmpfiles --dry-run --purge (due to --dry-run this is safe to run).
2. Notice how without --dry-run it would remove all your data.

Additional program output to the terminal or log subsystem illustrating the issue

No response