Configuración
He sido programador desde hace bastante tiempo, pero todavía estoy un poco confuso en cosas internas y profundas.
Ahora. Soy muy consciente de que tampoco es una buena idea:
- matar -9 un proceso (malo)
- desconectar espontáneamente el enchufe de alimentación de una computadora o servidor en funcionamiento (peor)
Sin embargo, a veces simplemente es necesario hacerlo. A veces un proceso simplemente no responde sin importar lo que hagas y, a veces, una computadora simplemente no responde, sin importar lo que hagas.
Supongamos un sistema que ejecuta Apache 2, MySQL 5, PHP 5 y Python 2.6.5 a través de mod_wsgi.
Nota: Lo que más me interesa es Mac OS X aquí, pero una respuesta que pertenezca a cualquier sistema UNIX me ayudaría.
Mi preocupación
Cada vez que tengo que hacer cualquiera de estas cosas, especialmente la segunda, durante un tiempo me preocupa mucho que algo se haya roto. Algún archivo en alguna parte podría estar corrupto, ¿quién sabe qué archivo? Hay más de 1.000.000 de archivos en la computadora.
A menudo uso OS X, por lo que ejecutaré una operación "Verificar disco" a través de la Utilidad de Discos. No informará ningún problema, pero esto todavía me preocupa.
¿Qué pasa si algún archivo de configuración en algún lugar se estropea? O peor aún, ¿qué pasa si un archivo binario en algún lugar está dañado? O un archivo de script en alguna parte ahora está dañado. ¿Qué pasa si algún hardware está dañado?
¿Qué pasa si no me entero hasta el próximo mes, en un escenario crítico, cuando la corrupción o el daño provocan una catástrofe?
¿O qué pasa si ya se han perdido datos valiosos?
Mi esperanza
Mi esperanza es que estas inquietudes y preocupaciones sean infundadas. Después de todo, después de haber hecho esto muchas veces antes, todavía no ha sucedido nada realmente malo. Lo peor es que tuve que reparar algunas tablas MySQL, pero no parece haber perdido ningún dato.
Pero, si mis preocupaciones no son infundadas y podrían ocurrir daños reales en la situación 1 o 2, entonces mi esperanza es que haya una manera de detectarlo y prevenirlo.
Mis preguntas)
¿Podría deberse esto a que los sistemas operativos modernos están diseñados para garantizar que no se pierda nada en estos escenarios? ¿Podría deberse esto a que el software moderno está diseñado para garantizar que no se pierda nada? ¿Qué pasa con el diseño de hardware moderno? ¿Qué medidas se aplican al desconectar el enchufe?
Mi pregunta es, para ambos escenarios, ¿quéexactamente¿Puede salir mal y qué medidas se deben tomar para solucionarlo?
Tengo la impresión de que algo que puede salir mal es que es posible que algunos programas no hayan descargado 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é pasa 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 escondidos en algún lugar del enorme bosque de archivos de mis discos duros?
¿Qué pasa con los daños al hardware?
¿Qué me ayudaría más?
Descripciones detalladas sobre lo que sucede internamente cuando matas un proceso o desconectas la energía de todo el sistema. (Parece instantáneo, pero ¿alguien puede ralentizarlo?)
Explicaciones de todas las cosas que podrían salir mal en estos escenarios, junto con las probabilidades (aproximadamente, por supuesto) (es decir, esto es muy poco probable, pero es probable)...
Descripciones de las medidas implementadas en hardware, sistemas operativos y software modernos para evitar daños o corrupción cuando ocurren estos escenarios. (para consolarme)
Instrucciones sobre qué hacer después de un kill -9 o un corte de energía, más allá de "verificar el disco", para asegurarse realmente de que no haya nada corrupto o dañado en alguna parte del disco.
Medidas que se pueden tomar para fortalecer la configuración de una computadora de modo que, si es necesario apagar algo o cortar la energía, se mitigue cualquier daño potencial.
Alguna información sobre 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 de la muerte?
¡Muchas gracias!
Respuesta1
Tirar de la energía hace que todo se detenga en vuelo, sin previo aviso. kill -9 tiene el mismo efecto en un solo proceso, finalizándolo a la fuerza con unSIGKILL.
Si un proceso muere debido al kernel o a un corte de energía, no realiza ninguna limpieza. Eso significa que podría tener archivos a medio escribir, estados inconsistentes o cachés perdidos. 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 es posible que aún tenga 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 está entregando un mensaje, pero se corta en el medio, el remitente volverá a intentarlo más tarde hasta que tenga éxito.
Probablemente su sistema de archivos esté registrado. Si está moviendo o escribiendo un archivo y muere a mitad de camino, el sistema de archivos registrado seguirá haciendo referencia al original. El sistema de archivos registrado realizará cambios de forma no destructiva, dejando la copia anterior y luego solo hará referencia a la nueva copia como último paso antes de recuperar el espacio que ocupaban las copias antiguas en el disco.
Ahora bien, si tiene una matriz RAID, tiene todo tipo de buffers de memoria para aumentar el rendimiento y brindar confiabilidad en caso de un corte de energía. Lo más probable es que su sistema de archivos no conozca los 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 algún lugar del caché RAID. Entonces, ¿qué sucede cuando se acaba el poder? Esperemos que tenga una batería funcional en su gabinete RAID y la controle. De lo contrario, tendrá un sistema de archivos corrupto para fsck.
Sí, algunos bits pueden corromperse en un binario, pero no me preocuparía tanto en el hardware moderno. Si está realmente paranoico, puede monitorear el estado de sus discos y RAID con las herramientas adecuadas, pero debería hacerlo de todos modos. Realice copias de seguridad periódicas y obtenga una fuente de alimentación ininterrumpida.
Respuesta2
En un apagado inesperado, los únicos archivos que deberían dañarse son los archivos que están abiertos para escritura. En la mayoría de los sistemas, en un momento dado, probablemente 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 manejarla.
1 apagado
Depende del hardware. Los cabezales se estacionan automáticamente bajo el impulso del disco y todo lo que hay en su caché de escritura pierde la actualización de la DRAM y decae hasta convertirse en una corrupción irreparable en cuestión de segundos. Lo mismo ocurre con la memoria del sistema, el caché de la CPU, los registros, etc.
De wdc.com (google: sitio:wdc.com Protective Head Parking)
Se pierde energía: se restablece el disco duro. El cabezal se estaciona en la zona de aterrizaje utilizando la energía del husillo. El motor del husillo se detuvo.
2 - ¿Qué puede salir mal?
los archivos que se dejan abiertos no se escriben completamente. Si se abre un archivo para escribir, se dañarán los datos. La escritura de archivos en el hardware moderno es rápida y las PC modernas normalmente no sufren estrés con IO. Es como caminar con los ojos vendados por un tranquilo camino rural. La mayor parte del tiempo estarás bien.
3 - contramedidas
Consulte arriba para saber qué hacen los discos.
Busque 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 en el que no haya una copia consistente en el disco.
Windows guarda copias del registro (es demasiado importante) Wikipedia: "Windows 2000 mantiene una copia alternativa de las secciones del registro (.ALT) e intenta cambiar a ella cuando se detecta corrupción" (no he brindado soporte técnico intensivo desde 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é estuviste trabajando por última vez
- Arranque desde un disco separado y busque las fechas/horas de última modificación para determinar qué podría haber estado haciendo el sistema en el momento del fallo.
- Inicie desde un disco separado y compare las sumas md5 de todos sus archivos con una copia sin conexión.
Mantener copias de seguridad es la respuesta más adecuada; unas buenas copias de seguridad deberían permitirle volver a la versión modificada previamente.
5
¿Poder redundante? ¿Educación del usuario final? ¿poner cinta y cartón sobre el botón de encendido?
6
A excepción de fallas de funcionamiento del hardware, controladores de disco dañados, un kernel del sistema operativo roto, ausencia de sumas de verificación o fallas durante las actualizaciones, los archivos binarios y las bibliotecas no se abren en lectura y escritura para que no se corrompan. Sucede, pero es raro.
Respuesta3
En cuanto a matar -9, esto envía una señal al proceso para que "muera" justo en el acto. El proceso muere (a menos que esté en sueño ininterrumpido, en cuyo caso se convierte en zombie). No se cierra ningún archivo, no se escribe ningún dato y el programa no puede captar esta señal y hacer otra cosa. Sin limpieza, sin nada: simplemente muere.
Los sistemas de archivos actuales 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 siendo leídos; si se están leyendo (es decir, Apache HTTP se está iniciando, por ejemplo), es posible que una subida de tensión pueda dañar el binario, pero parece poco probable.
Tengo una Mac Mini y a la gente parece gustarle apagarla en frío (no importa cuántas veces se lo diga.....) y sigue funcionando.
En su mayor parte, siempre y cuando no dependas de 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 Solaris 10 (y así sucesivamente).
Respuesta4
Un "kill -9" no sincronizará una operación IO pendiente. Esto no suele ser un problema, pero si el sistema tiene una gran carga de E/S, es posible que se pierdan datos.
Es más un problema con los servidores, donde el controlador RAID (sin caché respaldado por batería) puede almacenar escrituras 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 es cuando los usuarios montan archivos PST de Outlook en un recurso compartido y pierden energía o conectividad de red.