Can you actually use Terminal to crash your computer?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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).

Answer 5

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:

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.