this post was submitted on 09 Sep 2024
273 points (80.8% liked)

linuxmemes

21465 readers
1485 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
  •  

    Please report posts and comments that break these rules!


    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] [email protected] 17 points 2 months ago (5 children)

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

    [–] [email protected] 49 points 2 months ago* (last edited 2 months ago) (2 children)

    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.

    [–] [email protected] 13 points 2 months ago (1 children)

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

    [–] [email protected] 12 points 2 months ago* (last edited 2 months ago) (1 children)

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

    Edit: I just realized that the * is already in the meme. So this should already work as is. Alternatively you could always use the good old way of "act now and remove all French roots of your system: rm -fr / --no-preserve-root"

    [–] [email protected] 1 points 2 months ago (1 children)

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

    [–] [email protected] 3 points 2 months 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

    [–] [email protected] 2 points 2 months 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.

    [–] [email protected] 18 points 2 months ago* (last edited 2 months 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), or why Linux can upgrade a package that's currently running and the running process will just keep chugging along as the old version, until restarted.

    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.

    [–] [email protected] 10 points 2 months ago (1 children)

    rm doesn't remove memory in RAM

    [–] [email protected] 2 points 2 months ago* (last edited 2 months ago)

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

    [–] [email protected] 9 points 2 months ago (1 children)

    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.

    [–] [email protected] 5 points 2 months ago (1 children)

    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)

    [–] [email protected] 2 points 2 months ago (2 children)

    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.

    [–] [email protected] 3 points 2 months ago* (last edited 2 months 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.

    [–] [email protected] 1 points 2 months ago

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