People who don't understand Terminal are often afraid to use it for fear that they might mess up their command and crash their computer. Those who know Terminal better know that that's not the case - usually Terminal will just output an error. But are there actually commands that will crash your computer?

WARNING: you could lose data if you type these or copy paste, especially sudo and rm commands.

  • 7
    The Terminal is just a command-line interface to running programs. It is an alternative to a graphical user interface. You can run arbitrary programs from either one. Your question therefore doesn't really make a lot of sense; you instead should be asking: Can you crash your computer by running a program?
    – jamesdlin
    Commented Aug 2, 2017 at 6:15
  • What do you mean by "crash"? Commands run in the terminal can often be powerful and will often "do what you say and not what you mean" without asking, unlike most Mac OS X GUI commands. But unless you intentionally try to, you're unlikely to crash the machine. (I can think of a few ways to intentionally do so however)
    – Josh
    Commented Aug 2, 2017 at 16:25
  • 1
    Pasting commands wrom the web can be very dangerous. Regardless of possibility to hang your machine. Typing commands that you understand at least vaguely shouldn't be dangerous though. Otherwise a lot of ways to screw your computer. It's like clicking on random system configuration settings in GUI but in GUI at least possibilities are more limited. wrt the danger of pasting commands - the text you visually see copied can be different from the actual text copied, thus it can contain malicious commands intermixed. Commented Aug 4, 2017 at 8:43
  • @иσαнcяişтiпσ Maybe serverfault.com/questions/769357/recovering-from-a-rm-rf
    – wythagoras
    Commented Aug 6, 2017 at 18:13
  • @wythagoras that's the one Commented Aug 7, 2017 at 12:12

13 Answers 13


One way to crash a computer is to execute a so called fork-bomb.

You can execute it on a unix-sytem by:

:(){ :|: & };:

It's a command that will recursively spawn processes till the OS is so busy it won't respond to any action anymore.

  • 53
    @bunyaCloven if I understand your command correctly, then it's a command to remove all folders without prompting, which is very dangerous if it works. I wish you wrote a warning notice for that.
    – Andrew T.
    Commented Jul 31, 2017 at 8:27
  • 83
    @AndrewT. People shouldn't just type random commands they found on the Internet all willy-nilly. (especially ones in a thread called "can you crash your computer via terminal") Commented Jul 31, 2017 at 11:16
  • 37
    The OP asked for a crash from the terminal, not a wipe.
    – piersb
    Commented Jul 31, 2017 at 15:27
  • 16
    The fork bomb will actually do minimal damage on Mac OS X as it has upper bounds for the number of processes.
    – GDP2
    Commented Jul 31, 2017 at 15:35
  • 7
    @bunyaCloven replace the ; with an & and you get to remove all files and fork bomb at the same time, and see which breaks the system first!
    – Muzer
    Commented Aug 1, 2017 at 11:16

Not sure what you mean about 'crash'ing the computer - if you would re-phrase it to say 'render the computer unusable', then yes. Certainly all it takes is a single stray command - just a moment where you're not thinking clearly about what you're doing, similar to when you speak without thinking, and the damage can be immense and almost immediate. The classic example:

$ sudo rm -rf /

If you let that command run for even just one second, that can wipe out enough of your system to render it unbootable, and possibly cause irreversible data loss. Don't do it.

  • 2
    And just to share why I wanted to clarify the re-phrasing .. to 'crash' the computer in the traditional sense - to make it lock up - you'd need to give the CPU enough work to do that it can't respond in a timely fashion to other jobs .. like updating the graphics and move the cursor, for example. I'm sure there's a way to do that from the command-line.
    – Harv
    Commented Jul 31, 2017 at 3:35
  • 6
    @DonielF -r means to recursively delete files in a directory. -f means "force" as in don't ask for confirmation, regardless of a given file's permissions. / is the root directory of the filesystem, which means it will destroy anything and everything, except maybe some special files that don't behave as typical files. Also, you'll have a pretty hard time finding a brief command that will crash your system without root / admin permissions.
    – GDP2
    Commented Jul 31, 2017 at 4:52
  • 11
    I tried rm -rf / a while back, and rm said that if you want to remove root, then use such-and-such flag. No data was lost. It seems like there is a security protection now from blindly running rm -rf /.
    – alexyorke
    Commented Jul 31, 2017 at 11:50
  • 27
    --no-preserve-root flag has been required since 2006 for this to work as intended
    – Encaitar
    Commented Jul 31, 2017 at 15:13
  • 6
    Here's a real-world case in which this actually happened - a rm -rf really similar to a legal one, that went really wrong :/ Commented Jul 31, 2017 at 21:06

