E 'possibile "ibernare" un processo in linux? Proprio come "ibernare" nel laptop, vorrei scrivere tutta la memoria utilizzata da un processo su disco, liberare la RAM. E poi più avanti, posso 'riprendere il processo', cioè, leggere tutti i dati dalla memoria e rimetterli nella RAM e posso continuare con il mio processo?Come "ibernare" un processo in Linux memorizzando la sua memoria su disco e ripristinandola in seguito?
Ho utilizzato per mantenere CryoPID, che è un programma che fa esattamente quello che stai parlando. Scrive il contenuto dello spazio degli indirizzi di un programma, VDSO, i riferimenti dei descrittori di file e gli stati in un file che può essere successivamente ricostruito. CryoPID è iniziato quando non c'erano ganci utilizzabili in Linux e funzionava interamente da userspace (in realtà, funziona ancora, a seconda delle impostazioni di distro/kernel/sicurezza).
I problemi erano (effettivamente) socket, segnali RT in attesa, numerosi problemi X11, implementazione di glibc caching getpid() tra molti altri. La randomizzazione (specialmente VDSO) si è rivelata insormontabile per pochi di noi che ci lavoravano dopo che Bernard si era allontanato da esso. Tuttavia, è stato divertente ed è diventato l'argomento di diverse tesi di master.
Se stai solo pensando a un programma che può salvare il suo stato di esecuzione e ricominciare direttamente in quello stato, è molto lontano ... è più facile salvare semplicemente le informazioni dall'interno del programma stesso, magari quando si esegue la manutenzione di un segnale .
A luglio 2014, sfortunatamente, CryoPID non è più mantenuto e non funziona sui kernel recenti. Ma nel frattempo nascono nuovi progetti (qualche passo è stato fatto anche nella connessione TCP "ibernazione"). Ho inserito una [risposta] (http://stackoverflow.com/a/24991425/1161591) qui sotto con informazioni aggiornate. Controlla! ;) – dappiu
@dappiu È grandioso - ma CryoPID è stato solo un _esempio_ in questa risposta per illustrare quanto possa essere difficile, dove ho continuato a suggerire di gestire il salvataggio dello stato all'interno del programma stesso, in modo tale da poter essere facilmente ripreso . Il ristagno di CryoPID non rende la risposta meno rilevante. –
Ovviamente, non intendevo dirlo! ;) – dappiu
C'è ctrl+z in linux, ma non sono sicuro che offra le funzionalità specificate. Sospetto che abbiate posto questa domanda dal momento che non è
La risposta breve è "sì". Potresti iniziare osservando questo per alcune idee: ELF executable reconstruction from a core image (http://vx.netlux.org/lib/vsc03.html)
Ctrl-Z aumenta le probabilità che le pagine del processo vengano scambiate, ma non libera completamente le risorse del processo. Il problema di liberare completamente le risorse di un processo è che cose come i manici dei file, i socket sono risorse del kernel che il processo può utilizzare, ma non sa come persistere da solo. Quindi Ctrl-Z è buono come sembra.
Il problema è il ripristino degli stream - file e socket - che il programma ha aperto.
Quando l'intero sistema è in stato di ibernazione, i file locali e così via possono ovviamente essere ripristinati. Le connessioni di rete no, ma in questo caso il codice che accede a Internet è in genere più controllo degli errori e tale e sopravvive alle condizioni di errore (o dovrebbe).
Se si è eseguita la sospensione per programma (senza supporto dell'applicazione), come gestireste i file aperti? Cosa succede se un altro processo accede a quei file nel frattempo? eccetera?
Mantenere lo stato quando il programma non è caricato sarà difficile.
Sospendere semplicemente i thread e lasciarli scambiare su disco avrebbe lo stesso effetto?
Oppure eseguire il programma in una macchina virtuale e lasciare che la VM gestisca la sospensione.
C'è stata qualche ricerca su checkpoint/ripristino per Linux in 2.2 e 2.4 giorni, ma non è mai riuscita a superare il prototipo. È possibile (con le avvertenze descritte nelle altre risposte) per alcuni valori possibili - io posso scrivere un modulo del kernel per farlo, è possibile. Ma per il valore comune del possibile (posso farlo dalla shell su una distribuzione Linux commerciale), non è ancora possibile.
La risposta breve è "sì, ma non sempre in modo affidabile". Partenza CryoPID:
Aprire i file saranno effettivamente essere il problema più comune. CryoPID dichiara esplicitamente:
I file aperti e gli offset vengono ripristinati. I file temporanei che sono stati scollegati e non accessibili sul file system vengono sempre salvati nell'immagine . Altri file che non esistono in corso di ripresa non sono stati ancora ripristinati. Supporto per il salvataggio del contenuto dei file per tali situazioni sono pianificate.
Gli stessi problemi riguarderanno anche le connessioni TCP, sebbene CryoPID supporti tcpcp per il ripristino della connessione.
Dopo aver premuto il pulsante di invio ora mi rendo conto che questo legge molto simile a spam/pubblicità per CryoPID. Non è - sono semplicemente un utente soddisfatto dell'utilità, davvero. –
Questo è l'obiettivo finale del sistema operativo in cluster. Mathew Dillon si impegna molto per implementare qualcosa di simile nel suo progetto Dragonfly BSD.
Questa funzione è completamente implementata in Dragonfly BSD? –
Non credo, è l'obiettivo "definitivo" ... –
Come altri hanno notato, è difficile per il sistema operativo fornire questa funzionalità, poiché l'applicazione deve avere un controllo degli errori integrato per gestire i flussi interrotti.
Tuttavia, su una nota a margine, alcuni linguaggi di programmazione e strumenti che utilizzano macchine virtuali supportano esplicitamente questa funzionalità, come ad esempio Self programming language.
Le risposte che citano ctrl-z stanno davvero parlando di interrompere il processo con un segnale, in questo caso SIGTSTP. È possibile emettere un segnale di arresto con kill:
kill -STOP <pid>
che sospenderanno l'esecuzione del processo. Non libererà immediatamente la memoria utilizzata da esso, ma poiché la memoria è richiesta per altri processi, la memoria utilizzata dal processo arrestato verrà gradualmente sostituita.
Quando si desidera svegliarsi di nuovo, utilizzare
kill -CONT <pid>
Le soluzioni più complicate, come CryoPID, sono veramente necessari solo se si desidera che il processo smesso di essere in grado di sopravvivere a un arresto del sistema/riavvio - non sembra che tu ne abbia bisogno.
Ho esteso Cryopid producendo un pacchetto chiamato Cryopid2 disponibile da SourceForge. Questo può migrare un processo così come ibernarlo (insieme a qualsiasi file aperto e socket - i dati in socket/pipe vengono risucchiati nel processo in stato di ibernazione e restituiti in questi quando il processo viene riavviato).
Il motivo per cui non sono stato attivo con questo progetto è che non sono uno sviluppatore del kernel - sia questo (e/o il cryopid originale) bisogno di avere qualcuno a bordo che possa farli correre con i kernel più lastest (ad es. Linux 3.x).
Il metodo Cryopid funziona - ed è probabilmente la soluzione migliore per il processo generalizzato ibernazione/migrazione in Linux che ho incontrato.
Linux Kernel ha ora implementato parzialmente il checkpoint/riavvio dei futures: https://ckpt.wiki.kernel.org/, lo stato è here.
Alcune informazioni utili sono nel LWN (netto settimanale linux): http://lwn.net/Articles/375855/http://lwn.net/Articles/412749/ ......
Quindi la risposta è "SI"
Il programma userspace è chiamato blcr. – Behrooz
mi piacerebbe mettere un aggiornamento di stato qui, 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 attivamente mantenuti che forniscono la funzionalità di checkpoint dell'applicazione.
Il primo, quello che suggerisco perche' ho più fortuna che lo gestisce, è CRIU che esegue checkpoint/ripristino principalmente in userspace, e richiede l'opzione del kernel CONFIG_CHECKPOINT_RESTORE permesso di lavorare.
Checkpoint/Restore nello spazio utente, o CRIU (pronunciato Kree-oo, IPA:/krɪʊ /, Russo: криу), è uno strumento software per il sistema operativo Linux. Utilizzando questo strumento, è possibile bloccare un'applicazione (o parte di essa) in esecuzione e controllarla su un disco rigido come 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 viene principalmente implementato nello spazio utente.
Quest'ultimo è DMTCP; citando loro pagina principale:
DMTCP (Distributed MultiThreaded Checkpoint) è uno strumento il punto di controllo trasparente lo stato di più applicazioni simultanee, comprese applicazioni multi-threaded e distribuiti. Funziona direttamente sull'eseguibile binario dell'utente, senza alcun modulo del kernel di Linux o altre modifiche del kernel.
C'è anche una bella pagina Wikipedia sull'argomento: Application_checkpointing
Domanda interessante: D – dangerstat
Ciò che si descrive in realtà è spesso definito come 'checkpoint', si potrebbe avere più fortuna la ricerca con quel termine. –
Deve essere.buona caratteristica. Hibernate vs chiudi. –