Comment «hiberner» un processus sous Linux en stockant sa mémoire sur disque et en la restaurant plus tard?
Est-il possible d'hiberner un processus sous Linux? Tout comme "hibernation" dans un ordinateur portable, je voudrais écrire toute la mémoire utilisée par un processus sur le disque, libérer de la RAM. Et puis plus tard, je peux `` reprendre le processus '', c'est-à-dire lire toutes les données de la mémoire et les remettre à RAM et je peux continuer mon processus?
J'avais l'habitude de maintenir CryoPID , qui est un programme qui fait exactement ce dont vous parlez. Il écrit le contenu de l'espace d'adressage d'un programme, VDSO, des références de descripteur de fichier et des états dans un fichier qui peut être reconstruit ultérieurement. CryoPID a commencé quand il n'y avait pas de hooks utilisables dans Linux lui-même et fonctionnait entièrement à partir de l'espace utilisateur (en fait, cela fonctionne toujours, selon vos paramètres de distribution/noyau/sécurité).
Les problèmes étaient (en effet) des sockets, des signaux en attente RT, de nombreux problèmes X11, l'implémentation de la mise en cache de la glibc getpid () parmi beaucoup d'autres. La randomisation (en particulier VDSO) s'est avérée insurmontable pour quelques-uns d'entre nous y travailler après que Bernard s'en soit éloigné, mais c'était amusant et est devenu le sujet de plusieurs mémoires de maîtrise.
Si vous envisagez simplement un programme qui peut enregistrer son état de fonctionnement et redémarrer directement dans cet état, il est beaucoup plus facile de sauvegarder ces informations depuis le programme lui-même, peut-être lors de l'entretien d'un signal.
Je voudrais mettre une mise à jour de statut ici, à partir de 2014.
La réponse acceptée suggère CryoPID comme un outil pour effectuer Checkpoint/Restore, mais j'ai trouvé que le projet n'était pas maintenu et impossible à compiler avec les noyaux récents. Maintenant, j'ai trouvé deux projets activement maintenus fournissant la fonctionnalité de point de contrôle d'application.
Le premier, celui que je suggère car j'ai plus de chance de l'exécuter, est CRIU qui effectue le point de contrôle/restauration principalement dans l'espace utilisateur et nécessite l'option du noyau CONFIG_CHECKPOINT_RESTORE permis de travailler.
Checkpoint/Restore In Userspace, ou CRIU (prononcé kree-oo, IPA:/krɪʊ /, russe: криу), est un outil logiciel pour le système d'exploitation Linux. À l'aide de cet outil, vous pouvez geler une application en cours d'exécution (ou une partie de celle-ci) et la contrôler sur un disque dur en tant que collection de fichiers. Vous pouvez ensuite utiliser les fichiers pour restaurer et exécuter l'application à partir du point où elle a été gelée. La particularité du projet CRIU est qu'il est principalement mis en œuvre dans l'espace utilisateur.
Ce dernier est DMTCP ; citant de leur page principale:
DMTCP (Distributed MultiThreaded Checkpointing) est un outil pour vérifier en toute transparence l'état de plusieurs applications simultanées, y compris les applications multithread et distribuées. Il fonctionne directement sur l'exécutable binaire de l'utilisateur, sans aucun module du noyau Linux ou autres modifications du noyau.
Il y a aussi une belle page Wikipedia sur l'argument: Application_checkpointing
Les réponses mentionnant ctrl-z parle vraiment d'arrêter le processus avec un signal, dans ce cas SIGTSTP. Vous pouvez émettre un signal d'arrêt avec kill:
kill -STOP <pid>
Cela suspendra l'exécution du processus. Il ne libérera pas immédiatement la mémoire qu'il utilise, mais comme la mémoire est requise pour d'autres processus, la mémoire utilisée par le processus arrêté sera progressivement remplacée.
Lorsque vous souhaitez le réveiller à nouveau, utilisez
kill -CONT <pid>
Les solutions plus compliquées, comme CryoPID, ne sont vraiment nécessaires que si vous voulez que le processus arrêté puisse survivre à un arrêt/redémarrage du système - cela ne semble pas comme si vous en aviez besoin.
Le problème est de restaurer les flux - fichiers et sockets - que le programme a ouverts.
Lorsque tout votre système d'exploitation hiberne, les fichiers locaux et autres peuvent évidemment être restaurés. Les connexions réseau ne le font pas, mais le code qui accède à Internet est généralement plus de vérification des erreurs et tel et survit aux conditions d'erreur (ou devrait).
Si vous avez mis en veille prolongée par programme (sans le support d'application), comment géreriez-vous les fichiers ouverts? Et si un autre processus accède à ces fichiers dans l'intervalle? etc?
Le maintien de l'état lorsque le programme n'est pas chargé va être difficile.
Suspendre simplement les threads et les laisser être échangés sur le disque aurait à peu près le même effet?
Ou exécutez le programme sur une machine virtuelle et laissez la VM gérer la suspension.
La réponse courte est "oui, mais pas toujours de manière fiable". Découvrez CryoPID:
Les fichiers ouverts seront en effet le problème le plus courant. CryoPID déclare explicitement:
Les fichiers ouverts et les décalages sont restaurés. Les fichiers temporaires qui ont été dissociés et qui ne sont pas accessibles sur le système de fichiers sont toujours enregistrés dans l'image. Les autres fichiers qui n'existent pas lors de la reprise ne sont pas encore restaurés. La prise en charge de l'enregistrement du contenu des fichiers pour de telles situations est prévue.
Les mêmes problèmes affecteront également les connexions TCP, bien que CryoPID prenne en charge tcpcp pour la reprise de la connexion.
Le noyau Linux a maintenant partiellement implémenté les futurs checkpoint/restart: https://ckpt.wiki.kernel.org/ , le statut est ici .
Quelques informations utiles sont dans le lwn (linux hebdomadaire net): http://lwn.net/Articles/375855/http://lwn.net/Articles/412749/ = ......
Donc, la réponse est oui"
J'ai étendu Cryopid en produisant un paquet appelé Cryopid2 disponible auprès de SourceForge. Cela peut migrer un processus ainsi que l'hiberner (avec tous les fichiers et sockets ouverts - les données dans les sockets/tuyaux sont aspirées dans le processus en hibernation et crachées dans ces derniers lorsque le processus est redémarré).
La raison pour laquelle je n'ai pas été actif avec ce projet est que je ne suis pas un développeur de noyau - à la fois cela (et/ou le cryopide d'origine) doit avoir quelqu'un à bord qui peut les faire fonctionner avec les derniers noyaux (par exemple Linux 3.x) .
La méthode Cryopid fonctionne - et est probablement la meilleure solution à l'hibernation/migration de processus à usage général sous Linux que j'ai rencontrée.
La reponse courte est oui." Vous pouvez commencer par regarder ceci pour quelques idées: reconstruction exécutable ELF à partir d'une image de base ( http://vx.netlux.org/lib/vsc03.html )
Comme d'autres l'ont noté, il est difficile pour le système d'exploitation de fournir cette fonctionnalité, car l'application doit avoir une fonction de vérification des erreurs intégrée pour gérer les flux interrompus.
Cependant, en passant, certains langages de programmation et outils qui utilisent des machines virtuelles prennent explicitement en charge cette fonctionnalité, comme le langage de programmation automatique .
Il y a eu quelques recherches sur le point de contrôle/restauration pour Linux en 2,2 et 2,4 jours, mais il n'a jamais dépassé le prototype. Il est possible (avec les mises en garde décrites dans les autres réponses) pour certaines valeurs de possible - si vous pouvez écrire un module noyau pour le faire, c'est possible. Mais pour la valeur commune de possible (puis-je le faire à partir du Shell sur une distribution Linux commerciale), ce n'est pas encore possible.
C'est en quelque sorte l'objectif ultime du système d'exploitation en cluster. Mathew Dillon met beaucoup d'efforts pour implémenter quelque chose comme ça dans son projet Dragonfly BSD .