Pregunta ¿Qué * exactamente * se atornilla cuando mato -9 o desconecto la energía?


Preparar

He sido programador desde hace bastante tiempo, pero todavía estoy un poco confuso en temas internos y profundos.

Ahora. Soy muy consciente de que no es una buena idea:

  1. matar a -9 un proceso (mal)
  2. desconecte espontáneamente el enchufe de alimentación de una computadora o servidor en funcionamiento (peor)

Sin embargo, a veces simplemente tienes que hacerlo. A veces, un proceso simplemente no responde sin importar lo que haga, y otras veces una computadora simplemente no responde, no importa lo que haga.

Asumamos un sistema que ejecuta Apache 2, MySQL 5, PHP 5 y Python 2.6.5 a través de mod_wsgi.

Nota: aquí estoy más interesado en Mac OS X, pero una respuesta que corresponda a cualquier sistema UNIX me ayudaría.

Mi preocupación

Cada vez que tengo que hacer una de estas, especialmente la segunda, durante un período de tiempo me preocupa mucho que algo se haya roto. Algún archivo en algún lugar podría estar dañado, ¿quién sabe qué archivo? Hay más de 1,000,000 de archivos en la computadora.

A menudo uso OS X, así que ejecuto una operación de "Verificar Disco" a través de la Utilidad de Disco. No reportará problemas, pero todavía estoy preocupado por esto.

¿Qué pasa si algún archivo de configuración en algún lugar se arruinó. O incluso peor, ¿qué pasa si un archivo binario en algún lugar está dañado. O un archivo de script en alguna parte está corrupto ahora. ¿Qué pasa si algún hardware está dañado?

¿Qué pasa si no lo descubro hasta el mes próximo, en un escenario crítico, cuando la corrupción o el daño causan una catástrofe?

O, ¿qué pasa si ya se pierden datos valiosos?

Mi esperanza

Mi esperanza es que estas preocupaciones y preocupaciones sean infundadas. Después de todo, después de hacer esto muchas veces antes, nada realmente malo ha sucedido todavía. Lo peor es que he tenido que reparar algunas tablas MySQL, pero no parece haber perdido ningún dato.

Pero, si mis preocupaciones no son infundadas, y el daño real puede ocurrir en cualquiera de las situaciones 1 o 2, entonces mi esperanza es que haya una manera de detectarlo y prevenirlo.

Mis preguntas)

¿Podría ser esto porque los sistemas operativos modernos están diseñados para garantizar que no se pierda nada en estos escenarios? ¿Podría ser porque el software moderno está diseñado para garantizar que nada se pierda? ¿Qué pasa con el diseño de hardware moderno? ¿Qué medidas se aplican cuando desconecta el cable de alimentación?

Mi pregunta es, para ambos escenarios, que exactamente ¿Puede salir mal, y qué pasos se deben tomar para solucionarlo?

Tengo la impresión de que una cosa que puede salir mal es que algunos programas pueden no haber vaciado sus datos en el disco, por lo que cualquier dato muy reciente que se suponía que se escribiera en el disco (por ejemplo, unos segundos antes de la extracción de energía). ) podría estar perdido. Pero ¿qué hay más allá de eso? ¿Y este mismo problema de pérdida de datos de 5 segundos puede arruinar un sistema?

¿Qué pasa con la corrupción de archivos aleatorios que se esconden en algún lugar del enorme bosque de archivos en mis discos duros?

¿Qué pasa con el daño de hardware?

Lo que más me ayudaría

  1. Descripciones detalladas sobre lo que ocurre internamente cuando mata a -9 un proceso o desconecta todo el sistema. (Parece instantáneo, pero ¿puede alguien retrasarlo para mí?)

  2. Explicaciones de todas las cosas que podrían salir mal en estos escenarios, junto con las probabilidades (por supuesto) (es decir, esto es muy improbable, pero es probable) ...

  3. Descripciones de medidas implementadas en hardware, sistemas operativos y software modernos, para evitar daños o daños cuando ocurren estos escenarios. (para consolarme)

  4. Instrucciones sobre qué hacer después de un kill -9 o un tirón de alimentación, más allá de "verificar el disco", para asegurarnos de que realmente no haya nada dañado o dañado en algún lugar de la unidad.

  5. Medidas que se pueden tomar para fortalecer la configuración de una computadora, de modo que si hay que matar algo o quitar la energía, se mitigue cualquier daño potencial.

  6. Parte de la información sobre los archivos binarios: ¿no es cierto que el archivo binario de apache o alguna biblioteca podría tener uno o dos bytes aleatorios dañados en el medio, que no saldrían y causarían un problema hasta más tarde? ¿Cómo puedo asegurarme de que esto no sucedió como resultado del tirón de poder o la matanza?