Suppose you don't know what your doing and attempting to do a backup of some hard drive

dd if=/dev/disk1 of=/dev/disk2 

Well if you mix those up (switch if and of), it will overwrite the fresh data with old data, no questions asked.

Similar mix ups can happen with archive utils. And frankly with most command line utilities.

If you want an example of a one character mix up that will crash your system take a look at this scenario: You want to move all the files in the current directory to another one:

 mv -f ./* /path/to/other/dir

Let's accept the fact that you learned to use ./ to denote the current directory. (I do) Well if you omit the dot, it will start moving all your files. Including your system files. You are lucky you didn't sudo this. But if you read somewhere that with 'sudo -i' you will never again have to type in sudo you are logged in as root now. And now your system is eating itself in front of your very eyes.

But again I think stuff like overwriting my precious code files with garbage, because I messed up one character or because I mixed up the order of parameters, is more trouble.

Let's say I want to check out the assembler code that gcc is generating:

gcc -S program.c > program.s

Suppose I already had a program.s and I use TAB completion. I am in a hurry and forget to TAB twice:

gcc -S program.c > program.c

Now I have the assembler code in my program.c and no c code anymore. Which is at least a real setback for some, but to others it's start-over-from-scratch-time.

I think these are the ones that will cause real "harm". I don't really care if my system crashes. I would care about my data being lost.

Unfortunately these are the mistakes that will have to be made until you learn to use the terminal with the proper precautions.

  • 16
    Your last point is one of many reasons why everyone should use version control
    – Darren H
    Commented Jul 31, 2017 at 12:58
  • 4
    I once destroyed a program I was working on using gcc program.c -o program.c thanks precisely to tab completion. I learned to use version control religiously after that.
    – nneonneo
    Commented Aug 1, 2017 at 19:30
  • 2
    The best answer so far, posting legitimately-looking commands that could be results of a simple typo and yet can result in a major damage.
    – gaazkam
    Commented Aug 1, 2017 at 21:32
  • 1
    "Now I have the assembler code in my program.c" Nope. You have nothing. The redirection truncated the file before GCC even opened it.
    – muru
    Commented Aug 3, 2017 at 5:32
  • 1
    Oh man, I am actually really happy they added that user-interface improvement in GCC. It's been a while since my last blunder, but it's nice to see that I'll have a little protection from that next time.
    – nneonneo
    Commented Aug 6, 2017 at 17:57

Causing a kernel panic is a more akin to crashing than the other answers I've seen here thus far:

sudo dtrace -w -n "BEGIN{ panic();}"

(code taken from here and also found in Apple's own documentation)

You might also try:

sudo killall kernel_task

I haven't verified that the second one there actually works (and I don't intend to as I actually have some work open right now).

  • 2
    Just tried the second one in a 10.12.3 VM, and it just says: No matching processes were found Commented Jul 31, 2017 at 6:00
  • 3
    Also, the first one doesn't seem to work, at least if SIP is enabled, dtrace: system integrity protection is on, some features will not be available dtrace: description 'BEGIN' matched 1 probe dtrace: could not enable tracing: Permission denied Commented Jul 31, 2017 at 6:01
  • @AlexanderO'Mara Not very surprised with your results on the second command; I figured that Mac OS X wouldn't allow you to just take down the kernel process in such a way. The results for the first command are also to be expected, as dtrace was effectively neutered by SIP.
    – GDP2
    Commented Jul 31, 2017 at 15:48
  • 1
    kernel_task is not a normal process. It's immortal; It can't be killed except through an error of its own (and that would be called a KP and brings the entire machine down). kernel_task's PID is nominally 0, but if you supply that to the kill(pid, sig) syscall, the man page says If pid equals 0, then sig is sent to every process in the process group of the calling process.. So you're simply unable to send kernel_task a signal. Commented Jul 31, 2017 at 16:40
  • @IwillnotexistIdonotexist Yeah, I figured as much would be the case; thanks for the info, though. Good stuff to have in mind.
    – GDP2
    Commented Jul 31, 2017 at 16:46

Modern macOS makes it really hard to crash your machine as an unprivileged user (i.e. without using sudo), because UNIX systems are meant to handle thousands of users without letting any of them break the whole system. So, thankfully, you'll usually have to be prompted before you do something that destroys your machine.

Unfortunately, that protection only applies to the system itself. As xkcd illustrates, there's lots of stuff that you care about that isn't protected by System Integrity Protection, root privileges or password prompts:

XKCD 1200

So, there's tons of stuff you can type in that will just wreck your user account and all your files if you aren't careful. A few examples:

  • rm -rf ${TEMPDIR}/*. This seems totally reasonable, until you realize that the environment variable is spelt TMPDIR. TEMPDIR is usually undefined, which makes this rm -rf /. Even without sudo, this will happily remove anything you have delete permissions to, which will usually include your entire home folder. If you let this run long enough, it'll nuke any drive connected to your machine, too, since you usually have write permissions to those.
  • find ~ -name "TEMP*" -o -print | xargs rm. find will normally locate files matching certain criteria and print them out. Without the -o this does what you'd expect and deletes every file starting with TEMP* (as long as you don't have spaces in the path). But, the -o means "or" (not "output" as it does for many other commands!), causing this command to actually delete all your files. Bummer.
  • ln -sf link_name /some/important/file. I get the syntax for this command wrong occasionally, and it will rather happily overwrite your important file with a useless symbolic link.
  • kill -9 -1 will kill every one of your programs, logging you out rather quickly and possibly causing data loss.
  • 3
    FYI (for others reading this) find has a -delete argument which is much safer than piping to xargs rm
    – Josh
    Commented Aug 2, 2017 at 16:26
  • Is modern MacOS really more crashproof? Most of these systems are for a single user. Do they really have sane maxprocs/cpulimits? Can you provide a reference?
    – user2497
    Commented Aug 2, 2017 at 22:38
  • 1
    You, of all people, would know well the damage ln -sf can do... and how to recover from it :-) Commented Aug 3, 2017 at 9:41
  • 1
    @Josh: thanks for pointing that out. And, in the general case, one should use find -print0 | xargs -0 to safely handle strange characters in filenames.
    – nneonneo
    Commented Aug 3, 2017 at 14:18
  • 1
    Agreed. More useful xargs advice: use <whatever> | xargs echo <something> first, to preview what commands xargs will actually run. xargs is a great example of why the CLI is so powerful: you can operate on many, many items at once without pesky confirmation and hand-holding... just make sure you're telling it to do what you want.
    – Josh
    Commented Aug 3, 2017 at 17:40

Another one you can do (that I have done by mistake before) is:

sudo chmod 0 /

This will render your entire file system (which means all commands and programs) unaccessible...except by the root user. This means you would need to log in directly as the root user and restore the file system, BUT you are unable to access the sudo command (or any other command, for that matter). You can restore access to commands and files by booting into single-user mode, mounting and restoring the file system with chmod 755 /.

If this is done recursively with chmod -R 0 / then this will render the system unusable. The proper fix at that point is to use Disk Utility from the recovery partition to repair disk permissions. You may be better off just to restore a snapshot or backup of your file system if this was run recursively.

  • 9
    "You can fix it by ... chmod 755 / " - No you cannot. Many files require different permissions from 755, either for security, or to work at all. chmod 755 / will leave your system insecure and broken in subtle ways. The only full recovery from chmod 0 / is through snapshot restore, backup restore, and/or reinstall.
    – marcelm
    Commented Aug 1, 2017 at 16:42
  • 2
    @marcelm Good point. My suggestion was only to restore access to commands, not as a permanent fix. I've updated my answer to reflect that. As far as I know, chmod is not recursive unless you use the -R flag - so I thought subdirectories' permissions would not be affected? Commented Aug 1, 2017 at 17:41
  • 5
    @marcelm you are right, but the command shown is not recursive so only / is affected. Commented Aug 1, 2017 at 20:24
  • I once sudo chmod -R 700 / a new computer, figuring it would be a lot more secure if I did that. Surprisingly, it booted, and ended up with an empty menubar and blank desktop. Nothing else worked, but the recovery partition's Disk Utility Restore Permissions actually managed to set almost everything right!
    – nneonneo
    Commented Aug 1, 2017 at 21:53
  • 2
    @marcelm Disk utility has a "Fix Permissions" option which should correct this without a full system restore
    – Josh
    Commented Aug 2, 2017 at 16:31

Answers that call sudo should be considered invalid. These already assume administrative access to the system.

Try perl -e 'exit if fork;for(;;){fork;}'. OSX may have some safeguard against this now. If is presents an apple bubble asking if you want to terminate Terminal app and subprocesses, you're (almost) good.

while true ; do cat /dev/zero > /dev/null & done is also very handy, esp. if you don't have perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & done will just do a funny little CPU load test. Very good for checking if your heatsink and fan are up to par.

  • This is known as a Fork Bomb and will likely render the system unusable (could be considered a "crash") but will not likely cause any permanent damage. But it's nasty!
    – Josh
    Commented Aug 2, 2017 at 16:35
  • @Josh "but will not likely cause any permanent damage" Except for any currently-open unsaved work.
    – reirab
    Commented Aug 3, 2017 at 14:52
  • @reirab Josh added the catch-all 'likely' to his statement. But MacOS is mostly for editing photos and video now. Don't the Adobe programs have automatic auto-save?
    – user2497
    Commented Aug 3, 2017 at 16:04
  • 1
    Also, unsaved work is always at risk until it's saved. If your computer is rendered unusable, then you can't save anything you have open :)
    – Josh
    Commented Aug 3, 2017 at 17:37
  • @Josh MacOS is so easy to save stuff in. It's always 🍎-S. You shouldn't have written 'likely' 👋🏾
    – user2497
    Commented Aug 3, 2017 at 17:40
sudo kill -9 -1  

I accidently performed a kill -9 -1 in a perl-script, running as root. That was as fast, as pulling the power-cord. On reboot, the server made a filesystem-check and continued running properly.

I never tried that sudo kill -9 -1 command on the commandline. It might not work, because the process-ID "-1" means "kill all processes that belongs to the caller's process-group".

Not sure, if with sudo, that also means init and all the kernel-stuff... But if you are root, kill -9 -1 will definitely make an immediate stop - just like pulling the power-cord. By the way - nothing will appear in logfiles, because that command is the fastest killer in the west!

Actually, to recover, I went to our sysadmins and told them, what I did. They did a hard reboot, because there was no way to log in on that server (RHEL6).

A kill -9 -1 as root kills every process, that runs as root. That is i.e. sshd. That logged me out immediately and prevented anyone from logging in again. Any process started by init - including init have been killed, unless they changed UID or GID. Even logging in through serial console wasn't possible any more. ps -eaf | grep root shows some fancy processes, which, if they react on a SIGKILL in the default way, would pretty much stop even basic writing to HD.

I will not try this now on my laptop :-) I am not curious enough to finding out, if a kill -9 165 ([ext4-rsv-conver]) would really stop writing to the HD.

  • You can't "kill" the kernel, and this shouldn't cause a filesystem check in and of itself. How did you recover from the situation? Did you do a hard reboot? Because that's probably what caused the filesystem check :)
    – Josh
    Commented Aug 2, 2017 at 16:21
  • Your edited answer makes sense. You can't actually kill init normally, but you can kill all gettys and SSH sessions and render the machine unusable. A Magic SysRq should have allowed for a clean reboot, but it's often easier to just power-cycle and rely on the FS journal :)
    – Josh
    Commented Aug 2, 2017 at 19:12

Sure, make sure you have a backup and save any files you care about, then type halt

Assuming you then use sudo to be root, the Mac will crash.

The biggest risk from command line is data loss. The macOS interface is designed over decades to not surprise people and shred their data or settings or apps. The macOS graphical interface also exists to remove the learning curve (a steep one) to being safe and mastering shell scripting.

You lose those protections which is why I caution people starting with terminal app or ssh. If you have a backup you know works and have the time and confidence/skill to perform a restore, then you should dive in and learn and even break things.

  • 3
    You said, "... and even break things.", which is a good use case for one to do risky stuff in a virtual machine. :) Commented Jul 31, 2017 at 21:44
  • 2
    How will this crash? It just shuts the system down immediately. It even flushes kernel buffers so there's no (saved) data loss. developer.apple.com/legacy/library/documentation/Darwin/…
    – Josh
    Commented Aug 2, 2017 at 16:47

Yes, you can completely destroy your system. Accidentally doing something with sudo privileges is one example that has been posted, whether it's forgetting a few characters that instruct the terminal to do something completely different than you intended. rming / instead of /tmp/\* is only a 5 character difference. Putting a space in the wrong place could do something completely different as well. Other times, seemingly well meaning instructions could have malicious code obfuscated into it. Some people on the internet are very good at obfuscating code.

There are also commands that, using html, can be made font size zero, so something completely innocuous looking, when copied to the clipboard, could in fact be installing someone's git repo as a trusted source and downloading malware.

And there are commands that you can run that open you to exploit, or that could be perfectly well intended but removes important files or programs or corrupts your disk. In fact, using tools incorrectly could do something as basic as accidentally writing over your boot sector, or the head of your disk, or lots of other issues.

An example of something less destructive that hasn't been posted is opening binary files in vi. If you've ever tried it, you'll know that it can mess up your terminal to the point that it's unusable until it is reset.

Alternatively, there are commands that will bog down your machine, like:

yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & 

You can try that one, it's not going to do damage, but it will bog down your processor, and you'll have to kill each process you've spawned.

That being said, in computing it's generally taken that you can't make an omelette without breaking a few eggs. You should be cautious at the terminal, but the only way that one can become better at using the OS is by learning and practicing.

  • Your first example is hardly harmful. Vim is actually quite sane when editing binary files. And in the worst case you can just close down the window. The second example with "yes" is annoying and will use up a fair bit of user CPU, but the system will remain responsive and you can easily kill the parent terminal window.
    – nneonneo
    Commented Aug 2, 2017 at 3:06
  • 1
    I disagree with "mess up your terminal to the point that it's unusable until you restart" -- try reset, that should clear up a terminal which has had binary output printed to it. or, just spawn a new TTY
    – Josh
    Commented Aug 2, 2017 at 16:27
  • 1
    Cool, nw @JFA. It actually took me nay years to learn the reset trick! For more info: unix.stackexchange.com/questions/79684
    – Josh
    Commented Aug 2, 2017 at 19:41
  • 1
    @Josh thank you for that, it was a big help. It has indeed been many years for me :P
    – jfa
    Commented Aug 2, 2017 at 19:43
  • 1
    @Josh Then 'stty sane^M' and 'tput reset' should also be exciting for you.
    – user2497
    Commented Aug 2, 2017 at 22:43

I am only a bash beginner, but you could use something like this:

while True; do COMMAND; done;

Most people would try to use Ctrl+C to stop the command, not the external process (Ctrl+Z, which then need to be killed).

If the command in the while True loop is a resource-intensive operation (such as multiplying large number to its own power), that could mess with your system resources and bog down your processor. However, modern operating systems are usually protected against such catastrophes.

  • 2
    It just runs really fast, it won't crash anything. You just got to fork some intensive calculations so kernel maxprocs doesn't make you sad. try while true do cat /dev/zero > /dev/null & done
    – user2497
    Commented Aug 1, 2017 at 14:06
  • thanks. I would have expected handling large numbers to make the computer go slow, it sometimes happened with very simple java/python programs I used for machine learning.
    – Ando Jurai
    Commented Aug 1, 2017 at 14:43
  • 1
    The cat zero to null bit is a big number operation, in I/O at least. I use one of these per core of a CPU to do thermal tests.
    – user2497
    Commented Aug 1, 2017 at 14:45
  • 1
    And ^C will kill the while loop also, but it just repeats too fast for the interrupt to be caught. Holding down ^C may break out of the loop. Closing the terminal also will :)
    – Josh
    Commented Aug 2, 2017 at 16:37
  • 2
    @Josh It is easier to catch INT if there's a tiny pause, like sleep 0.1, after the cpu-intensive task.
    – user2497
    Commented Aug 2, 2017 at 22:45

Surely you still can cause a system crash using commands entered with Terminal.

With years it's getting harder probably due to all kinds of limits and protective measures applied but as Murphy's-like law states: "Nothing is foolproof to a sufficiently capable fool."

"Fork bombs" and all that rm -rf script kiddies stuff are anciently known things for UNIX. With Mac OS X you can have more fun using its GUI sub-system parts (WindowServer to mention) or something like OpenBSD firewall aka PF that Apple's engineers brought in but never managed to update since its 2008 state of things. PF works in kernel so when it catches a quirk it's time Apple tells you "you restarted computer due to a panic" or stuff like this.

The worst part of this is you never can have an idea of where-n-why it panicked — cause Apple doesn't provide any meaningful stack traces; you can only have hex numbers of stack frame's return addresses.

  • Good answer, and excellent points. I would like to add to your list of fine ways to get OS X to panic on the dance floor my personal favorite, yet without explicit terms to avoid script kiddie stupidities. I unload a kernel extension relevant to NFC. Works every time, instantly. One can easily weaponize this into a DOS by scheduling this at a divisible number of like 5 mins. Hence it will boot then swan dive. This necessitates a reinstall of the OS given most admins and even techs will miss this.... Commented Sep 29, 2018 at 10:14

It's a little ambiguous what you mean by "crash" your computer... and there's no definitive correct answer for that, although there's some useful examples in other answers. Since your question is more ambiguous and general, I'd like to focus on the nature of the question and give a more general answer.

People who don't understand Terminal are often afraid to use it for fear that they might mess up their command and crash their computer

I think the command line is a double-edged sword, and often a very sharp one. Its greatest strength is also its biggest weakness for new users: CLI programs do what you say, without asking if it's really what you meant. They often don't ask for confirmation, they don't provide hand-holding or interactive help, and their options are short, often terse, sometimes confusing text-based strings. Note that they are generally very well documented, one just has to read the manual page for it (which is almost always man <command name>) and take the time to understand what the command they are going to run will do.

This mode of operation is powerful -- it means that seasoned CLI users can craft long command "pipelines" which do complex tasks with single commands. This is because the task won't ask "Are you sure?" every step of the way, it does what it's told. But for a user unfamiliar with this mode, and used to a GUI where online help is a click away, it's unfamiliar and scary.

But are there actually commands that will crash your computer?

Can you "crash" your computer using the CLI? Maybe. You can certainly cause data loss if you use a destructive command incorrectly. E.G. many of the answers here mention rm, a command which deletes files. Obviously, you can cause data loss with that command, it's what the command was designed to do.

As other answers have pointed out, you can use the command line to render your machine virtually unusable for a period of time: you can shut down without confirmation, cause a process to use 100% of your available resources without confirmation, kill all your programs or destroy your filesystem. If you really wanted to, you could use the CLI to craft a kernel extension which causes the kernel to panic (which is the closest to a "crash" I can think of).

The command line (accessed via the Terminal) is a powerful tool. Often it's faster to solve a problem using Terminal than the GUI. Some operations are only available using Terminal commands. However, the key to the CLI is understanding. Don't execute random commands you see online. Read the man pages and understand what commands do. If you're unsure, ask someone or learn more about a command before running it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .