Ero solito mantenere CryoPID, che è un programma che fa esattamente quello di cui parli. Scrive il contenuto dello spazio degli indirizzi di un programma, VDSO, riferimenti al descrittore di file e stati in un file che può essere successivamente ricostruito. CryoPID è iniziato quando non c'erano hook utilizzabili in Linux stesso e funzionava interamente dallo spazio utente (in realtà, funziona ancora, a seconda della tua distribuzione/kernel/impostazioni di sicurezza).
I problemi erano (in effetti) socket, segnali RT in sospeso, numerosi problemi con X11, l'implementazione di getpid() nella cache di glibc tra molti altri. La randomizzazione (in particolare VDSO) si è rivelata insormontabile per i pochi di noi che ci lavoravano dopo che Bernard se ne è andato. Tuttavia, è stato divertente ed è diventato l'argomento di diverse tesi di laurea.
Se stai solo contemplando un programma in grado di salvare il suo stato di esecuzione e riavviarsi direttamente in quello stato, è molto .. molto .. più facile salvare semplicemente quelle informazioni all'interno del programma stesso, forse durante la manutenzione di un segnale.
Vorrei inserire qui un aggiornamento di stato, a partire dal 2014.
La risposta accettata suggerisce CryoPID come strumento per eseguire Checkpoint/Restore, ma ho trovato il progetto non gestito e impossibile da compilare con i kernel recenti. Ora, ho trovato due progetti mantenuti attivamente che forniscono la funzionalità di checkpoint dell'applicazione.
Il primo, quello che suggerisco perché ho più fortuna a eseguirlo, è CRIU che esegue il checkpoint/restore principalmente nello spazio utente e richiede che l'opzione del kernel CONFIG_CHECKPOINT_RESTORE sia abilitata per funzionare.
Checkpoint/Restore In Userspace, o CRIU (pronunciato kree-oo, IPA:/krɪʊ/, russo:криу), è uno strumento software per il sistema operativo Linux. Usando questo strumento, puoi bloccare un'applicazione in esecuzione (o parte di essa) e farne il checkpoint su un disco rigido come una raccolta di file. È quindi possibile utilizzare i file per ripristinare ed eseguire l'applicazione dal punto in cui è stata bloccata. La caratteristica distintiva del progetto CRIU è che è principalmente implementato nello spazio utente.
Quest'ultimo è DMTCP; citando dalla loro pagina principale:
DMTCP (Distributed MultiThreaded Checkpointing) è uno strumento per controllare in modo trasparente lo stato di più applicazioni simultanee, comprese le applicazioni multi-thread e distribuite. Funziona direttamente sull'eseguibile binario dell'utente, senza alcun modulo del kernel Linux o altre modifiche del kernel.
C'è anche una bella pagina di Wikipedia sull'argomento:Application_checkpointing
Le risposte che menzionano ctrl-z stanno davvero parlando di fermare il processo con un segnale, in questo caso SIGTSTP . Puoi emettere un segnale di stop con kill :
kill -STOP <pid>
Ciò sospenderà l'esecuzione del processo. Non libererà immediatamente la memoria da esso utilizzata, ma poiché la memoria è necessaria per altri processi, la memoria utilizzata dal processo interrotto verrà gradualmente sostituita.
Quando vuoi riattivarlo di nuovo, usa
kill -CONT <pid>
Le soluzioni più complicate, come CryoPID, sono davvero necessarie solo se vuoi che il processo interrotto sia in grado di sopravvivere a un arresto/riavvio del sistema - non sembra che tu ne abbia bisogno.