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:
What is the best choice?
Partly duplicate of this question
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.
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.
kill -9
It kills a process and does not allow any signal handlers to run.
Why not do a halt? Or call panic?
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)
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.
You could try using a virtual machine. Freeze it, screw it hard, and see what happens.
Otherwise kill -9 would be the best solution.
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.
Any solution where the process terminates itself programatically does not emulate an asynchronous termination in any way. It is entirely deterministic in the sense that it will terminate at the same point in the code every time.
Of your suggestions
exit() is defined to "terminate normally, performing the regular cleanup for terminating processes." - hardly violent!
_exit() performs some subset of exit()'s operations, but remains 'nice' to the application, the OS, and its resources.
abort() creates a SIGABRT, and the OS may choose to perform clean-up of some resources.
It is probably best not to have the application terminate itself, but have some external process kill it asynchronously so that termination may occur at any point in the execution. Use kill from another process or script on a randomised timer, to send the SIGKILL signal which cannot be trapped, and performs no clean-up. If you must have the process terminate itself, do it from some asynchronous thread that wakes up after some non-deterministic time, and kills the process, but even then you will know which thread was running when it ternminated. Even using these methods, there is no way a process can be terminated mid-cpu-cycle as a real power down might, and any cached or buffered data pending output may still appear or be written after process termination.
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 ?
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);
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.
On a recent system, a process with superuser privileges could take realtime CPU/IO priority, lock all addressable memory, spew garbage across /proc, /dev, /sys, LAN/WiFi, firmware ioctls, and flash memory simultaneously, overclock/overvolt the CPU/GPU/RAM, and have a good chance of exiting by causing something nearby to Halt and Catch Fire.
If the process only needs to do metaphorical violence, it could stop at /proc/sysrq-trigger.
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.
