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

Question

¿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.

Answer 1

Solía ​​mantener CryoPID, que es un programa que hace exactamente lo que usted está 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, señales RT pendientes, numerosos problemas X11, la implementación de 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 volver a iniciarse directamente en ese estado, es mucho más fácil simplemente guardar esa información desde el propio programa, tal vez cuando da servicio a una señal .

Answer 2

Hay ctrl+z en Linux, pero no estoy seguro de que ofrece las características especificadas. Sospecho que hizo esta pregunta ya que no hace

Answer 3

La respuesta corta es "sí". Puede comenzar por buscar algunas ideas: ELF executable reconstruction from a core image (http://vx.netlux.org/lib/vsc03.html)

Answer 4

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.

Answer 5

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

Cuando toda su SO hiberna, los archivos locales y, obviamente, por ejemplo se pueden restaurar. 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 lo hizo la hibernación por programa (sin el apoyo de la aplicación), ¿cómo administrar 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 suspendiendo los hilos y dejar que se vuelva intercambiada con el disco tendría el mismo efecto?

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

Answer 6

Hubo algunas investigaciones sobre puesto de control/restauración para Linux de nuevo en 2,2 y 2,4 días, pero nunca llegó más allá 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.

Answer 7

La respuesta breve es "sí, pero no siempre de manera confiable". Salida CryoPID:

http://cryopid.berlios.de/

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

Se restauran los archivos abiertos y los desplazamientos. archivos temporales que han sido no enlazados y no son accesibles en el sistema de archivos siempre se guardan en la imagen de la . Otros archivos que no existen en la hoja de vida todavía no se restauran. Soporte para guardar contenido de archivos para tales situaciones están planificadas.

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

Answer 8

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

Answer 9

Como han señalado otros, es difícil para el sistema operativo proporcionar esta funcionalidad, ya que la aplicación necesita una comprobación de error integrada para manejar flujos interrumpidos.

Sin embargo, en una nota al margen, algunos lenguajes de programación y herramientas que utilizan máquinas virtuales admiten explícitamente esta funcionalidad, tales como el Self programming language.

Answer 10

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

kill -STOP <pid> 

que suspenderán 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 desee para activarlo de nuevo, utilizar

kill -CONT <pid> 

Las soluciones más complicadas, como CryoPID, son realmente sólo es necesario si desea que el proceso se detuvo para ser capaz de sobrevivir a una parada normal del sistema/reinicio - no parece que necesites eso.

Answer 11

Extendí Cryopid produciendo un paquete llamado Cryopid2 disponible de SourceForge. Esto puede migrar un proceso así como hibernarlo (junto con los archivos y sockets abiertos: 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 ha estado activo en este proyecto es que no soy un desarrollador del kernel - tanto esto (y/o el cryopid originales) que conseguir a alguien a bordo que puede hacerlo funcionar con los núcleos últimas (ej. Linux 3.x).

El método Cryopid funciona, y es probablemente la mejor solución para el proceso de propósito general Hibernación/migración en Linux. Me he encontrado.

Answer 12

Linux Kernel ha implementado parcialmente los futuros de punto de control/reinicio: https://ckpt.wiki.kernel.org/, el estado es here.

Algunas informaciones útiles se encuentran en el lwn (neto semanal Linux): http://lwn.net/Articles/375855/http://lwn.net/Articles/412749/ ......

Así que la respuesta es "sí"

Answer 13

me gustaría poner una actualización de estado aquí, desde 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.

La primera, la que yo sugiero porque tengo más suerte de ejecutarlo, es CRIU puesto de control que realiza/restaurar principalmente en el espacio de usuario, y requiere la opción del núcleo CONFIG_CHECKPOINT_RESTORE permitido trabajar.

Checkpoint/Restaurar En el espacio de usuario, o CRIU (pronunciado Kree-oo, IPA:/krɪʊ /, ruso: криу), 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 varias 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