Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 152 down vote favorite
32

I've often wondered how far the system will actually get if you run rm -rf /. I doubt the OS would be able to erase itself (?)

Bonus Question: After the command has been executed, will rm have removed itself?

Update: I've tested this in a couple of the main unix distributions using VirtualBox and the answers describe exactly what happens. If given the correct parameters, rm will remove every physical bit of data on the disc. However, I ran into some issues when using a version of rm other than the GNU one. For example, I believe BusyBox has their own version and it doesn't let you remove as much as you potentially could.

This question was a Super User Question of the Week.
Read the July 7th, 2011 blog entry for more details or submit your own Question of the Week.

share|improve this question
8  
It's funny that you asked this question. I was just answering another rm -f question on another forum and started remembering an article I read a while back. Luckily I saved it for times like this: THE classic Unix horror story Besides the fact that it's interesting to see how far it'll go... I think it's a very well written article and is a generally good read! – akseli Jul 20 '11 at 13:57
1  
I've just tried sudo rm -rf / on tinycore/microcore linux and it seems that the OS protects several directories (/sys and others) from being deleted. – MaxMackie Jul 20 '11 at 14:06
39  
I tried rm -f /bin/rm once. Unfortunately, it worked, and I spent the next hour getting the right version of rm back from GNU coreutils. – squircle Jul 20 '11 at 17:21
14  
Wait a sec, I will try... – Martijn Courteaux Jul 20 '11 at 18:16
23  
I do this at the apple store all the time – eggie5 Jul 21 '11 at 5:40
show 3 more comments

8 Answers

up vote 151 down vote accepted

If you have rm from GNU coreutils (most probably if it's a regular Linux distro), rm -rf / will be refused by the built-in protection (according to manpage and Wikipedia, haven't tried that).

You can override this protection with --no-preserve-root. rm will then remove everything it possibly can, without stopping after having attempted to remove every single file. Of course it won't remove virtual filesystems like /proc and /sys, but that's irrelevant – it will remove everything on your disk.

After the command finishes, you disk will be wiped empty, including the OS. The kernel and current processes will continue to run from memory, but many processes will die because they will fail to access some file. The OS will fail to boot next time.

share|improve this answer
54  
Exactly what I was looking for. Now to use this power TO TAKE OVER THE WORLD. – MaxMackie Jul 20 '11 at 15:55
28  
+1 especially for --no-preserve-root because that's usually not mentioned. – Matěj Grabovský Jul 20 '11 at 18:29
14  
@MaxMackie, it's worth noting that hackers very quickly found this to be the least useful thing they could do to a user. It destroys any data that could be used for cash gains, and prevents the hacker from further exploiting the machine. Like a cat with an insect, you don't want to kill it, you just want to play with it for a while because it's fun. – zzzzBov Jul 20 '11 at 21:55
3  
To answer the OP's other question, yes rm will remove itself. It is entirely possible to modify or delete an executable even while there is an instance of it running. It will keep running, too, and will be unaffected by the change. – thomasrutter Jul 21 '11 at 4:44
1  
Yes on the built-in protection; if you attempt it it will now say "rm: it is dangerous to operate recursively on `/'". It was not so once upon a time, however... – Michael Trausch Jul 21 '11 at 5:57
show 8 more comments
up vote 31 down vote

For those who like to do stuff like this visually while listening to techno music.

Running rm- rf on Linux (video)

Bonus points if you can name the processes as they start dying.

share|improve this answer
up vote 20 down vote

Set up a VM and try for fun?

It'll go quite far... if you're using a gui you might have fun noticing things degrade more visibly. (icons on menus stop loading etc.)

If you let it go, the OS will pretty much be beyond recovery though you may be able to get some data back easily.

Either way, you'll be wanting to do a reinstall of the OS.

share|improve this answer
6  
I didn't even think about trying it in a VM. Going to try now! ooo this is fun. – MaxMackie Jul 20 '11 at 13:53
27  
Mistakenly writes the command to the host system's Terminal – slhck♦ Jul 20 '11 at 13:58
1  
Check out the article I posted. "The Classic Unix Horror Story!" – akseli Jul 20 '11 at 14:00
I'm at work right now and don't have time to go through a full install of a popular distro (ubuntu/slack/suse/fedora). If anyone else can clone a VM disk file and try it for us, it would be awesome. – MaxMackie Jul 20 '11 at 14:08
Yes! I tried it on TinyCore running under QEMU - it was an interesting exercise... I wonder how many executable images I can get back from /proc... – new123456 Jul 22 '11 at 3:18
show 1 more comment
up vote 8 down vote

Well, trying it on http://bellard.org/jslinux/ produces:

rm: can't remove '/dev/pts': Device or resource busy
rm: can't remove '/dev': Directory not empty
rm: can't remove '/proc/swaps': Operation not permitted
rm: can't remove '/proc/kallsyms': Operation not permitted
rm: can't remove '/proc/dma': Operation not permitted

SNIP 881 entries

rm: can't remove '/proc/149/oom_adj': Permission denied
rm: can't remove '/proc/149': Operation not permitted
rm: can't remove '/proc': Device or resource busy
rm: can't remove '/tmp': Device or resource busy
rm: can't remove '/': Device or resource busy

