私は CryoPID を維持していました。これはまさにあなたが話していることを実行するプログラムです。プログラムのアドレス空間、VDSO、ファイル記述子の参照、および状態の内容を、後で再構築できるファイルに書き込みます。 CryoPID は、Linux 自体に使用可能なフックがなく、ユーザー空間から完全に機能したときに開始されました (実際、ディストリビューション / カーネル / セキュリティ設定によっては、まだ機能しています)。
問題は (実際) ソケット、保留中の RT シグナル、多数の X11 の問題、glibc キャッシュの getpid() 実装などでした。ランダム化 (特に VDSO) は、Bernard がそれから離れた後、それに取り組んでいる数人の私たちにとって克服できないことが判明しました。しかし、それは楽しく、いくつかの修士論文の話題になりました.
実行中の状態を保存し、その状態で直接再起動できるプログラムを検討している場合は、おそらくシグナルを処理するときに、プログラム自体からその情報を保存する方がはるかに簡単です。
2014 年現在の最新状況をここに掲載したいと思います。
受け入れられた回答は、チェックポイント/復元を実行するツールとして CryoPID を示唆していますが、プロジェクトは管理されておらず、最近のカーネルでコンパイルすることは不可能であることがわかりました.現在、アプリケーションのチェックポイント機能を提供する 2 つの積極的に管理されているプロジェクトを見つけました.
最初に提案するのは、運がよかったので、主にユーザー空間でチェックポイント/復元を実行する CRIU であり、機能するにはカーネル オプション CONFIG_CHECKPOINT_RESTORE を有効にする必要があります。
<ブロック引用>Checkpoint/Restore In Userspace、または CRIU (kree-oo と発音、IPA:/krɪʊ/、ロシア語:криу) は、Linux オペレーティング システム用のソフトウェア ツールです。このツールを使用すると、実行中のアプリケーション (またはその一部) をフリーズし、ファイルのコレクションとしてハード ドライブにチェックポイントを設定できます。その後、ファイルを使用して、フリーズした時点からアプリケーションを復元および実行できます。 CRIU プロジェクトの際立った特徴は、主にユーザー空間で実装されることです。
後者は DMTCP です。メインページからの引用:
<ブロック引用>DMTCP (Distributed MultiThreaded Checkpointing) は、マルチスレッドおよび分散アプリケーションを含む複数の同時アプリケーションの状態を透過的にチェックポイントするツールです。これは、Linux カーネル モジュールやその他のカーネル変更なしで、ユーザー バイナリ実行可能ファイルで直接動作します。
引数に関する素敵なウィキペディアのページもあります:Application_checkpointing
ctrl-z に言及している回答 シグナルでプロセスを停止することについて実際に話している、この場合は SIGTSTP . kill で停止信号を出すことができます :
kill -STOP <pid>
これにより、プロセスの実行が中断されます。使用されているメモリをすぐに解放するわけではありませんが、他のプロセスがメモリを必要とするため、停止したプロセスが使用していたメモリは徐々にスワップアウトされます。
もう一度起こしたい時は
kill -CONT <pid>
CryoPID などのより複雑なソリューションは、停止したプロセスをシステムのシャットダウン/再起動後も存続させたい場合にのみ必要です。必要なようには思えません.