42 Answers
42

When a single program stops working:

When a program window stops responding, you can usually stop it by clicking the X-shaped close button at the top left of the window. That will generally result in a dialog box saying that the program is not responding (but you already knew that) and presenting you with the option to kill the program or to continue to wait for it to respond.

Sometimes this does not work as expected. If you can't close a window by normal means, you can hit Alt+F2, type xkill, and press Enter. Your mouse cursor will then turn into an X. Hover over the offending window and left-click to kill it. Right clicking will cancel and return your mouse to normal.

If your program is running from a terminal, on the other hand, you can usually halt it with Ctrl+C. If not, find the name and process ID of its command, and end it with kill [process ID here]. If that fails despite waiting a few seconds, try sending a SIGHUP: kill -HUP [process ID here]. If all else fails, as a last resort send SIGKILL (-9): kill -9 [process ID here]. Note that you should only use SIGKILL as a last resort, because the process will be terminated immediately with no opportunity for cleanup.

When the mouse stops working:

If the keyboard still works, press Alt+F2 and run gnome-terminal (or, if these fail to launch, press Alt+Ctrl+F1 and login with your username and password). From there you can troubleshoot things. I'm not going to get into mouse troubleshooting here, as I haven't researched it. If you just want to try restarting the GUI, run sudo service lightdm restart. This should bring down the GUI, which will then attempt to respawn, bringing you back to the login screen.

When everything, keys and mouse and all, stop working:

First try the Magic SysReq method outlined in Phoenix' answer. If that doesn't work, press the Reset button on the computer case. If even that doesn't work, you'll just have to power-cycle the machine.May you never reach this point.

I've recently discovered that, rather than the "ps $options | grep $process_name" referenced above, one can just enter "pgrep $process_name" to achieve approximately the same result (for certain values of $options).
–
koanheadJun 4 '11 at 13:45

In the event you're forced to do this, do it slowly. Let a few seconds pass in between each keypress so that the commands you're invoking have a chance to finish before you go to the next one.
–
Andrew LambertApr 24 '11 at 8:22

17

In case you like mnemonics: Raising Elephants Is So Utterly Boring, or Reboot Event If System Utterly Broken. I've also seen it as RSEIUB (Raising Skinny Elephants is Utterly Boring).
–
Siegfried GevatterApr 26 '11 at 14:19

9

I actually came up with this one and try to remember it this way: "Reset System Environment In UBuntu". or "Reset Environment In System UBuntu".
–
Luis Alvarado♦Aug 14 '12 at 21:32

3

What do you do if you're using a Mac that has no SysRq key?
–
CerinJan 9 '13 at 23:22

but if X is locking up fully, or even the kernel is hung, you can't do much with a keyboard shortcut.
–
hexafractionJun 14 '12 at 21:58

8

Unfortunately, System Monitor is quite CPU intensive. It typically consumes up to 20% of my CPU, so if you're computer's bogged down, launching SM is only going to grind it into the dirt faster.
–
CerinJan 9 '13 at 23:25

2

If you can open System Monitor you can get to a terminal, in which case your OS is not frozen.
–
nbmNov 11 '13 at 23:32

1

System Monitor is, unfortunately, not the trusty Task Manager on Windows. As commented above, it will only launch if (ironically) Ubuntu isn't frozen. And even if it does, it's unresponsive anyway.
–
AsianSquirrelMar 25 '14 at 22:07

If you're getting a lot of freezes, there might be something wrong with your hardware. I used to get hard lockups every 48 hours due to some less than optimal RAM. Memtest86+ showed the fault after 40 minutes of testing. Swapped the RAM out for some more (under warranty) and I'm now at 32 days, 1 hour of uptime.

Ubuntu doesn't tend to leak its guts all over your memory like Windows can over time. Even if one application or a poor X video driver does, you can restart LigthtDM very simply and just keep going and going and going. I've actually been through three beta versions of the nvidia driver in this one boot :)

