Preparar

He sido programador durante bastante tiempo, pero todavía estoy un poco confuso en cosas internas profundas.

Ahora. Soy consciente de que tampoco es una buena idea:

1. matar -9 un proceso (malo)
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 a veces una computadora simplemente no responde, sin importar lo que haga.

Supongamos 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 pertenezca a cualquier sistema UNIX me ayudaría.

Mi preocupación

Cada vez que tengo que hacer uno de estos, especialmente el segundo, estoy muy preocupado por un período de tiempo de 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 ejecutaré una operación "Verificar disco" a través de la Utilidad de Discos. No informará ningún problema, pero todavía estoy preocupado por esto.

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

¿Qué sucede si no me entero hasta el próximo mes, 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 tuve que reparar algunas tablas de MySQL, pero parece que no he perdido ningún dato.

Pero, si mis preocupaciones no son infundadas, y podría ocurrir un daño real en las situaciones 1 o 2, entonces espero 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 esto porque el software moderno está diseñado para garantizar que nada se pierda? ¿Qué pasa con el diseño moderno de hardware? ¿Qué medidas existen cuando desconecta el enchufe de alimentación?

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

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

¿Qué pasa con la corrupción de archivos aleatorios escondidos en algún lugar en el 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 sucede internamente cuando se elimina -9 un proceso o se desconecta todo el sistema. (Parece instantáneo, pero ¿alguien puede desacelerarlo por mí?)

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

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

4. Instrucciones sobre qué hacer después de un kill -9 o un power pull, más allá de "verificar el disco", para asegurarse de que nada esté 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 algo se tiene que matar o se tiene que retirar la energía, se mitiga cualquier daño potencial.

6. Alguna información sobre archivos binarios: ¿no es cierto que el archivo binario apache o alguna biblioteca podría tener un byte aleatorio o dos corruptos en el medio, que no saldría y causaría un problema hasta más tarde? ¿Cómo puedo asegurarme de que esto no sucedió como resultado del tirón de poder o la muerte?

¡Muchas gracias!

Tirar del poder hace que todo se detenga en vuelo, sin advertencia. kill -9 tiene el mismo efecto en un solo proceso, terminando forzosamente con un SIGKILL .

Si un kernel o un corte de energía matan un proceso, no se realiza ninguna limpieza. Eso significa que podría tener archivos a medio escribir, estados inconsistentes o cachés perdidas. Por lo general, no tiene que preocuparse por nada de esto debido al registro en diario, el estado de salida y la batería de respaldo.

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 probablemente esté registrado. Si está moviendo o escribiendo un archivo y muere a mitad de la secuencia, el sistema de archivos registrado seguirá haciendo referencia al original. El sistema de archivos registrado hará cambios de manera no destructiva, dejando la copia anterior, luego solo hará referencia a la nueva copia como último paso antes de reclamar el espacio que ocuparon 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 caso de falla de energía. Lo más probable es que su sistema de archivos no conozca las cachés en el dispositivo y su estado, por lo que cree que se ha confirmado un cambio en el disco, pero todavía está en la caché RAID en alguna parte. Entonces, ¿qué sucede cuando el poder muere? Esperemos que tenga una batería funcional en su gabinete RAID y la monitoree. De lo contrario, tiene un sistema de archivos corrupto para fsck.

Sí, algunos bits pueden corromperse en un binario, pero no me preocuparía tanto por el hardware moderno. Si eres realmente paranoico, puedes controlar el estado de tus discos y RAID con las herramientas apropiadas, pero deberías hacerlo de todos modos. Realice copias de seguridad con regularidad y obtenga una fuente de alimentación ininterrumpida.

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, probablemente no esté escribiendo en un archivo. Probablemente.

1 asesinato -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 irremediables en cuestión de segundos. Lo mismo ocurre con la memoria del sistema, la memoria caché de la CPU, los registros, etc.

De wdc.com (google: sitio: wdc.com Protective Head Parking)

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

2 - que puede salir mal

los archivos que quedan abiertos están incompletamente escritos. Si se abre un archivo para escritura, habrá corrupción de datos. Las escrituras de archivos en hardware moderno son rápidas y las PC modernas no suelen estar estresadas 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 arriba para lo que hacen los discos.

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

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 guarda copias del registro (es demasiado importante) Wikipedia: "Windows 2000 guarda una copia alternativa de las colmenas del registro (.ALT) e intenta cambiar a él cuando se detecta corrupción" (no he hecho un gran soporte técnico 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-difícil)

• Mantener copias de seguridad
• Comprueba en qué estabas trabajando por última vez
• Arranque desde un disco separado y busque las últimas fechas / horas modificadas para averiguar qué pudo haber estado haciendo el sistema en el momento del bloqueo
• Arranque desde un disco separado y compare md5sums de todos sus archivos con una copia sin conexión.

Mantener copias de seguridad es la respuesta más adecuada, las buenas copias de seguridad deberían permitirle volver a la versión modificada previamente.

5 5

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

6 6

A falta de mal funcionamiento del hardware, controladores de disco dañados, un núcleo del sistema operativo dañado, la ausencia de sumas de verificación o bloqueos durante las actualizaciones, los archivos binarios y las bibliotecas no se abren de lectura-escritura para que no se corrompan. Sucede, pero es raro.

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 un sueño ininterrumpido, en cuyo caso se convierte en un zombie). No hay archivos cerrados, no hay datos escritos, y el programa no puede captar esta señal y hacer otra cosa. Sin limpieza, sin 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.

No es probable que los binarios como el propio Apache y otros se corrompan por una pérdida repentina de energía o por una interrupción del sistema, ya que están en la memoria o son leídos; Si se están leyendo (es decir, Apache HTTP se está iniciando, por ejemplo), es posible que un aumento de potencia pueda corromper el binario, pero parece poco probable.

Tengo una Mac Mini que a la gente parece gustarle que se apague (no importa cuántas veces les diga ...) y simplemente continúa.

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

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

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

Editar : Una cosa más ... si depende de unidades montadas en red y tiene identificadores de archivos 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.