from Hacker News

Systemd 256.1 Fixes systemd-tmpfiles Unexpectedly Deleting Your /home Directory

by surteen on 6/19/24, 10:45 AM with 8 comments

• by nullc on 6/19/24, 7:03 PM

  Systemd 256: now with 98% less unix philosophy and 100% less data retention.

• by pm2222 on 6/19/24, 11:26 AM

  Read the other recent discussion on Debian moving to mount /tmp as tmpfs in upcoming stable release. It’s just confusing at the least if not a bad idea outright that systemd-tmpfiles goes out to delete files in /tmp regardless of how and by whom files were created. /tmp is a shared folder.

• by ikekkdcjkfke on 6/20/24, 5:14 AM

  What a sh*t show. Something with so many dependants should not be run by a couple of dudes LGTM'ing each other

• by DiabloD3 on 6/20/24, 7:08 AM

  Guys, look. You know when I say systemd is evil and will screw you over, and never like any of my examples?

  HERE. RIGHT HERE. This is the evil and/or incompetence I don't want interacting with my machines. I, and the rest of the community, frankly, is being held hostage.

• by sillystuff on 6/19/24, 8:45 PM

  After only reading the headline, I expected Poettering to be quoted saying, "Functioning as designed. Go pound sand." The response was as expected, but apparently Poettering's attitude has become contagious within the systemd devs:

  > Initially the bug report was shot down by systemd developer Luca Boccassi of Microsoft with:

  > 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