What is the most violent way that an application can terminate itself (linux)

Question

I'd like to emulate violent system shutdown, i.e. to get as close as possible to power outage on an application level. We are talking about c/c++ application on Linux. I need the application to terminate itself.

Currently i see several options:

1. call exit()
2. call _exit()
3. call abort()
4. do division by zero or dereference NULL.
5. other options?

What is the best choice?

Partly duplicate of this question

Answer 1

Why not do a halt? Or call panic?

Answer 2

kill -9

It kills a process and does not allow any signal handlers to run.

Answer 3

IMHO the closest to come to a power outrage is to run the application in a VM and to power of the VM without shutting down. In all other cases where the OS is still running when the application terminates the OS will do some cleanup that would not occur in a real power outage.

Answer 4

Try

raise(SIGKILL)

in the process, or from the command line:

kill -9 pid

where pid is the PID of your process (these two methods are equivalent and should not perform any cleanup)

Answer 5

At the application level, the most violent you can get is _exit(). Division by zero, segfaults, etc are all signals, which can be trapped - if untrapped, they're basically the same as _exit(), but may leave a coredump depending on the signal.

If you truly want a hard shutdown, the best bet is to cut power in the most violent way possible. Invoking /sbin/poweroff -fn is about as close as you can get, although it may do some cleanup at the hardware level on its way out.

If you really want to stress things, though, your best bet is to really, truly cut the power - install some sort of software controlled relay on the power cord, and have the software cut that. The uncontrolled loss of power will turn up all sorts of weird stuff. For example, data on disk can be corrupted due to RAM losing power before the DMA controller or hard disk. This is not something you can test by anything other than actually cutting power, in your production hardware configuration, over multiple trials.

Answer 6

You're unclear as to what your requirements are. If you're doing tests of how you will recover from a power failure, you need to actually cause a power failure. Even doing things like a kernel panic will allow write buffers on hard disks to flush, since they are independent of the CPU.

A remote power strip might be a solution if you really need to test the complete failure case.

Answer 7

I've had regression tests that we used to perform where we flicked the power switch to OFF. While doing disk IO.

Failure to recover later was, well: a failure.

You can buy reliability like that: generally you'll need an "end user certificate".

You can get there in software by talking (dirty) to your UPS. APC UPSes will definitely do power off under software control!

Who says systems can't power cycle themselves ?

Answer 8

You could try using a virtual machine. Freeze it, screw it hard, and see what happens.

Otherwise kill -9 would be the best solution.

Answer 9

If you need the application to terminate itself, the following seems appropriate:

kill(getpid(), SIGKILL); // same as kill -9

If that's not violent enough (and it may not be), then I like the idea of terminating a VM inside which your application is running. You should be able to rig up something where the application can send a command to the host machine (via ssh or something) to terminate its own VM.

Answer 10

Infinite recursion, should run out of stack space (if not, the OOM killer will finish the job):

void a() { a(); }

Fork bomb (if the app doesn't have any fork limits then the OOM killer should kill the app at some point):

  while(1)
    fork();

Run out of memory:

  while(1)
    malloc(1);

Answer 11

Within a single running process kill(getpid(), SIGKILL) is the most extreme, as no cleanup is possible.

Otherwise, try a VM, or put a test machine on a power strip and turn the power off, if you are doing automated testing.

Answer 12

As pointed out try to consume as much resources as possible until the kernel kills you.

while(1) malloc(1); fork();

Another way is trying to write to a read only page, just keep writing memory until you get a bus error.

If you can get to the kernel, a great way to kill it is simply writing over a data structure the kernel uses, bonus points if you find a page as only readable and marked as writable and then overwrite it. BTW most linux kernels allow writing to the syscall_table or interrupt table, if you write there your system will crash for sure.