Anyway... While knowing how to restart softly is a very handy thing, finding, reporting and fixing the system should be your next priority. If it's an always-on system, you should easily be able to make it between kernel updates* without needing a restart.

*You should restart when you get kernel updates as they'll be security fixes that won't be applied until you reboot into the newer kernel.

Freezes such as you have described can be both software and hardware related and as you have found sometimes frustratingly difficult to diagnose.

Hardware

If this is a desktop PC look at your hardware-cards. For both laptops and desktops possibly acpi type issues.

It might be useful to temporarily simplify your configuration to have just the graphics card connected with a standard keyboard and mouse. All other cards should be removed.

For acpi related issues, try booting with noapic nomodeset in your grub boot option. Its also worth trying acpi=off although this could have other undesirable effects such as constant fan usage.

Also worth checking the bios version level and seeing if the vendor has a newer bios version. The readme notes should hopefully reveal if any newer version fixed crashes and freezes.

Software

I note you have tried the standard 270 drivers but have failed due to freezes. Can you clarify if you had similar issues with the open-source driver? Obviously you will not get Unity during testing this.

Graphics freezing can be one of/or a combination of the driver/compiz/X/kernel

If you are willing to try any of the suggestions below first backup your system with a good backup tool such as CloneZilla. You will need an external media device to receive the image such as a large USB stick/drive or separate internal hard-drive.

Installing newer nVidia driver

There are a small number of important fixes primarily in the 275 stable but a small number also in the 280beta that fixed freezes - it is worth a shot to see if these apply to your graphics card. Unfortunately nvidia dont go into detail on which cards they specifically fix (readme.txt)

However - I would strongly recommend a backup unless you feel confident on reversing a nvidia install - especially since you had serious issues with the slightly older 270 drivers. I've used clonezilla countless times and it has always got me out of trouble. You do need a large external drive though - USB stick/external drive or a separate drive.

X/Kernel/Compiz

If you run classic Ubuntu with effects do you get the same freeze issues as standard Ubuntu? If you cannot reproduce the freeze with classic Ubuntu (no effects) then this will point you towards a compiz issue. I would raise a launchpad bug report with the compiz team.

If space is available (e.g. 20Gb), you could dual boot/install alongside the latest oneiric alpha. Obviously this will itself be unstable, but it will come with the latest X and Kernel. You may need to also install manually the beta 280 graphics drivers above since it probably will not be offered in the Additional Drivers window.

If during testing you dont see the same freeze activity you could try uplifting your X version with the x-edgers ppa and using kernel kernel 3.0 in Natty. Going this route is not really desirable - and could cause you upgrade issues in the future - and may have other unforeseen stability issue. Again, use ppa-purge to remove the PPA.

Kernel 3.0 is packaged with the PPA - you'll need to install the headers as well as the kernel itself from synaptic BEFORE rebooting if you intend to install the nvidia drive later.

This is a testing ppa - do have a ready backup if you want to try this route.

If your video driver is using kernel modesetting (KMS), it's unlikely this will be sufficient to fix lockups, you have to use sysrq or power cycle. (Go ahead and try C-A-B, it obviously can't hurt; it does work when an app (like compiz/unity) is stuck, rather than X itself, however other answers on this page would be better in this case). But when it doesn't work, now you know why. :-)
–
BryceJun 16 '12 at 0:53

When everything stops working, first try Ctrl + Alt + F1 to go to a terminal, where you can likely kill X or other problem processes.

If even that doesn't work, try using holding down Alt + SysReq while pressing (slowly, with a few seconds between each) REISUB.

This puts the keyboard in raw mode, ends tasks in various states, syncs the disks, etc, and finally reboots the machine.
You will get much better results doing this than just pulling the plug. Of course, if this fails, you're pretty much left with pulling the plug.

Between Ctrl+Alt+F1 and trying to kill processes, and Alt+SysRq+REISUB, it's worth pressying Ctrl+Alt+Delete. If you successfully got to a text-based virtual console (from having pressed Ctrl+Alt+F1), this will virtually always reboot the machine.
–
Eliah KaganJun 14 '12 at 21:24