¡Muchas gracias!


13
2018-06-01 20:24


origen


¿Qué procesos estás enviando kill -9? Mencionas 'Apache 2, MySQL 5, PHP 5 y Python 2.6.5 a través de mod_wsgi.' ¿Estás matando algunos de estos? Saber lo que estás matando permitirá una respuesta más directa de las implicaciones de hacerlo. Además, lo que realmente está ocurriendo para hacer que quieras matar los procesos. Sepa esto y puede identificar las causas fundamentales de su problema en lugar de que simplemente comprenda las implicaciones de su método de fuerza bruta para solucionarlo. Por cierto, en MacOS X, para las máquinas modernas mantener presionado el botón de encendido durante 10 segundos en lugar de solo tirar de la energía, es menos brutal. - Graham Dumpleton
No sé sobre kill -9, pero a menos que tenga algún tipo de fuente de alimentación de respaldo, creo que es bastante seguro decir que TODO muere cuando desconecta el cable de alimentación. - John Gardeniers


Respuestas:


Al desconectar la alimentación, todo se detiene en el vuelo, sin previo aviso. kill -9 tiene el mismo efecto en un solo proceso, terminándolo a la fuerza con un SIGKILL.

Si un proceso es destruido por el núcleo o un corte de energía, no realiza ninguna limpieza. Eso significa que podría tener archivos a medio escribir, estados incoherentes o cachés perdidos. Por lo general, no tiene que preocuparse por nada de esto debido al registro por diario, al estado de salida y al respaldo de la batería.

Los archivos temporales en / tmp desaparecerán automáticamente si están en tmpfs, pero aún puede tener archivos de bloqueo específicos de la aplicación para eliminar, como el bloqueo y .parentlock para firefox.

La mayoría del software es lo suficientemente inteligente como para volver a intentar una transacción si no registra un estado de salida exitoso. Un buen ejemplo de esto es un sistema de correo típico. Si se entrega un mensaje, pero se corta en el medio, el remitente volverá a intentarlo más tarde hasta que tenga éxito.

Su sistema de archivos es probablemente registrado. Si está moviendo o escribiendo un archivo y muere a mitad de la secuencia, el sistema de archivos registrado por diario seguirá haciendo referencia al original. El sistema de archivos registrado por diario realizará cambios de forma no destructiva, dejando la copia antigua, y luego solo hará referencia a la copia nueva como último paso antes de reclamar el espacio que ocupaban las copias antiguas en el disco.

Ahora, si tiene una matriz RAID, tiene todo tipo de memorias intermedias para aumentar el rendimiento y proporcionar confiabilidad en un fallo de alimentación. Lo más probable es que su sistema de archivos no sepa acerca de los cachés en el dispositivo y su estado, por lo que cree que se ha confirmado un cambio en el disco, pero aún está en el caché RAID en algún lugar. Entonces, ¿qué pasa cuando el poder muere? Esperemos que tenga una batería funcional en su gabinete RAID y la monitoree. De lo contrario tienes un sistema de archivos corruptos para fsck.

Sí, algunos bits pueden corromperse en un binario, pero no me preocuparía mucho por el hardware moderno. Si está realmente paranoico, puede controlar la salud de sus discos y RAID con las herramientas adecuadas, pero debería hacerlo de todos modos. Haga copias de seguridad periódicas y obtenga una fuente de alimentación ininterrumpida.


9
2018-06-01 21:50





En un cierre inesperado, los únicos archivos que deberían estar dañados son los archivos que están abiertos para escritura. En la mayoría de los sistemas, en cualquier momento dado, es probable que no esté escribiendo en un archivo. Probablemente.

1 muerte -9

es POSIX SIGKILL y depende de la implementación. El proceso que recibe esta señal no tendrá la oportunidad de manejarlo.

1 apagado

Depende del hardware. Las cabezas se estacionan automáticamente bajo el impulso de la unidad y Todo en su caché de escritura pierde la actualización de DRAM y se descompone en daños irreparables en cuestión de segundos. Lo mismo sucede con la memoria del sistema, la memoria caché de la CPU, los registros, etc.

