I'm studying the Server Guide from Ubuntu and I can't resolve this trouble.

I follow these steps:

sudo -s
[sudo] password for ubuntu:
# echo c > /proc/sysrq-trigger
[ 31.659002] SysRq : Trigger a crash
[ 31.659749] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 31.662668] IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20
[ 31.662668] PGD 3bfb9067 PUD 368a7067 PMD 0
[ 31.662668] Oops: 0002 [#1] SMP
[ 31.662668] CPU 1

I did sudo sysctl -w kernel.sysrq=1 too

But the screen stays frozen and the system doesn't reboot. I can reboot the system manually but after reboot ls /var/crash returns nothing.

How can I fix this?

2 Answers 2


That's what it's supposed to do.

It could take a very long time for a server to dump ram, and depend on your host they may "catch" it and do something odd with it. My advise, "quit messin' with it".

The command triggers a kernel panic. Nothing more. All that extra stuff, is configurable and not really reliable. Your hosting provider may catch it (specially if it's something like Amazon EC2 where they build their own kernels and base images).

Your best bet to catch a production level kernel panic is with host monitoring of some kind. I use and recommend Nagios. When the server stops responding in a production environment, a reboot is NEVER EVER EVER the answer anyway. Testing and building a protocal around this type of kernel panic handling will just cause you to fail in a most spectacular fashion.

If you need syslogs or crash logs look at using the remote features of syslog.

In short, from hosting stuff 101, if you can't afford the down time, don't rely on cheap tricks like auto-reboot, setup a proper host monitoring solution, and a cluster.


I did the same command and that cause me a kernel panic. So decide to google it and find some interesting information.

We are causing a kernel test crash when we execute this command

echo c | sudo tee /proc/sysrq-trigger

According to the Ubuntu documentation

If everything works, there should be some delay (depending on the memory size). Then the system reboots again into the normal mode. Usually apport kicks in and asks about reporting the issue. Alternatively the report file can be found under /var/crash and either placed somewhere else or be unpacked again by calling:

#> apport-unpack <report file> <target directory>

It all depends on the memory size. I will search how much time it should take for a computer with 4GB of ram. In my case I reboot the system manually, but it was less than 2 minutes. Hope this helps.

You must log in to answer this question.

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