linux-kernel - Comment "hiberner" un processus sous Linux en stockant sa mémoire sur le disque et en le restaurant plus tard?




checkpoint (12)

Linux Kernel a maintenant implémenté partiellement le checkpoint / restart futures: https://ckpt.wiki.kernel.org/ , le statut est here .

Certaines informations utiles sont dans le lwn (linux net hebdomadaire): http://lwn.net/Articles/375855/ http://lwn.net/Articles/412749/ ......

Donc, la réponse est oui"

Est-il possible d'hiberner un processus sous linux? Tout comme "hiberner" 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 dans la RAM et continuer mon processus?


Le problème consiste à restaurer les flux (fichiers et sockets) que le programme a ouverts.

Lorsque l'ensemble de 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 d'erreurs et ainsi de suite et survit aux conditions d'erreur (ou devrait).

Si vous faisiez un hibernation par programme (sans support d'application), comment géreriez-vous les fichiers ouverts? Que se passe-t-il si un autre processus accède à ces fichiers entre-temps? etc?

Maintenir l'état lorsque le programme n'est pas chargé va être difficile.

Le simple fait de suspendre les threads et de les laisser passer sur le disque aurait plus ou moins le même effet?

Ou exécutez le programme dans une machine virtuelle et laissez la VM gérer la suspension.


Ctrl-Z augmente les chances d'échange des pages du processus, mais ne libère pas complètement les ressources du processus. Le problème avec la libération complète des ressources d'un processus est que des choses comme les handles de fichiers, les sockets sont des ressources du noyau que le processus peut utiliser, mais ne savent pas comment persister tout seul. Donc, Ctrl-Z est aussi bon que possible.


J'ai étendu Cryopid en produisant un paquet appelé Cryopid2 disponible auprès de SourceForge. Cela peut migrer un processus et l'hiberner (avec tous les fichiers et sockets ouverts - les données des sockets / pipes sont aspirées dans le processus en hibernation et recrachées dans celles-ci 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 - les deux (et / ou le cryopid original) ont besoin de quelqu'un qui puisse les faire fonctionner avec les derniers noyaux (par exemple Linux 3.x) .

La méthode Cryopid fonctionne - et c'est probablement la meilleure solution pour l'hibernation / migration des processus généraux dans Linux que j'ai rencontré.


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, les références des descripteurs de fichiers et les états dans un fichier qui peut être reconstruit ultérieurement. CryoPID a démarré lorsqu'il n'y avait pas de hooks utilisables sous Linux et fonctionnait entièrement à partir de l'espace utilisateur (en fait, il fonctionne toujours, en fonction de vos paramètres distro / kernel / security).

Les problèmes étaient (en effet) des sockets, des signaux RT en attente, de nombreux problèmes X11, l'implémentation de la mise en cache de glibc getpid () parmi beaucoup d'autres. La randomisation (surtout VDSO) s'est révélée insurmontable pour les quelques-uns d'entre nous qui y travaillaient après que Bernard s'en soit éloigné. Cependant, c'était amusant et est devenu le sujet de plusieurs thèses 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 simplement enregistrer cette information à partir du programme lui-même, peut-être lors de l'entretien d'un signal.


Il y a eu quelques recherches sur checkpoint / restore pour Linux en 2.2 et 2.4 jours, mais ça 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 - je peux écrire un module noyau pour le faire, c'est possible. Mais pour la valeur commune de possible (je peux le faire depuis le shell sur une distribution Linux commerciale), ce n'est pas encore possible.



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é le projet inopérant 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 parce que 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 que l'option du noyau CONFIG_CHECKPOINT_RESTORE permette de fonctionner.

Checkpoint / Restore Dans 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 figer une application en cours d'exécution (ou une partie de celle-ci) et la placer 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 implémenté dans l'espace utilisateur.

Ce dernier est DMTCP ; citant de leur page principale:

DMTCP (Distributed MultiThread Checkpointing) est un outil permettant de vérifier de manière transparente l'état de plusieurs applications simultanées, y compris des applications multi-threadées et distribuées. Il fonctionne directement sur l'exécutable binaire de l'utilisateur, sans aucun module de noyau Linux ni aucune autre modification du noyau.

Il y a aussi une belle page Wikipedia sur l'argument: Application_checkpointing


Il y a ctrl+z dans linux, mais je ne suis pas sûr qu'il offre les fonctionnalités que vous avez spécifiées. Je suppose que vous avez posé cette question, car elle ne le fait pas


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 intégrée de vérification des erreurs pour gérer les flux brisés.

Cependant, d'un autre côté, certains langages de programmation et outils utilisant des machines virtuelles prennent explicitement en charge cette fonctionnalité, comme le langage de programmation automatique .


Les réponses mentionnant ctrl-z parlent 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 va suspendre l'exécution du processus. Il ne libérera pas immédiatement la mémoire utilisée par lui, mais comme la mémoire est requise pour d'autres processus, la mémoire utilisée par le processus arrêté sera progressivement permise.

Lorsque vous voulez le réveiller, 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 - il ne semble pas que vous en ayez besoin.


Vous devriez utiliser file = open('myfile.dat', 'w+')





linux linux-kernel checkpoint