¿Por qué actualizar un sistema Linux en ejecución no es problemático?

Hace años que uso sistemas Linux a diario, y nunca tuve problemas importantes al actualizar un sistema cuando estaba en funcionamiento, pero todavía me pregunto por qué esto es posible.

Déjame hacer un ejemplo.

Supongamos que un programa "A" de un determinado paquete se ejecuta en un sistema. Este programa, en cierto punto, necesita abrir otro archivo ("B") del mismo paquete. Después de eso, el programa "A" cierra "B" porque ya no lo necesita. Supongamos que ahora actualizo el paquete al que pertenecen "A" y "B". "A" no se ve directamente afectado por estas operaciones, al menos por el momento, ya que se está ejecutando en RAM y la actualización acaba de reemplazar "A" en el disco duro. Supongamos que "B" también ha sido reemplazado en el sistema de archivos. Ahora "A" necesita leer "B" nuevamente por alguna razón. La pregunta es: ¿es posible que "A" pueda encontrar una versión incompatible de "B" y bloquearse o funcionar mal de alguna otra manera?

¿Por qué nadie actualiza sus sistemas reiniciando con un CD en vivo o algún procedimiento similar?

La actualización de Userland es rara vez un problema

A menudo puede actualizar paquetes en un sistema en vivo porque:

1. Las bibliotecas compartidas se almacenan en la memoria, no se leen del disco en cada llamada, por lo que las versiones antiguas permanecerán en uso hasta que se reinicie la aplicación.
2. Los archivos abiertos en realidad se leen desde descriptores de archivo , no desde los nombres de archivo, por lo que el contenido del archivo permanece disponible para las aplicaciones en ejecución incluso cuando se mueven / renombran / eliminan hasta que los sectores se sobrescriben o se cierran los descriptores de archivos.
3. Los paquetes que requieren recargar o reiniciar generalmente son manejados adecuadamente por el administrador de paquetes si el paquete ha sido bien diseñado. Por ejemplo, Debian reiniciará ciertos servicios cada vez que libc6 se actualice.

Generalmente, a menos que esté actualizando su núcleo y no esté usando ksplice, entonces los programas o servicios pueden necesitar reiniciarse para aprovechar una actualización. Sin embargo, rara vez es necesario reiniciar un sistema para actualizar algo en el país de usuario, aunque en los escritorios ocasionalmente es más fácil que reiniciar servicios individuales.

Ver también

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode

Sí, lo que describió es posible, pero la mayoría de las veces si el archivo se incluye con el paquete, será una biblioteca u otro archivo que se leerá una vez y solo una vez (ya que no cambia, no hay razón para hacerlo). léelo varias veces). Además, si el archivo se necesita a largo plazo, es probable que la aplicación deje abierto el identificador de archivo, en el que incluso si se reemplaza en el sistema de archivos real, el identificador de archivo abierto mantendrá abierta la versión anterior.

En la mayoría de los casos, los datos que se leen varias veces durante la vida del proceso son datos de usuario / variables, y esto no cambiaría durante una actualización del paquete. Además, dado que los datos son variables, cualquier programador en su sano juicio se aseguraría de que el programa pueda manejarlo cambiando de una lectura a la siguiente.

Supongamos que "B" también ha sido reemplazado en el sistema de archivos. Ahora "A" necesita leer "B" nuevamente por alguna razón. La pregunta es: ¿es posible que "A" pueda encontrar una versión incompatible de "B" y bloquearse o funcionar mal de alguna otra manera?

Esto es posible, pero poco probable en la mayoría de los casos. Si "B" es una biblioteca de códigos, la versión original generalmente no se cerraría. "A" continuaría usando la versión original de "B". Si ejecuta "A" después de la actualización, se utilizará la nueva versión de "B". Durante la actualización, existe el riesgo de que se puedan cargar versiones incompatibles. Sin embargo, debido a la forma en que se cargan las bibliotecas de códigos, esto solo debería ser un problema si "A" necesita funcionalidad que no está presente en las versiones de "B" que cargó.

Las buenas prácticas de codificación mantienen la interfaz para las funciones igual. Como resultado, no importa mucho qué versión se cargue, aparte de si hubo errores corregidos en la versión más nueva.

Los archivos de configuración son un asunto ligeramente diferente, pero generalmente se leen durante el inicio. En este caso, "A" no leería "B" a menos que se cambiara una recarga de la configuración. Nuevamente, sería una mala práctica de codificación cambiar el formato o el significado del archivo de configuración. Una versión incompatible del archivo de configuración debe tener un nombre diferente, por lo que no causaría ningún problema.

¿Por qué nadie actualiza sus sistemas reiniciando con un CD en vivo o algún procedimiento similar?

Cerrar y reiniciar desde una versión diferente conduciría a una interrupción del servicio. Para los servidores, esto generalmente no se desea. En cualquier caso, el administrador de paquetes en el sistema en ejecución conoce el software y las versiones que ha instalado. Los CD en vivo tienen su propia lista de software instalado, posiblemente con diferentes versiones. Esto dificulta la actualización confiable del sistema en ejecución desde el CD en vivo.

Los CD en vivo a veces se usan cuando se instala una nueva versión de O / S. En este caso, generalmente se realiza una instalación limpia de O / S. Esto puede limitar la cantidad de archivos no utilizados de la versión anterior que se retiene. Puede ser más esfuerzo que actualizar el sistema en vivo. Sin embargo, si se utilizan diferentes particiones raíz, puede limitar el riesgo de quedar atascado con un sistema parcialmente arrancable que no se puede arrancar.

Hay algunos casos en los que esto ES un problema:

• Actualización de JDK mientras se está ejecutando un Java-VM: me hice la misma pregunta que tenía: tenía un Tomcat en ejecución que usa Java. Ahora, después de una actualización de parche del JDK, todavía funcionaba sin problemas, por lo que parecía.

Ahora la explicación es la memoria caché. OK, comencé un programa de memoria para usar toda la RAM disponible, y luego Tomcat se bloqueó (después de acceder a la aplicación que se ejecuta allí).

• Kernel-Upgrade en sistemas SuSE: en SuSE, el kernel antiguo y sus módulos se eliminan justo después de la actualización del kernel. Si luego desea usar algo nuevo, que requiere un módulo de núcleo, que no se cargó hasta ahora, el servicio fallará.