Linuxでメモリをディスクに保存して後で復元することで、プロセスを「休止状態」にする方法は？
Linuxでプロセスを「休止状態にする」ことは可能ですか？ラップトップの「休止状態」のように、プロセスで使用されるすべてのメモリをディスクに書き込み、RAMを解放します。その後、「プロセスを再開する」、つまりメモリからすべてのデータを読み取り、RAMに戻して、プロセスを続行できますか？
以前は CryoPID を維持していましたが、これはまさにあなたが話していることをするプログラムです。プログラムのアドレス空間、VDSO、ファイル記述子の参照および状態の内容を、後で再構築できるファイルに書き込みます。 CryoPIDは、Linux自体に使用可能なフックがないときに開始され、ユーザー空間から完全に機能しました（実際、ディストリビューション/カーネル/セキュリティ設定に応じて、引き続き機能します）。
問題は（実際に）ソケット、保留中のRTシグナル、多数のX11の問題、glibcキャッシングgetpid（）実装など）でした。バーナードがそこから立ち去った後、それに取り組んでいたが、それは楽しく、いくつかの修士論文のトピックとなった。
実行状態を保存し、その状態に直接再起動できるプログラムを考えている場合、おそらく信号を処理するときに、プログラム自体からその情報を保存する方がはるかに簡単です。
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などのより複雑なソリューションは、停止したプロセスがシステムのシャットダウン/再起動に耐えられるようにする場合にのみ本当に必要です-必要なようには聞こえません。
問題は、プログラムが開いているストリーム（ファイルとソケット）を復元することです。
OS全体が休止状態になると、ローカルファイルなどが明らかに復元されます。ネットワーク接続はそうではありませんが、インターネットにアクセスするコードは通常、より多くのエラーチェックなどであり、エラー状態を乗り越えます（またはそうすべきです）。
プログラムごとに休止状態にした場合（アプリケーションサポートなし）、開いているファイルをどのように処理しますか？別のプロセスがその間にそれらのファイルにアクセスするとどうなりますか？等？
プログラムがロードされていないときに状態を維持することは困難です。
単にスレッドを一時停止し、ディスクにスワップさせるだけでも同じ効果がありますか？
または、仮想マシンでプログラムを実行し、VMがサスペンションを処理するようにします。
簡単な答えは「はい、しかし常に確実ではない」です。 CryoPIDを確認してください。
実際、開いているファイルは最も一般的な問題です。 CryoPIDの明示的な状態：
開いているファイルとオフセットが復元されます。リンクされておらず、ファイルシステム上でアクセスできない一時ファイルは、常にイメージに保存されます。再開時に存在しない他のファイルはまだ復元されていません。このような状況でのファイル内容の保存のサポートが計画されています。
同じ問題はTCP接続にも影響しますが、CryoPIDは接続の再開のためにtcpcpをサポートします。
Linuxカーネルは現在、チェックポイント/リスタート先物を部分的に実装しています： https://ckpt.wiki.kernel.org/ 、ステータスは here です。
いくつかの有用な情報がlwn（linux weekly net）にあります。 http://lwn.net/Articles/375855/http://lwn.net/Articles/412749/ = ......
答えは「はい」です
SourceForgeから入手可能なCryopid2というパッケージを作成して、Cryopidを拡張しました。これにより、プロセスを休止状態にするだけでなく、移行することができます（開いているファイルとソケットとともに-ソケット/パイプ内のデータは休止状態でプロセスに吸い込まれ、プロセスの再起動時にこれらに戻ります）。
私がこのプロジェクトで活動していなかった理由は、私はカーネル開発者ではないということです。これ（および/または元のcryopid）は、最新のカーネル（Linux 3.xなど）で実行できる人を乗せる必要があります。
Cryopidメソッドは機能します。これはおそらく、私が遭遇したLinuxでの汎用プロセスの休止状態/移行に対する最適なソリューションです。
短い答えは「はい」です。いくつかのアイデアについてこれを見て開始することができます： コアイメージからのELF実行可能再構築 （ http：// vx.netlux.org/lib/vsc03.html ）
他の人が述べたように、壊れたストリームを処理するためにアプリケーションに組み込みのエラーチェックが必要なため、OSがこの機能を提供することは困難です。
ただし、副次的に、仮想マシンを使用する一部のプログラミング言語およびツールは、 Self programming language など、この機能を明示的にサポートしています。
Linuxのチェックポイント/復元に関する調査は2.2日と2.4日で行われましたが、プロトタイプを通過することはありませんでした。可能性のある特定の値については可能です（他の回答で説明されている注意事項を使用）-それを行うためのカーネルモジュールを書くことができます、可能です。しかし、可能性の一般的な価値のために（商用Linuxディストリビューションのシェルからそれを行うことはできます）、それはまだ不可能です。
これは、クラスター化されたオペレーティングシステムの最終的な目標の一種です。 Mathew Dillonは、このようなものを Dragonfly BSD プロジェクトに実装するために多大な努力を払っています。