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 de descripteur de fichier et les états dans un fichier qui peut ensuite être reconstruit. CryoPID a démarré alors qu'il n'y avait pas de crochets utilisables dans Linux lui-même et fonctionnait entièrement à partir de l'espace utilisateur (en fait, cela fonctionne toujours, en fonction de votre distribution/noyau/paramètres de sécurité).
Les problèmes étaient (en effet) les sockets, les signaux RT en attente, de nombreux problèmes X11, l'implémentation de la glibc caching getpid() parmi beaucoup d'autres. La randomisation (en particulier VDSO) s'est avéré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 mémoires de maîtrise.
Si vous envisagez simplement un programme qui peut enregistrer son état d'exécution et redémarrer directement dans cet état, il est de loin .. bien .. plus facile de simplement enregistrer ces informations à partir du programme lui-même, peut-être lors du traitement d'un signal.
J'aimerais mettre une mise à jour de statut ici, à partir de 2014.
La réponse acceptée suggère CryoPID comme outil pour effectuer un point de contrôle/restauration, mais j'ai trouvé que le projet n'était pas géré et impossible à compiler avec des 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 des points de contrôle/restauration principalement dans l'espace utilisateur et nécessite l'activation de l'option du noyau CONFIG_CHECKPOINT_RESTORE pour fonctionner.
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 implémenté dans l'espace utilisateur.
Ce dernier est DMTCP; citant leur page principale :
DMTCP (Distributed MultiThreaded Checkpointing) est un outil permettant de vérifier de manière transparente 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 ni aucune autre modification du noyau.
Il y a aussi une belle page Wikipedia sur l'argument :Application_checkpointing
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 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éactiver, utilisez
kill -CONT <pid>
Les solutions les 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.