This Systemd tool Started Deleting User Files on Linux..

Systemd had an issue where an unclear command would start deleting a Linux users home directory. Which then the Linux system wouldn't be able to recover data for the user. This unclear tool is being fixed and better documented so we don't get unexpected behavior.

My Linux Cheat Sheet and 25 Page Checklist here:

Share this free tool and support Small YouTubers
(I made this tool to help creators)

Want more info/content?

Useful Commands/Links:

#linux #tech #pc

[SavvyNik]

What commands have you had issues with before?

[supercheetah]

Systemd isn't really just an init system any more. It's a brand, really, of a bunch of utilities that have some standard ways of being configured, and talk with each other.

[skelebro]

Artix, Void and MX Linux users having a field day right now LOL

[agentotten]

systemd is the gift that keeps on giving

[fluoriteByte]

Its kind of funny how one of the devs of systemd (which, keep in mind is one of the maintainers of its package on debian) said that nobody uses systemd-tmpfiles for permanent stuff

Debian literally uses it to make /var and /home

[_xX_me_Xx_]

We went from Linux, to GNU/Linux, to Systemd/Linux, and now just Systemd 😭

[ueddgdz]

The 'd' in systemd stands for deletion.

[locatemarbles]

What a bizarre reality. Despite Poettering working overtime, the proprietary OS enshittify at a faster rate, driving lots of refugees to Linux.

[GrzesiekJedenastka]

Original reporter here. I find this video biased against systemd, using the issue I reported as proof that systemd is evil (or something). Funny thing is, I actually like systemd, if I didn't I probably wouldn't use it.
All software has bugs, so I often go and open issues against software that I use, so that it can hopefully get better. I don't think we should judge software by the amount of bugs, but rather by how reports are handled. The response to this ticket was, other than the initial comment (maybe that maintainer had a bad day, I don't know), excellent.
Now about the issue itself - turns out, systemd-tmpfiles doesn't "just manage temporary files", and the name is an unfortunate one, largely caused by it's origins. This wasn't well documented, as the (now corrected) manpage explicitly said it manages "temporary files". Really, it just manages the file structure _in general_.
Moreover, while there _is_ an option to actually clean temporary files, it's --remove. --purge actually clears _all_ specified directories (or, before this was changed, everything if nothing is specified) managed by the tool, which can include /home and other "data" directories. This makes sense for example when you need to create a basic file structure on the first boot, or want to do a factory reset (kinda what I, unintentionally, did).
The option itself isn't doing anything "bad". It just wasn't well documented. All I really wanted to achieve here is improving the docs, so they explicitly state what it does and warn the user, and that was implemented. Moreover, it's now harder to call it by accident, as apparently just --purge alone isn't normally used. I think viewers of this video should indeed read the original report and the responses, as the issue feels very misrepresented by the author.
On systemd, it is _not_ a monolith. It's made out of components. You can easily take the init system and service manager but not integrate anything else. The reverse is harder, as those components are usually meant for it and are well integrated. You could probably use them independently, but at that point you probably should just use something else... I guess you can think of these components as "plugins", if you will (not technically correct but does explain the situation decently well).
The "Unix philosophy" argument is also thrown around without much substance. The Linux kernel also doesn't accomplish a "single task", it's very complex, but that doesn't mean it's _bad_. It can be broadly said that the kernel "provides an enviroment for userspace to run". In the same vein, it can be broadly said that systemd "manages the userspace". I think that's enough, the goal is defined, even if there are many things needed to accomplish it.
I would also argue that it isn't _that_ complex. I do not know many of it's components, but I am very much familiar with the init system and service manager part, and I feel like "traditional" init systems are a lot more clunky and complicated to understand and configure.

[valcaron]

The less reliable systemd gets, the more important routine off-site backups and snapshot-capable file systems like BTRFS and ZFS become.

[walter_lesaulnier]

The problem is developers writing tools for developers without even considering average desktop users.

[ToumalRakesh]

The problem with systemd is not that it's "new" or "different". The problem is a lack of experience in its development. From the slewing of timesyncd (or lack thereof), the BSOD implementation not providing anything of value and being someone's first time programming, or heck, Poettering's decision to kill user processes on logout and making that the default, then saying it'd be up to the distros to change the default to something more reasonable... Imagine the lpad guy, or the guy who made the is_true, is_even and is_odd javascript-"libraries" were to build core components for your operating system.
That's systemd.

[TheJimNicholson]

The original motivation for systemd was well-intentioned, but the current implementation of systemd is way beyond the scope of init, and ultimately if left unchecked, systemd will be sufficiently distinct from Unix/Linux that it should be considered its own operating environment.

[georgecoldwell]

I honestly feel like this is the fault of distros that use systemd-tmpfiles to setup /home. the thing is a manager of temporary files, one would expect these to be cleaned up every now and then. it even has tmp in name. not that I don't think the change done in response is bad, but this really is just distros misusing a tool to do something it was not meant to do and now the users pay.

also this really has very little to do with systemd. systemd-tmpfiles is very much a standalone service that nobody has to use if they don't want to, and the situation would be the exact same had it been an external service unrelated to systemd.

[knutblaise]

Hey there. Are you aware of CVE's tied to XORG running as part of desktop Linux sharing keypress with ALL running apps? In an XORG Linux desktop VM, install xinput, run xinput, NOT as root, in test mode in a terminal, open another terminal, a notepad, a calc, and a browser. With xinput in test mode it will capture all keypresses. The note in notepad, the calculations in your calc, your financial account in your browser, and your sudo pw in the second terminal. Wayland supposedly gets around this but with Linux on X every nonprivileged app running can read EVERY keypress. No NPU required on XORG Linux to capture your data.

[francescodlx]

Linux (in the means of distros) has a lot of tools written by incompetents. systemd is the leader of all them.

[monisrajput]

I was practicing to recover arch.
In the tutorial command has been run and author recover fully.
But i ran the same thing but all is blown out
I thought why this is happening

[damouze]

Systemd IS the issue. But that's what happens when you try to create a solution for a problem that does not exist.

[alliboogaloo]

Glad I rest on Alpine, Systemd just keeps having issues pop up.

[cest]

petition to rename it into "problemd"