share|improve this answer
1  
Yeah I get those errors/warnings too. Is this standard you think? – MaxMackie Jul 20 '11 at 14:28
5  
/proc, /sys, sometimes /dev, and any mountpoints are properties of the operating system and can't be deleted. – pjc50 Jul 20 '11 at 15:35
1  
Concurring with @pcj50, those are not literally files on the hard disk, so "deleting" them is not meaningful. – CarlF Jul 20 '11 at 17:11
up vote 7 down vote

I recall this being chewed over on alt.sysadmin.recovery back in days of yore, when there was no such thing as /proc, and /dev was just a regular directory containing entries for a bunch of unusual inodes...

... but, on some variants of Unix (my recollection is HP-UX, but that could be totally wrong), you could not remove the last directory entry for a program that was running. (Shared libraries? What are those?)

On such systems, if you started one up in maintenance mode (so nothing was running but your shell, not even init, and no secondary file systems were mounted) and did exec /bin/rm -rf /, you would be left with a completely empty root file system except that /bin and /bin/rm would survive.

The denizens of the scary devil monastery considered this to be fitting and proper.

share|improve this answer
up vote 3 down vote

rm -rf / shouldn't be allowed on recent implementations as it has been suggested it violates the POSIX standard:

"rm -rf /" protection on Oracle blog

Anyway, in the end, we got the spec modified, and Solaris 10 has (since build 36) a version of /usr/bin/rm (/bin is a sym-link to /usr/bin on Solaris) and /usr/xpg4/bin/rm which behaves thus:

[28] /bin/rm -rf /
rm of / is not allowed
[29]
share|improve this answer
2  
"pointing out that if one attempts to remove "/" recursively, one will ultimately attempt to remove ".." and ".", and that all we are doing is allowing rm to pre-determine this heuristically. Amazingly, they bought that! " - er, wouldn't that disallow removing any directory? The actual spec only disallows .. and . in the actual command-line arguments, it doesn't say anything about what you "ultimately attempt to remove" – Random832 Jul 20 '11 at 16:22
1  
Why would it disallow removing any directory ? The root directory is the only concerned here and removing it obviously imply removing "." and "..", whatever the current directory is. Common sense isn't forbidden in standard interpretation. – jlliagre Jul 20 '11 at 20:57
1  
That line of argumentation is pure genius. – Nate C-K Jul 20 '11 at 22:09
The standard specifies that rm is not allowed to continue if an argument has the string "." or ".." as the basename component. You cannot remove /foo/.. even if you're not in /foo. It does not specify that you're not allowed to remove the current directory (e.g. rm -r `pwd`) or the parent of the current directory. – Random832 Jul 20 '11 at 22:30
1  
Indeed, I misunderstood the statement and you are correct. Hopefully, the standard guys accepted the smarter behavior as being standard compliant. Removing large parts if not all of the file system would quickly make the OS non standard compliant anyway. – jlliagre Jul 20 '11 at 22:44
up vote 2 down vote

One point I didn't see made by anyone else: files that are currently open (e.g. rm itself), even if deleted, won't actually disappear fom the drive until closed.

share|improve this answer
That's right, because they're loaded in memory right? – MaxMackie Jul 20 '11 at 17:15
I'm not sure if that is safe to assume; the kernel could very well just load the removed file into memory and remove it on the disk immediately, and keep this in-memory copy until the file is open (e.g. until rm is running). – Ambroz Bizjak Jul 20 '11 at 17:25
I'm not speculating. If a program is running, deleting it does not remove it on my Linux boxes, at least. (Mind you I haven't tested this in, oh, a couple of years.) – CarlF Jul 20 '11 at 19:25
4  
rm will remove itself from the fs - the program is completely loaded in memory, not the file – warren Jul 20 '11 at 19:25
3  
@MaxMackie: not because they're loaded in memory, but because an open file reference have the same power as a hard-link (i.e. if a file has at least one hard link, it won't be deleted from the disk). – Lie Ryan Jul 20 '11 at 19:49
show 6 more comments
up vote 1 down vote

For having tried it once (on a server that what pissing me off), logged as root, in terminal, you'll lose almost everything. The only thing that'll not be erased will be only the process that was essential for the OS.

share|improve this answer
11  
"[not erased] only the process that was essential for the OS" - oh, don't worry. Unlike Windows, Linux will happily erase anything, even if the file is OS-critical and in use. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, gone. Good luck booting without those - in fact, good luck doing anything at all once the delete is finished. – Piskvor Jul 20 '11 at 16:26
If I recall there was some file that wasn't deleted, and I let my linux run for more than 4 hours. But still, it's good to know what happen, like doing a chmod 777 /* -fR ;) – Anarko_Bizounours Jul 21 '11 at 7:25
1  
"chmod 777 /* -fR" - That should just make the system very insecure, though very user-friendly. – Bart van Heukelom Jul 26 '11 at 18:41
did it, it's very insecure. You can't do a thing, some process need to have specific right, and the chmod 777 will change every right, you'll never be able to load a session, and some process to. – Anarko_Bizounours Jul 27 '11 at 6:35
1  
@BartvanHeukelom, some tools will perform a quick self-test, or be tested by the system for proper ownership and permissions and refuse to act if malconfigured. – killermist Jul 27 '12 at 12:40

protected by random♦ Jul 20 '11 at 22:16

This question is protected to prevent "thanks!", "me too!", or spam answers by new users. To answer it, you must have earned at least 10 reputation on this site.

Not the answer you're looking for? Browse other questions tagged or ask your own question.