私は長年にわたって毎日Linuxシステムを使用してきましたが、システムの実行中にシステムを更新するのに大きな問題はありませんでしたが、なぜこれが起こるのか疑問に思います。
たとえば、見てみましょう。
特定のパッケージのプログラム「Ａ」がシステムで実行されていると仮定する。ある時点で、プログラムは同じパッケージ内の別のファイル（「B」）を開く必要があります。その後、プログラム「Ａ」は不要になったので「Ｂ」を終了する。ここで、「A」と「B」が属するパッケージを更新するとしましょう。 「A」はRAM上で実行され、更新は単にハードドライブの「A」に取って代わるため、少なくとも現在はこの操作の直接的な影響を受けません。ファイルシステムの「Ｂ」も交換されたとする。今、何らかの理由で「A」は「B」を読み直す必要があります。問題は、「A」が「B」の互換性のないバージョンを見つけてクラッシュまたは誤動作する可能性がありますか？
Live CDや同様のプログラムを使用して再起動してシステムを更新しないのはなぜですか？
答え1
ユーザースペースの更新はほとんど問題ありません。
次の理由により、ライブシステムでパッケージを頻繁に更新できます。
- 共有ライブラリは、呼び出すたびにディスクから読み取られずにメモリに保存されるため、アプリケーションを再起動するまで、以前のバージョンは引き続き使用されます。
- 開かれたファイルは、実際には次からインポートされます。ファイル記述子したがって、移動/名前変更/削除された場合でも、セクタを上書きするか、ファイル記述子が閉じられるまで実行中のアプリケーションでファイルの内容を引き続き使用できます。
- パッケージがうまく設計されている場合、再ロードまたは再起動が必要なパッケージは通常、パッケージマネージャが正しく処理できます。たとえば、Debianはlibc6がアップグレードされるたびに特定のサービスを再起動します。
通常、カーネルを更新して ksplice を使用していない場合は、更新プログラムを利用するためにプログラムやサービスを再起動する必要があります。ただし、デスクトップでは個々のサービスを再起動するよりも簡単な場合がありますが、ユーザースペースのエントリを更新するためにシステムを再起動する必要はほとんどありません。
また、見ることができます
http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode
答え2
はい、説明した内容は可能です。ただし、ほとんどの場合、ファイルがパッケージに含まれている場合は一度だけ読み取られるライブラリやその他のファイルになります（変更されないため、何度も読み取る理由はありません）。タイムズ）。さらに、ファイルが長期間必要な場合、アプリケーションはファイルハンドルを開いたままにすることができます。ここで開かれたファイルハンドルは、実際のファイルシステムで置き換えられても古いバージョンを開いたままにします。
ほとんどの場合、プロセスのライフサイクル中に複数回読み取られるデータはユーザー/変数データであり、パッケージのアップグレード中に変更されません。また、データは変更可能であるため、正しい考えを持つプログラマーである場合は、プログラムがある読み取りから次の読み取りまでの変更を処理できることを確認する必要があります。
答え3
ファイルシステムの「Ｂ」も交換されたとする。今、何らかの理由で「A」は「B」を読み直す必要があります。問題は、「A」が「B」の互換性のないバージョンを見つけてクラッシュまたは誤動作する可能性がありますか？
これは可能ですが、ほとんどの場合、可能性は低いです。 「B」がコードベースの場合、元のバージョンは通常閉じられません。 「A」は「B」の元のバージョンを引き続き使用します。アップデート後に「A」を実行すると、新しいバージョンの「B」が使用されます。アップデート中に互換性のないバージョンがロードされる危険性があります。ただし、コードベースのロード方法のため、「A」にロードされる「B」バージョンにない機能が必要な場合にのみ問題になります。
良いコーディング習慣は、機能的なインターフェースを同じに保ちます。したがって、新しいバージョンでバグが修正されない限り、どのバージョンがロードされるかは問題ではありません。
設定ファイルの状況は少し異なりますが、通常は起動時に読み込まれます。この場合、構成変更を再ロードしないと、「A」は「B」を読みません。同様に、構成ファイルの形式や意味を変更することは、誤ったコーディング習慣です。互換性のない構成ファイルのバージョンには、問題を引き起こさないように別の名前が必要です。
Live CDや同様のプログラムを使用して再起動してシステムを更新しないのはなぜですか？
終了してから別のバージョンで再起動すると、サービスが中断される可能性があります。これは通常、サーバーにとって望ましくありません。それにもかかわらず、実行中のシステムのパッケージマネージャは、インストールされているソフトウェアとバージョンを知っています。 Live CD にはインストールされたソフトウェアの独自のリストがあり、バージョンが異なる場合があります。これにより、Live CDで実行されているシステムを確実にアップグレードすることが困難になります。
新しいバージョンのオペレーティングシステムをインストールするときにLive CDが使用されることがあります。この場合、通常はオペレーティングシステムの新規インストールが完了します。これにより、保持される以前のバージョンの未使用ファイルの数が制限されます。これはライブシステムをアップグレードするよりも難しいかもしれません。ただし、別のルートパーティションを使用すると、部分的に更新されたシステムが起動しないため、輻輳するリスクを制限できます。
答え4
これは次の場合に問題になります。
- java-VM ランタイムのための JDK アップグレード: 私も同じ質問を自分にしました。 javaを使用して実行中のtomcatがあります。これで、JDKにパッチを適用した後もまだうまく動作しているようです。
現在の説明はキャッシュです。いいですね。利用可能なRAMをすべて消費するメモリホグを起動しました。その後、Tomcatがクラッシュしました（ここで実行されているアプリケーションにアクセスした後）。
- SuSEシステムのカーネルアップグレード：SuSEでは、カーネルパッチのアップグレード後、以前のカーネルとそのモジュールがすぐに削除されます。これまでロードされていないカーネルモジュールが必要な新しいものを使用しようとすると、サービスは失敗します。