It will complete, because unix file systems have the concept of hard links.
Filesystems operate like a brick-and-mortar library. In this metaphor, the files are books. But there's no way to just walk through the library, we must use the card catalog to know where the book is on the shelves--then we can go find it. If the card catalog doesn't have an entry, then the data is--for all practical purposes--not there (it is eligible to be dumped and replaced with other books). That card catalog to book linkage is a hard link. As long as there is at least one hard link in the library, we will keep the book around.
When you open a file in any way, the operating system temporarily creates another hard link--in memory--to the book in question.
In the case of programs, executing the program causes a hard link to be created (again, in memory) to the contents of the executable. Once the file is closed or the process exits, the OS cleans up the hard link it created in memory. If that was the last hard link, then the book is now free space and can be used for other purposes.
This means even if you ran rm \`which rm\`, it will complete and erase rm. This is no different than if you ran sudo rm -rf / with safeties disabled. The process will complete because there is temporarily and extra linkage to the underlying executable code. Once it completes its work, it will also remove itself.
Note that for the same reason, a bunch of other programs will continue to live on disk until they are forced to exit--usually because you've rebooted.
If I understand correctly, you are curious if the command will kinda delete itself and stop this way?
If I understand correctly how Linux works, it will load everything necessary to perform your command into ram. Also even when the RM command will be deleted from disk, since the system will know the RM file is in use, the file will be only marked for deletion, and deleted only after all references are gone.
30 years administering various *nix systems and I’ve never actually done this. I had a spare 20 minutes. Go to the 5 minute mark :)
https://youtu.be/JKUnFlJXaQU?si=UYWwWjmaBPP84Q2P
Well, strictly speaking it does nothing. `rm` will ignore `/` as an argument by default.
But assuming you override that, it will remove all files that the superuser can remove. There's really not much more to it than that. Of course, any process that _needs_ any of those files is going to be disappointed. Any attempt to look up a filename will fail, as well as any attempt to add a file to a directory that has been removed. One would hope processes would error out cleanly when that happens, though you're probably going to exercise error paths that aren't tested regularly.
Processes that have files open will still have those files open. In particular, `rm` will quite happily keep running until it has finished removing everything.
The kernel certainly doesn't care that you've emptied the filesystem out.
There isn't any particular point where it "explodes". In fact, depending on the software you happen to be running, things could keep working just fine. An in-memory database server will probably still keep serving its clients, for instance.
>There isn't any particular point where it "explodes".
Well, your shell will get pretty unhappy when you try to run any program. Then the sysadmin will get pretty unhappy.
`rm` has defaulted to preserving root for well over a decade now. `rm -rf /` is perfectly safe, assuming you haven't aliased `rm` to `rm --no-preserve-root` for some reason.
>`rm` has defaulted to preserving root for well over a decade now.
In fact, it is so commonplace that it is actually POSIX-mandated behaviour (since Issue 7, POSIX.1-2017). It's not just a GNU or Linux thing.
I've been on the receiving end of this, decades ago. Hacker got root on a Linux box I used (not mine but I had the root password), changed the root password (this was before many sysadmins bothered with `sudo`), then `rm -rf`'d the drive. I got to watch it as it happened.
At no point did my SSH bash session fail! But as `/bin` and `/sbin` started to disappear, less and less things would work from the command line. I lost `ps`, I eventually lost `ls`. All I could do is autocomplete in Bash to see what was left on the drive, which worked for awhile. Eventually even that started erroring out. The shell was still active, but there was nothing useful it would do anymore.
I said farewell and typed `exit`, and that was the last I heard from that system.
1. Yes, it will delete all files
2. At some point, system will crash. E.g: when it stats deleting processes and other things from OS ( /proc directory)
> At some point, system will crash
Not necessarily.
I ran this in a couple of different Docker containers (a Debian one and an Alpine one) and the `rm` command returned (having failed to delete stuff from `/proc` - not even root can do that) and dropped me back into a bash or sh shell directly. Aside from only having access to shell builtins (`ls` is gone, so it's `echo /*` from here on out) it kept working as normal.
Admittedly Docker is cheating because there's no `init`. If you kill pid 1 it's game over. But I couldn't be bothered getting a sacrificial VM up and running to test.
Yes, Docker is saving the instance in this scenario. It will work differently in VM / physical host. System will crash as soon as root deletes RW files in /proc
There are no RW files in /proc though. Procfs isn't a regular file system where deleting files is possible or meaningful, and the kernel won't let anyone do it, even root, because it simply doesn't support deletion.
The command `sudo rm -rf /` is used in Unix-like operating systems to delete files and directories. Breaking it down:
- `sudo` elevates the command's privileges, allowing it to operate with administrative or root permissions.
- `rm` is the remove command.
- `-rf` are options where `-r` stands for recursive, meaning it includes all files and directories within a specified directory, and `-f` stands for force, meaning it skips prompts and warnings.
- `/` specifies the root directory of the filesystem.
Thus, `sudo rm -rf /` would attempt to delete all files and directories from the root downwards, effectively wiping the contents of the drive on which the root filesystem resides. This is extremely destructive and typically disabled by default on modern systems to prevent accidental execution.
This what kvm is for.... do shit without the consequences following you.
Just don't share your home directory or anything silly with the vm you're about to nuke....
Somebody long ago [tried this](https://web.archive.org/web/20041213034031/http://hohle.net/scrap_post.php?post=23&m=full) (may have to reload it if there’s an error).
[Slashdot comments](https://slashdot.org/story/51390) in response were funny.
If you boot into Windows, login as an Administrator, open Windows explorer go to C:\ and then select all -> delete.
That’s basically what it does.
Maybe Windows wont let you but Linux used to (there’s a —no-preserve-root argument now). rm also bypasses the recycle bin so it’s the same as using Shift+Delete on Windows.
`rm` gets loaded into memory, the program deletes everything, even the copy of itself on disk that is running from memory, the program finishes and you get a brick.
About 30+ years ago (I think about 1993 or so), I convinced a new MU\* sysadmin guy to type sudo rm -fr / and it made waves all over the MU\* worlds at the time because I had logged it and posted the conversation. He was a very, very, very annoying guy who nobody liked and we all laughed very hard at the prank. This happened on a MUX that was invite-only and for heads of other MU\*s to converse at the time, run by a good friend of mine.
However, in retrospect, with more advanced years and age, I've come to regret that prank a little bit - not completely, mind, but a little tinge of "I was a real asshole back then to that guy...."
>a little tinge of "I was a real asshole back then to that guy...."
I mean, maybe, but how come he was a sysadmin and didn't know by himself what the command would do?
Programs on Linux are loaded into RAM and do not require access to their executable after they start. Because of that, it can delete the executable it is running from, but that won't terminate it. It's somewhat different on Windows as Windows requires the executable of a process to remain. It puts a read-only lock on it.
I worked at as place once, a religious broadcaster, the main IT/tech left under a cloud, then we found he'd put TrueCrypt on key machines. It took police intervention to make him realise the only outcome i.e. give us the keys.
I have seen this done on Solaris 2.5, and it did not run to completion. But that might be dependent on the particular implementation of `rm -r` .
On Solaris, `rm` implements `-r` by actually recursing. For each subdirectory, it ran a new process after `cd` into the new level.
Solaris actually looked for `/bin/rm` each time, even though all the code would be in RAM already and could be shared. Being as `/bin` is first in `/`, the recursion failed after wiping `/bin`. Still hard to recover from, as you just wiped all the shells, tar etc, but it did not wipe `/etc` or `/home`.
YMMV, and you would have to be seriously off the wall to try this.
It will complete, because unix file systems have the concept of hard links. Filesystems operate like a brick-and-mortar library. In this metaphor, the files are books. But there's no way to just walk through the library, we must use the card catalog to know where the book is on the shelves--then we can go find it. If the card catalog doesn't have an entry, then the data is--for all practical purposes--not there (it is eligible to be dumped and replaced with other books). That card catalog to book linkage is a hard link. As long as there is at least one hard link in the library, we will keep the book around. When you open a file in any way, the operating system temporarily creates another hard link--in memory--to the book in question. In the case of programs, executing the program causes a hard link to be created (again, in memory) to the contents of the executable. Once the file is closed or the process exits, the OS cleans up the hard link it created in memory. If that was the last hard link, then the book is now free space and can be used for other purposes. This means even if you ran rm \`which rm\`, it will complete and erase rm. This is no different than if you ran sudo rm -rf / with safeties disabled. The process will complete because there is temporarily and extra linkage to the underlying executable code. Once it completes its work, it will also remove itself. Note that for the same reason, a bunch of other programs will continue to live on disk until they are forced to exit--usually because you've rebooted.
If I understand correctly, you are curious if the command will kinda delete itself and stop this way? If I understand correctly how Linux works, it will load everything necessary to perform your command into ram. Also even when the RM command will be deleted from disk, since the system will know the RM file is in use, the file will be only marked for deletion, and deleted only after all references are gone.
30 years administering various *nix systems and I’ve never actually done this. I had a spare 20 minutes. Go to the 5 minute mark :) https://youtu.be/JKUnFlJXaQU?si=UYWwWjmaBPP84Q2P
Glad I could provide the inspiration, and thanks for the demonstration
Lol. So weird that it continues interacting but can't do anything.
Well, strictly speaking it does nothing. `rm` will ignore `/` as an argument by default. But assuming you override that, it will remove all files that the superuser can remove. There's really not much more to it than that. Of course, any process that _needs_ any of those files is going to be disappointed. Any attempt to look up a filename will fail, as well as any attempt to add a file to a directory that has been removed. One would hope processes would error out cleanly when that happens, though you're probably going to exercise error paths that aren't tested regularly. Processes that have files open will still have those files open. In particular, `rm` will quite happily keep running until it has finished removing everything. The kernel certainly doesn't care that you've emptied the filesystem out. There isn't any particular point where it "explodes". In fact, depending on the software you happen to be running, things could keep working just fine. An in-memory database server will probably still keep serving its clients, for instance.
>There isn't any particular point where it "explodes". Well, your shell will get pretty unhappy when you try to run any program. Then the sysadmin will get pretty unhappy.
Stop trolling people
`rm` has defaulted to preserving root for well over a decade now. `rm -rf /` is perfectly safe, assuming you haven't aliased `rm` to `rm --no-preserve-root` for some reason.
>`rm` has defaulted to preserving root for well over a decade now. In fact, it is so commonplace that it is actually POSIX-mandated behaviour (since Issue 7, POSIX.1-2017). It's not just a GNU or Linux thing.
What?
I've been on the receiving end of this, decades ago. Hacker got root on a Linux box I used (not mine but I had the root password), changed the root password (this was before many sysadmins bothered with `sudo`), then `rm -rf`'d the drive. I got to watch it as it happened. At no point did my SSH bash session fail! But as `/bin` and `/sbin` started to disappear, less and less things would work from the command line. I lost `ps`, I eventually lost `ls`. All I could do is autocomplete in Bash to see what was left on the drive, which worked for awhile. Eventually even that started erroring out. The shell was still active, but there was nothing useful it would do anymore. I said farewell and typed `exit`, and that was the last I heard from that system.
> exit “Farewell, my friend” 😭
Remove French language pack "rm -fr /"
1. Yes, it will delete all files 2. At some point, system will crash. E.g: when it stats deleting processes and other things from OS ( /proc directory)
Easy to validate this, just create a VM and try this. Even a docker intstance will work
make sure to mount the host root directory before trying!
They will learn very quickly ;)
> At some point, system will crash Not necessarily. I ran this in a couple of different Docker containers (a Debian one and an Alpine one) and the `rm` command returned (having failed to delete stuff from `/proc` - not even root can do that) and dropped me back into a bash or sh shell directly. Aside from only having access to shell builtins (`ls` is gone, so it's `echo /*` from here on out) it kept working as normal. Admittedly Docker is cheating because there's no `init`. If you kill pid 1 it's game over. But I couldn't be bothered getting a sacrificial VM up and running to test.
Yes, Docker is saving the instance in this scenario. It will work differently in VM / physical host. System will crash as soon as root deletes RW files in /proc
There are no RW files in /proc though. Procfs isn't a regular file system where deleting files is possible or meaningful, and the kernel won't let anyone do it, even root, because it simply doesn't support deletion.
The command `sudo rm -rf /` is used in Unix-like operating systems to delete files and directories. Breaking it down: - `sudo` elevates the command's privileges, allowing it to operate with administrative or root permissions. - `rm` is the remove command. - `-rf` are options where `-r` stands for recursive, meaning it includes all files and directories within a specified directory, and `-f` stands for force, meaning it skips prompts and warnings. - `/` specifies the root directory of the filesystem. Thus, `sudo rm -rf /` would attempt to delete all files and directories from the root downwards, effectively wiping the contents of the drive on which the root filesystem resides. This is extremely destructive and typically disabled by default on modern systems to prevent accidental execution.
So it clears up a lot of space! ;-)
Name checks out.
This what kvm is for.... do shit without the consequences following you. Just don't share your home directory or anything silly with the vm you're about to nuke....
Somebody long ago [tried this](https://web.archive.org/web/20041213034031/http://hohle.net/scrap_post.php?post=23&m=full) (may have to reload it if there’s an error). [Slashdot comments](https://slashdot.org/story/51390) in response were funny.
so old!
If you boot into Windows, login as an Administrator, open Windows explorer go to C:\ and then select all -> delete. That’s basically what it does. Maybe Windows wont let you but Linux used to (there’s a —no-preserve-root argument now). rm also bypasses the recycle bin so it’s the same as using Shift+Delete on Windows.
`rm` gets loaded into memory, the program deletes everything, even the copy of itself on disk that is running from memory, the program finishes and you get a brick.
About 30+ years ago (I think about 1993 or so), I convinced a new MU\* sysadmin guy to type sudo rm -fr / and it made waves all over the MU\* worlds at the time because I had logged it and posted the conversation. He was a very, very, very annoying guy who nobody liked and we all laughed very hard at the prank. This happened on a MUX that was invite-only and for heads of other MU\*s to converse at the time, run by a good friend of mine. However, in retrospect, with more advanced years and age, I've come to regret that prank a little bit - not completely, mind, but a little tinge of "I was a real asshole back then to that guy...."
>a little tinge of "I was a real asshole back then to that guy...." I mean, maybe, but how come he was a sysadmin and didn't know by himself what the command would do?
Programs on Linux are loaded into RAM and do not require access to their executable after they start. Because of that, it can delete the executable it is running from, but that won't terminate it. It's somewhat different on Windows as Windows requires the executable of a process to remain. It puts a read-only lock on it.
Try it in a VM
it will remove every file from the system from the top down. Save this for your last day in a shitty job, but do it anonymously ;)
https://en.m.wikipedia.org/wiki/Terry_Childs_(network_administrator) No matter how shitty your job is, going to jail for it is for idiots.
I worked at as place once, a religious broadcaster, the main IT/tech left under a cloud, then we found he'd put TrueCrypt on key machines. It took police intervention to make him realise the only outcome i.e. give us the keys.
cleans up wasted bloat from your root partition
I have seen this done on Solaris 2.5, and it did not run to completion. But that might be dependent on the particular implementation of `rm -r` . On Solaris, `rm` implements `-r` by actually recursing. For each subdirectory, it ran a new process after `cd` into the new level. Solaris actually looked for `/bin/rm` each time, even though all the code would be in RAM already and could be shared. Being as `/bin` is first in `/`, the recursion failed after wiping `/bin`. Still hard to recover from, as you just wiped all the shells, tar etc, but it did not wipe `/etc` or `/home`. YMMV, and you would have to be seriously off the wall to try this.
Easily testable with a docker image no?
Create a snapshot of your virtual machine, run the command. See what happens. Rollback the virtual machine to the previous snapshot.
No idea, let me check!
He's dead, Jim
Legends say that he’s still trying to reply.