linux linux-kernel checkpoint

¿Cómo "hibernar" un proceso en Linux almacenando su memoria en el disco y restaurándola más tarde?



linux-kernel checkpoint (13)

¿Es posible ''hibernar'' un proceso en Linux? Al igual que ''hibernate'' en la computadora portátil, me gustaría escribir toda la memoria utilizada por un proceso en el disco, liberar la memoria RAM. Y luego, más adelante, puedo "reanudar el proceso", es decir, leer todos los datos de la memoria y volver a ponerlos en la memoria RAM y puedo continuar con mi proceso.

Como han señalado otros, es difícil para el sistema operativo proporcionar esta funcionalidad, ya que la aplicación debe tener algún control de errores incorporado para manejar flujos interrumpidos.

Sin embargo, en una nota lateral, algunos lenguajes de programación y herramientas que usan máquinas virtuales son compatibles explícitamente con esta funcionalidad, como el lenguaje de programación Self .

Ctrl-Z aumenta las posibilidades de que las páginas del proceso se intercambien, pero no libera completamente los recursos del proceso. El problema de liberar por completo los recursos de un proceso es que, como los manejadores de archivos, los sockets son recursos de kernel que el proceso puede usar, pero no sabe cómo persistir por sí mismo. Entonces Ctrl-Z es tan bueno como se pone.

El problema es restaurar las secuencias (archivos y sockets) que el programa ha abierto.

Cuando todo tu sistema operativo hiberna, obviamente se pueden restaurar los archivos locales. Las conexiones de red no lo hacen, pero luego el código que accede a Internet suele ser más de comprobación de errores y tal y sobrevive a las condiciones de error (o debería).

Si hiciera hibernación por programa (sin soporte de aplicaciones), ¿cómo manejaría los archivos abiertos? ¿Qué pasa si otro proceso accede a esos archivos mientras tanto? etc?

Mantener el estado cuando el programa no está cargado va a ser difícil.

¿Simplemente suspender los hilos y dejar que se intercambie al disco tendría el mismo efecto?

O ejecute el programa en una máquina virtual y deje que la VM maneje la suspensión.

Este es el objetivo final del sistema operativo agrupado. Mathew Dillon pone mucho esfuerzo para implementar algo como esto en su proyecto Dragonfly BSD .

Extendí Cryopid produciendo un paquete llamado Cryopid2 disponible de SourceForge. Esto puede migrar un proceso así como también hibernarlo (junto con cualquier archivo y socket abierto: los datos en sockets / pipes se absorben en el proceso en hibernación y se vuelven a escupir en éstos cuando se reinicia el proceso).

La razón por la que no he estado activo con este proyecto es que no soy un desarrollador de kernel; tanto esto (y / o el cryopid original) necesitan tener a alguien a bordo que pueda hacer que funcionen con los kernels más recientes (por ejemplo, Linux 3.x) .

El método Cryopid funciona, y es probablemente la mejor solución para la hibernación / migración de procesos de propósito general en Linux que he encontrado.

Hay ctrl+z en Linux, pero no estoy seguro de que ofrezca las características que ha especificado. Sospecho que hiciste esta pregunta ya que no

Hubo algunas investigaciones sobre punto de control / restauración para Linux en 2.2 y 2.4 días, pero nunca pasaron del prototipo. Es posible (con las advertencias descritas en las otras respuestas) para ciertos valores de posible - Yo puedo escribir un módulo kernel para hacerlo, es posible. Pero por el valor común de posible (puedo hacerlo desde el shell en una distribución comercial de Linux), aún no es posible.

La respuesta breve es "sí, pero no siempre de manera confiable". Echa un vistazo a CryoPID:

CryoPID

Los archivos abiertos serán, de hecho, el problema más común. CryoPID establece explícitamente:

Los archivos abiertos y las compensaciones se restauran. Los archivos temporales que se han desvinculado y no están accesibles en el sistema de archivos siempre se guardan en la imagen. Otros archivos que no existen en la hoja de vida todavía no se restauran. Se planifica el soporte para guardar el contenido del archivo para tales situaciones.

Los mismos problemas también afectarán las conexiones TCP, aunque CryoPID admite tcpcp para la reanudación de la conexión.

Me gustaría poner una actualización de estado aquí, a partir de 2014.

La respuesta aceptada sugiere CryoPID como una herramienta para realizar Checkpoint / Restore, pero encontré que el proyecto no se ha conservado y es imposible de compilar con kernels recientes. Ahora, encontré dos proyectos mantenidos activamente que proporcionan la función de punto de control de la aplicación.

El primero, el que sugiero porque tengo más suerte al ejecutarlo, es CRIU que realiza el punto de control / restauración principalmente en el espacio de usuario, y requiere que la opción de kernel CONFIG_CHECKPOINT_RESTORE habilitada funcione.

Checkpoint / Restore In Userspace, o CRIU (pronunciado kree-oo, IPA: / krɪʊ /, Russian: криу), es una herramienta de software para el sistema operativo Linux. Con esta herramienta, puede congelar una aplicación en ejecución (o parte de ella) y marcarla en un disco duro como una colección de archivos. A continuación, puede usar los archivos para restaurar y ejecutar la aplicación desde el punto en que se detuvo. La característica distintiva del proyecto CRIU es que se implementa principalmente en el espacio del usuario.

El último es DMTCP ; citando desde su página principal:

DMTCP (Punto de control multipunto distribuido) es una herramienta para controlar de forma transparente el estado de múltiples aplicaciones simultáneas, incluidas las aplicaciones distribuidas y de subprocesos múltiples. Opera directamente en el ejecutable binario del usuario, sin ningún módulo de kernel de Linux u otras modificaciones del kernel.

También hay una buena página de Wikipedia sobre el argumento: Application_checkpointing

Solía ​​mantener CryoPID , que es un programa que hace exactamente lo que estás hablando. Escribe los contenidos del espacio de direcciones de un programa, VDSO, referencias de descriptores de archivos y estados en un archivo que luego puede reconstruirse. CryoPID comenzó cuando no había ganchos utilizables en el propio Linux y funcionaba completamente desde el espacio del usuario (de hecho, todavía funciona, dependiendo de la distribución / kernel / configuración de seguridad).

Los problemas eran (de hecho) sockets, pendientes de señales RT, numerosos problemas X11, la implementación glibc caching getpid () entre muchos otros. La aleatorización (especialmente VDSO) resultó ser insuperable para los pocos de nosotros que trabajamos en ella después de que Bernard se alejó de ella. Sin embargo, fue divertido y se convirtió en el tema de varias tesis de maestría.

Si solo está contemplando un programa que puede guardar su estado de ejecución y reiniciarlo directamente en ese estado, es mucho más fácil simplemente guardar esa información desde dentro del programa mismo, tal vez cuando da servicio a una señal.

Las respuestas que mencionan ctrl-z realmente están hablando de detener el proceso con una señal, en este caso SIGTSTP . Puedes emitir una señal de stop con kill :

kill -STOP <pid>

Eso suspenderá la ejecución del proceso. No liberará inmediatamente la memoria utilizada, pero como la memoria es necesaria para otros procesos, la memoria utilizada por el proceso detenido se intercambiará gradualmente.

Cuando quiera despertarlo nuevamente, use

kill -CONT <pid>

Las soluciones más complicadas, como CryoPID, solo son realmente necesarias si desea que el proceso detenido pueda sobrevivir a un apagado / reinicio del sistema; no parece que lo necesite.