The first thing to look at is if it is just X that's frozen, or the whole system. Enable ssh and then ssh into the system. If you can't ssh into it, then it's probably a kernel lock up. If you can ssh in, then it might be just a gpu lockup.

Next try restarting X. Do this by restarting the display manager:

On Ubuntu 11.10 and later, LightDM is the display manager, so run:

service lightdm restart

On Ubuntu 11.04 and earlier, GDM is the display manager, so run:

service gdm restart

If that works, then it's perhaps an X bug. If it still doesn't work, then you may have a GPU lockup in the kernel drm driver. It would be useful to know at this point whether you're running the -ati (open source) driver, or -fglrx (closed source) driver.

If you have to do a hard shutdown I'd be wondering if the memory (RAM) was failing. On your next boot, try running memtest86. To do this:

while booting, hold down a shift key

the GRUB menu will appear

use the cursor keys to select the last option "memtest86"

press enter

You'll get a basic display and it will try reading and writing lots of values to all of your RAM. As long as there are no failures, you'll see a green status. If there is any failure it will turn red. In that case you'll need to replace at least one stick of your RAM.

Just press Ctrl+Alt+F1 on your keyboard to open TTY1. When it opens, run the Kill command. Example below.

first you use: ps
this will show you all processes running ("ps | less" if you want to see the results page by page)
Then you look for the PID of the process you want to terminate.
After this use: kill pid

Description: Most modern shells, Bash included, have a built-in kill
function. In Bash, both signal names and numbers are

accepted as options, and arguments may be job or process IDs. An exit
status can be reported using the -l option: zero when at least one
signal was successfully sent, non-zero if an error occurred. Using the
kill command from /usr/bin, your system might enable extra options,
such as the ability to kill processes from other than your own user ID
and specifying processes by name, like with pgrep and pkill. Both kill
commands send the TERM signal if none is given.

My ubuntu is super prone to freezing (probably 20 odd times a day).
I use the magic sysrq key too, but instead of using it to reboot or kill xserver,
I use the 'f' command which calls oom_kill, effectively dropping a process.
I've only ever seen this drop chrome tabs (as I tend to have quite a few heavyweight
ones open at a time). Anyway, this get's me out of this mess 95% of the time.

So when my ubuntu freezes (locks up, mouse stops responding etc), I hold alt + sysrq and then hit f (if you don't do this correctly it will take a screenshot instead). I usually have to repeat this combo a couple of times before ubuntu spurs back to life.

I'd have given up on ubuntu a long time ago if I hadn't discovered this, hope it helps someone!

if possible, try to open an ssh shell from another computer. this is an option If you knew in advance that the computer might hang soon, open the connection first before you perform that task.

I do this sometimes when I know vmware runs crazy and the GUI of ubuntu (the vmware host) becomes unresponsive. I can do a suspend from the ssh shell, it might take a while until it gets thru, and after a while the computer is idle again.

In the very specific case you are using Virtualbox to run a 64-bit guest on a 32-bit (Ubuntu) host using VT-x or AMD-V (hardware virtualization technology built-in your CPU) only

Virtualbox may make your 32-bit host randomly crash when you run a 64-bit guest on it using VT-x or AMD-V (hardware virtualization technology built-in your CPU). It is a known issue.

2 solutions:

You have to run 32-bit guests only on your current 32-bit host [recommended if you have less than 2 GB of RAM];

You have to switch to Ubuntu 64-bit as host (you can even perform a 32-bit to 64-bit "migration" by reinstalling Ubuntu 64-bit without touching to your "/home" folder) [recommended if you have 2 GB of RAM or more].

Please note that you can run 64-bit and 32-bit guests on a 64-bit host using Virtualbox without any problem.

You might get some extra information when you switch to the TTY view. Press Ctrl + Alt + F1 to get this, use Ctrl + Alt + F7 (or maybe F8) to get back to the GUI. You can have different sessions on most of the F-keys but that's different question altogether.