Desde wdc.com (google: site: wdc.com Protective Head Parking)

El poder se pierde: El disco duro se reinicia. La cabeza está estacionada en la zona de aterrizaje utilizando la energía del huso. Motor del husillo parado.

2 - ¿Qué puede salir mal?

Los archivos que se dejan abiertos están incompletos. Si se abre un archivo para escribir, se dañarán los datos. Las grabaciones de archivos en hardware moderno son rápidas y las PC modernas normalmente no se subrayan con IO. Es como caminar con los ojos vendados sobre un camino rural tranquilo. La mayoría de las veces, estarás bien.

3 - contramedidas

ver más arriba para lo que hacen los discos.

Busque sistemas de archivos registrados por diario, son normales ahora: http://en.wikipedia.org/wiki/Journaling_file_system

El software como MS Word o vi escribirá en un archivo temporal en lugar del original. El objetivo es nunca dejar el sistema en un estado donde no haya una copia consistente en el disco.

Windows conserva copias del registro (es demasiado importante) Wikipedia: "Windows 2000 conserva una copia alternativa de las secciones del registro (.ALT) e intenta cambiar a él cuando se detecta corrupción" (no he hecho soporte técnico pesado desde entonces). Win2k, así que no estoy seguro de cuáles son los nuevos mecanismos de MS)

4 - que hacer

En orden de dificultad (fácil-duro)

  • Mantener copias de seguridad
  • Revisa en lo que estabas trabajando por última vez
  • Arranque desde un disco separado y busque las últimas fechas / horas modificadas para averiguar qué pudo haber hecho el sistema en el momento del bloqueo
  • Arranque desde un disco separado y compare las sumas md5 de todos sus archivos con una copia fuera de línea.

Mantener copias de seguridad es la respuesta más adecuada, las copias de seguridad correctas deben permitirle volver a la versión modificada anteriormente.

5

¿Poder redundante? ¿Educación del usuario final? ¿Poner cinta y cartón sobre el botón de encendido?

6

A falta de fallos de hardware, controladores de disco dañados, un kernel del sistema operativo dañado, ausencia de sumas de comprobación o fallos durante las actualizaciones, los binarios y las bibliotecas no se abren de lectura y escritura para que no se dañen. Sucede, pero es raro.


5
2018-06-01 22:20



+1 para el punto # 6 - Bigbio2002


En cuanto a un kill -9, esto envía una señal al proceso para "morir" en el acto. El proceso muere (a menos que esté en modo de suspensión ininterrumpida, en cuyo caso se convierte en un zombi). Ningún archivo está cerrado, no se escriben datos y el programa no puede detectar esta señal y hacer otra cosa. No hay limpieza, no hay nada: simplemente muere.

Los sistemas de archivos de hoy son muy robustos; cosas como XFS, JFS, ext3 y ext4 tienen diarios y otras cosas para mantener intactos los metadatos del sistema de archivos.

Los binarios como el propio Apache y otros no corren el riesgo de corromperse por una pérdida repentina de energía o por un ataque del sistema, ya que están en la memoria o se están leyendo; si se están leyendo desde (es decir, se está iniciando Apache HTTP, por ejemplo) es posible que una subida de tensión pueda dañar el binario, pero parece poco probable.

A la gente de Mac Mini parece que le gusta apagarse en frío (no importa cuántas veces les diga ...) y simplemente continúa.

En su mayor parte, siempre y cuando no dependas de kill -9 o apagar regularmente, no me preocuparía demasiado. Las cosas eran mucho peores en el pasado; Me preocuparía más sobre Solaris 2.6 (por ejemplo) que sobre Solaris 10 (y así sucesivamente).


4
2018-06-01 21:33



Referencias: matar -9, ¿Cuándo debo usar kill -9, Uso inútil de matar -9 - Dennis Williamson


Un "kill -9" no sincronizará una operación de IO pendiente. Esto a menudo no es un problema, pero si el sistema está bajo una gran carga de IO, puede perder datos.

Es más un problema con los servidores, donde la controladora RAID (sin caché respaldada por batería) puede almacenar en caché y perder sus datos.

Editar: Una cosa más ... si depende de unidades montadas en la red y tiene identificadores de archivo abiertos, es muy probable que deje el archivo inconsistente o dañado. En Windows, el ejemplo clásico de esto donde se ve esto es cuando los usuarios montan archivos PST de Outlook en un recurso compartido y pierden energía o conectividad de red.


3
2018-06-01 21:57