実行中のLinuxシステムの更新に問題がないのはなぜですか？

私は毎日Linuxシステムを使用している年であり、実行中にシステムを更新することで大きな問題は一度もありませんでしたが、なぜこれが可能か疑問に思います。

例を挙げましょう。

特定のパッケージのプログラム「A」がシステムで実行されているとします。このプログラムは、ある時点で、同じパッケージから別のファイル（「B」）を開く必要があります。その後、プログラム「A」は「B」を必要としないため、閉じます。今、「A」と「B」が属するパッケージを更新するとします。「A」は、RAMで実行されており、ハードディスク上の「A」を置き換えただけなので、少なくとも現時点では、この操作の直接の影響を受けません。ファイルシステムの「B」も置き換えられたとします。現在、「A」は何らかの理由で「B」を再度読み取る必要があります。問題は、「A」が「B」の互換性のないバージョンを見つけて、他の方法でクラッシュまたは誤動作する可能性はありますか？

ライブCDまたは同様の手順で再起動してシステムを更新する人がいないのはなぜですか？

ユーザーランドの更新はめったに問題ではない

多くの場合、ライブシステムでパッケージを更新できます。

1. 共有ライブラリは、呼び出しごとにディスクから読み取られるのではなく、メモリに格納されるため、アプリケーションが再起動されるまで古いバージョンが使用され続けます。
2. 開いているファイルは、実際にはファイル記述子から読み取られますはファイル名ではなくため、セクターが上書きされるかファイル記述子が閉じられるまで、移動/名前変更/削除されても、実行中のアプリケーションはファイルの内容を利用できます。
3. 再ロードまたは再起動が必要なパッケージは、パッケージが適切に設計されていれば、通常パッケージマネージャーによって適切に処理されます。たとえば、Debianはlibc6がアップグレードされるたびに特定のサービスを再起動します。

一般に、カーネルを更新していてkspliceを使用していない場合を除き、更新を利用するにはプログラムまたはサービスの再起動が必要になる場合があります。ただし、ユーザーランドで何かを更新するためにシステムを再起動する必要はほとんどありませんが、デスクトップでは個々のサービスを再起動するよりも簡単な場合があります。

こちらもご覧ください

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode

はい、あなたが説明したことは可能ですが、ほとんどの場合、ファイルがパッケージに含まれている場合、それは一度だけ読み取られるライブラリまたは他のファイルになります（変更されないため、理由はありません複数回読んでください）。また、ファイルが長期間必要な場合、アプリケーションはファイルハンドルを開いたままにする可能性があります。実際のファイルシステムで置き換えられても、開いているファイルハンドルは古いバージョンを開いたままにします。

ほとんどの場合、プロセスの存続期間中に複数回読み取られるデータはユーザー/変数データであり、パッケージのアップグレード中に変更されることはありません。さらに、データは可変であるため、正しい考えを持つプログラマーであれば、読み取りから読み取りへの変更をプログラムが処理できることを確認できます。

ファイルシステムの「B」も置き換えられたとします。現在、「A」は何らかの理由で「B」を再度読み取る必要があります。問題は、「A」が「B」の互換性のないバージョンを見つけて、他の方法でクラッシュまたは誤動作する可能性はありますか？

これは可能ですが、ほとんどの場合は考えられません。「B」がコードライブラリの場合、元のバージョンは通常閉じられません。「A」は「B」の元のバージョンを引き続き使用します。更新後に「A」を実行すると、「B」の新しいバージョンが使用されます。更新中に、互換性のないバージョンがロードされる可能性があるというリスクがあります。ただし、コードライブラリのロード方法により、「A」がロードした「B」のバージョンに存在しない機能が必要な場合にのみ問題になります。

優れたコーディング慣行により、機能へのインターフェースは同じに保たれます。結果として、新しいバージョンで修正されたバグがある場合を除いて、どのバージョンがロードされるかは重要ではありません。

構成ファイルは少し異なりますが、通常は起動時に読み込まれます。この場合、設定のリロードが変更されない限り、「A」は「B」とは読みません。繰り返しになりますが、構成ファイルの形式または意味を変更することは、コーディングの習慣として不適切です。構成ファイルの互換性のないバージョンには別の名前を付ける必要がありますので、問題は発生しません。

ライブCDまたは同様の手順で再起動してシステムを更新する人がいないのはなぜですか？

別のバージョンからシャットダウンして再起動すると、サービスが停止します。サーバーの場合、これは一般的に望ましくありません。いずれにしても、実行中のシステムのパッケージマネージャーは、インストールされているソフトウェアとバージョンを認識しています。ライブCDには、インストールされているソフトウェアのリストがあり、バージョンが異なる場合があります。これにより、実行中のシステムをライブCDから確実にアップグレードすることが難しくなります。

ライブCDは、O / Sの新しいリリースをインストールするときに使用される場合があります。この場合、O / Sのクリーンインストールが通常行われます。これにより、保持される以前のバージョンの未使用ファイルの量を制限できます。ライブシステムをアップグレードするよりも手間がかかる場合があります。ただし、異なるルートパーティションを使用すると、起動できない部分的に更新されたシステムでスタックするリスクを制限できます。

これが問題になる場合がいくつかあります。

• java-VMの実行中のJDKのアップグレード：myselvにあなたと同じ質問をしました-javaを使用してTomcatを実行していました。JDKのパッチ更新後も、問題なく実行されました。

現在、説明はキャッシュメモリです。OK-メモリホグプログラムを開始して、使用可能なすべてのRAMを使い果たしました-そして、tomcatがクラッシュしました（そこで実行されているアプリケーションにアクセスした後）。

• SuSEシステムでのカーネルのアップグレード：SuSEでは、カーネルのパッチアップグレードの直後に古いカーネルとそのモジュールが削除されます。その後、カーネルモジュールを必要とする、今までロードされていなかった新しい何かを使用する場合、サービスは失敗します。