¿Cuál es la forma más violenta en que una aplicación puede darse por terminada? (Linux)

Question

Me gustaría emular el apagado violento del sistema, es decir, acercarme lo más posible al corte de energía en un nivel de aplicación. Estamos hablando de la aplicación c/C++ en Linux. Necesito que la aplicación se resuelva solo.

Actualmente Veo varias opciones:

1. llamada exit()
2. llamada _exit()
3. llamada abort()
4. hacer la división por cero o NULL eliminar la referencia.
5. otras opciones?

¿Cuál es la mejor opción?

Parcialmente duplicado de this question

Answer 1

En el nivel de aplicación, el más violento que puede obtener es _exit(). La división por cero, segfaults, etc. son todas las señales, que pueden quedar atrapadas; si no están atrapadas, son básicamente las mismas que _exit(), pero pueden dejar un núcleo en función de la señal.

Si realmente quieres un apagado completo, la mejor opción es reducir la potencia de la manera más violenta posible. Invocar/sbin/poweroff -fn es lo más cercano que puede obtener, aunque puede hacer una limpieza en el nivel de hardware en el camino de salida.

Si realmente quiere enfatizar las cosas, su mejor opción es realmente cortar la energía de verdad, instalar algún tipo de relé controlado por software en el cable de alimentación y hacer que el software corte eso. La pérdida incontrolada de poder presentará todo tipo de cosas extrañas. Por ejemplo, los datos en el disco pueden estar dañados debido a RAM losing power before the DMA controller or hard disk. Esto no es algo que pueda probar con otra cosa que no sea cortar la potencia, en la configuración de hardware de producción, en varias pruebas.

Answer 2

Por qué no hacer un alto? ¿O llamas al pánico?

Answer 3

kill -9 

Mata un proceso y no permite el funcionamiento de controladores de señal.

Answer 4

En mi humilde opinión, lo más cercano a una indignación de poder es ejecutar la aplicación en una máquina virtual y a la potencia de la máquina virtual sin apagar. En todos los demás casos en los que el sistema operativo todavía se está ejecutando cuando la aplicación finaliza, el sistema operativo hará una cierta limpieza de que no ocurriría en un corte de energía real.

Answer 5

Trate

raise(SIGKILL) 

en el proceso, o desde la línea de comandos:

kill -9 pid 

donde PID es el PID de su proceso (estos dos métodos son equivalentes y no deben realizar la limpieza)

Answer 6

No está claro cuáles son sus requisitos. Si está haciendo pruebas de cómo se recuperará de un corte de energía, realmente debe causar un corte de energía. Incluso hacer cosas como un kernel panic permitirá que los búferes de escritura en los discos duros se vayan al ras, ya que son independientes de la CPU.

Una toma de corriente remota podría ser una solución si realmente necesita probar la falla completa.

Answer 7

He tenido pruebas de regresión que solíamos realizar cuando pulsábamos el interruptor de encendido en OFF. Mientras se hace el disco IO.

La falla en la recuperación posterior fue, bueno: una falla.

Puede comprar una fiabilidad como esa: generalmente necesitará un "certificado de usuario final".

Puede acceder al software hablando (sucio) a su UPS. UPS de APC definitivamente se apagarán con el control de software.

¿Quién dice que los sistemas no pueden encenderse por sí mismos?

Answer 8

Puede probar con una máquina virtual. Congelarlo, atornillarlo con fuerza y ​​ver qué pasa.

De lo contrario kill -9 sería la mejor solución.

Answer 9

Si necesita la aplicación termine en sí, la siguiente parece apropiada:

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

Si eso no es lo suficientemente violenta (y puede que no sea), entonces me gusta la idea de poner fin a una máquina virtual dentro de la cual su aplicación se está ejecutando. Debería poder instalar algo donde la aplicación pueda enviar un comando al equipo host (a través de ssh o algo similar) para terminar su propia máquina virtual.

Answer 10

recursividad infinita, debe quedarse sin espacio de pila (si no, el asesino OOM terminará el trabajo):

void a() { a(); } 

Tenedor bomba (si la aplicación no tiene ningún límite de horquilla y luego el asesino OOM debe matar a la aplicación en algún momento):

while(1) 
    fork(); 

quedado sin memoria:

while(1) 
    malloc(1); 

Answer 11

Dentro de una sola corriendo g proceso kill (getpid(), SIGKILL) es el más extremo, ya que no es posible la limpieza.

De lo contrario, pruebe una VM, o coloque una máquina de prueba en una regleta de enchufes y apáguela, si está realizando pruebas automáticas.

Answer 12

Como se señaló, tratar de consumir tantos recursos como sea posible hasta que el kernel que mata:

while(1) 
    { 
    malloc(1); 
    fork(); 
    } 

Otra manera está tratando de escribir en una única página leída, sólo seguir escribiendo de memoria hasta que llegue un autobús error.

Si puede acceder al kernel, una excelente forma de eliminarlo es simplemente escribir sobre una estructura de datos que utiliza el kernel, puntos de bonificación si encuentra que una página es solo legible y marcada como escribible y luego sobrescribirla. Por cierto, la mayoría de los kernels de Linux permiten escribir en syscall_table o en la tabla de interrupciones, si escribe allí, su sistema se bloqueará con seguridad.

Answer 13

Cualquier solución en la que el proceso se resuelva programáticamente no emula una terminación asincrónica de ninguna manera. Es completamente determinista en el sentido de que terminará en el mismo punto en el código cada vez.

de sus sugerencias

• exit() se define a "terminar normalmente, realizar la limpieza periódica de los procesos de terminación." - casi no violenta !

• _exit() realiza un subconjunto de las operaciones de exit(), pero sigue siendo "agradable" para la aplicación, el sistema operativo y sus recursos.

• abort() crea un SIGABRT y el sistema operativo puede optar por realizar la limpieza de algunos recursos.

• /0 probablemente tiene un comportamiento similar a abortar()

Probablemente es mejor no tener la aplicación termina en sí, pero tienen algún proceso externo acabar con él de forma asíncrona por lo que la terminación se puede producir en cualquier punto de la ejecución. Use kill desde otro proceso o secuencia de comandos en un temporizador aleatorio, para enviar la señal SIGKILL que no puede ser capturada y no realiza ninguna limpieza. Si debe hacer que el proceso se termine, hágalo a partir de un subproceso asíncrono que se despierte después de un tiempo no determinista, y mate el proceso, pero incluso así sabrá qué subproceso se estaba ejecutando cuando termino. Incluso utilizando estos métodos, no hay forma de que un proceso se pueda finalizar mid-cpu-cycle como un verdadero poder de apagado, y cualquier salida almacenada en memoria caché o almacenada aún puede aparecer o escribirse después de la finalización del proceso.

Answer 14

En un sistema reciente, un proceso con privilegios de superusuario podría tomar la CPU en tiempo real/prioridad IO, bloquear toda la memoria direccionable, arrojan basura a través de /proc, /dev, /sys, LAN/Wi-Fi, ioctls firmware y de memoria flash de forma simultánea, overclock/sobrevoltaje de la CPU/GPU/RAM, y tiene una buena posibilidad de salir causando algo cercano a Halt and Catch Fire.

Si el proceso solo necesita hacer violencia metafórica, podría detenerse en /proc/sysrq-trigger.