274
submitted 1 week ago* (last edited 1 week ago) by Lanky_Pomegranate530@midwest.social to c/linuxmemes@lemmy.world
you are viewing a single comment's thread
view the rest of the comments
[-] crimsoncobalt@lemmy.world 16 points 1 week ago

Does this really work? Wouldn't rm remove itself in /bin early in the process?

[-] rbn@sopuli.xyz 48 points 1 week ago* (last edited 1 week ago)

I think it would continue even after it's own deletion as the binary is already loaded into memory, so process is not dependent on the file system. Still doubt that it'll complete successfully. Most likely the system crashes in the middle.

[-] kirk781@discuss.tchncs.de 13 points 1 week ago

I thought - - no-preserve root also needed to be added as an argument for self destruct to completely work.

[-] elvith@feddit.org 11 points 1 week ago

Yes, though you could also do rm -rf /* afaik to not need --no-preserve-root

[-] blibla@slrpnk.net 1 points 1 week ago

i dont get why you can't just do sudo rm -fr /

[-] elvith@feddit.org 2 points 1 week ago

because it won't let you do that:

elvith@testvm:~$ sudo rm -fr /

rm: it is dangerous to operate recursively on '/'

rm: use --no-preserve-root to override this failsafe

[-] SpaceCadet@feddit.nl 1 points 1 week ago

as the binary is already loaded into memory

That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.

[-] SpaceCadet@feddit.nl 18 points 1 week ago

In Unix/Linux, a removed file only disappears when the last file descriptor to it is gone. As long as the file /usr/bin/rm is still opened by a process (and it is, because it is running) it will not actually be deleted from disk from the perspective of that process.

This also why removing a log file that's actively being written to doesn't clear up filesystem space, and why it's more effective to truncate it instead. ( e.g. Run > /var/log/myhugeactivelogfile.log instead of rm /var/log/myhugeactivelogfile.log)

Sometimes you can even use this to recover an accidentally deleted file, if it's still held open in a process. You can go to /proc/$PID/fd, where $PID is the process ID of the process holding the file open, and find all the file descriptors it has in use, and then copy the lost content from there.

[-] Arcity@feddit.nl 10 points 1 week ago

rm doesn't remove memory in RAM

[-] SpaceCadet@feddit.nl 1 points 1 week ago* (last edited 1 week ago)

That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.

[-] Johanno@feddit.org 9 points 1 week ago

Since you forgot to add - - preserve-root It won't go too far. But at some point the system wants to load a file that is deleted and the kernel will panic. System crash. Delete incomplete. But rest assured, the important stuff is gone.

[-] SpaceCadet@feddit.nl 5 points 1 week ago

Since you forgot to add - - preserve-root It won’t go too far

Go on then ... try it.

Or don't because you will erase your system. (Hint: it's in the asterisk)

[-] Johanno@feddit.org 2 points 1 week ago

Or was it non preserve. I never tried it though. I guess a vm should be fine to test it. On the other hand I don't care enough.

[-] SpaceCadet@feddit.nl 2 points 1 week ago* (last edited 1 week ago)

The flag is called --no-preserve-root, but the flag wouldn't do anything here because you're not deleting root (/), you're deleting all non-hidden files and directories under root (/*), and rm will just let you do it.

Pretty sure it's --no-preserve-root or something similar.

this post was submitted on 09 Sep 2024
274 points (81.0% liked)

linuxmemes

20693 readers
912 users here now

I use Arch btw


Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS