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

25

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?

software-installation executable upgrade Francesco Turco
fuente
Tiendo a preferir evitar tales actualizaciones, no por la mecánica de actualización (esto se puede hacer bien), sino más bien por una preferencia por probar mis aplicaciones y configuración contra los cambios, primero. Entonces tendría un sistema separado ahora actualizado para simplemente cambiar. Pero aparte de eso, la actualización en el área de usuarios generalmente no es un problema, y ​​para pequeñas o soluciones de seguridad, simplemente lo haría.
Skaperen

Respuestas:

23

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

CodeGnome
fuente
Pero, ¿qué sucederá si necesita toda la memoria caché? En ese caso, las bibliotecas compartidas deberán volver a cargarse desde el disco ...
Nils
3
En realidad, la descripción del # 1 no era tan clara. El contenido del archivo de la biblioteca anterior permanece bajo un inodo separado (original), incluso si todos los nombres que lo vinculan desaparecen, siempre que algún proceso tenga el archivo abierto o sus contenidos asignados, los datos se mantienen distintos (y el sistema de archivos no puede se puede volver a montar hasta que se complete la desvinculación del archivo). El proceso que asignó el archivo original todavía tiene asignaciones de memoria a los contenidos originales.
Skaperen
@Nils No soy un experto, pero si te quedas sin memoria caché, ¿no se escribiría para intercambiar y releer desde allí? Si eso estaba lleno, entonces algún proceso probablemente se bloquearía antes de que pudiera quitarle la memoria a otro proceso que ya lo está usando.
Joe
@ Joe no, el intercambio también es ram. Skaperen describe lo que sucede: el identificador de archivo se mantiene intacto. Básicamente, el programa tiene un problema con la biblioteca antigua (desaparecida), que no se eliminará hasta que ese identificador vuelva a estar libre, todo esto en el nivel del sistema de archivos, no en el nivel de RAM.
Nils
4

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.

Patricio
fuente
El archivo todavía se puede volver a leer como "almacén de respaldo" si el mapeo del mismo no realizó cambios en la memoria (lo que de otro modo cambiaría el almacén de respaldo para intercambiar si está disponible), y la copia en memoria se descarta debido a otra presión de demanda para usar memoria. Pero esto no es un problema porque el archivo original todavía está abierto o asignado. La biblioteca de reemplazo es un archivo nuevo y diferente que el proceso anterior no ha abierto.
Skaperen
1
@Skaperen Supongo que estás hablando de archivos mapeados en memoria. Estos no son problemas al actualizar paquetes. Todos los administradores de paquetes crean nuevos archivos para reemplazar los antiguos en lugar de sobrescribirlos. De hecho, esta es la única forma de hacerlo, ya que un ejecutable en ejecución no se puede modificar, solo se puede desvincular.
Patrick
4

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.

BillThor
fuente
0

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á.
Nils
fuente
2
Parece que algunas partes de Tomcat se reiniciaron, o se usaron bibliotecas dinámicas por debajo del nivel de Java (por ejemplo, dlopen () y similares) que podrían terminar con una combinación de API en vivo.
Skaperen
@Skaperen incluso cuando usa bibliotecas compartidas: si se cierran después de usar cualquier programa debería tener problemas si la caché se está volviendo escasa ...
Nils
1
Un descriptor de archivo abierto tiene el mismo poder para retener los datos en el disco que un nombre para el archivo en un directorio. El inodo original no se eliminará mientras haya un enlace duro en el disco o un descriptor de archivo abierto. La caché no tiene nada que ver con eso. Ahora, algunos programas cierran sus descriptores de archivo cuando no los están usando y eso puede permitir que los datos se vayan.
dmckee
@dmckee Derecha. Nos estamos acercando al núcleo. Entonces, ¿qué es normal para un programa "normal": abrir la biblioteca y mantenerla abierta, o cargar la biblioteca y cerrarla después?
Nils