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


25

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

例を挙げましょう。

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

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


私はそのような更新を避けることを好む傾向がありますが、これは更新の仕組みのためではなく(これは問題なく実行できます)、むしろ最初にアプリケーションと設定を変更に対してテストする設定のためです。それから、私は、ただ更新するために、今更新された別個のシステムを持っているでしょう。しかし、それ以外は、ユーザーランドでの更新は一般に問題ではありません。小規模な修正やセキュリティの修正については、私がやるだけです。
スカペレン

回答:


23

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

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

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

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

こちらもご覧ください

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


しかし、すべてのキャッシュメモリが必要な場合はどうなりますか?その場合、共有ライブラリをディスクから再度ロードする必要があります
Nils

3
実際、#1の説明はそれほど明確ではありませんでした。古いライブラリファイルの内容は、リンクしているすべての名前がなくなっても、何らかのプロセスがファイルを開いているか、その内容がマップされている限り、データは明確に保持されます(そしてファイルシステムはファイルのリンク解除が完了するまでr / oを再マウントしてください)。元のファイルをマップしたプロセスには、元のコンテンツへのメモリマッピングが残っています。
スカペレン

@Nils私は専門家ではありませんが、キャッシュが不足すると、スワップに書き込まれ、そこから再読み取りされませんか?それがいっぱいの場合、すでに使用している別のプロセスからメモリを奪う前に、おそらくいくつかのプロセスがブロックされます。
ジョー

@ジョーいいえ-スワップもラムです。Skaperenは何が起こるかを説明しています。ファイルハンドルはそのまま保持されています。基本的に、プログラムには古い(なくなった)ライブラリへの1つのハドルがあり、そのハンドルが再び解放されるまで削除されません-これはすべてRAMレベルではなくファイルシステムレベルで行われます。
ニルス

4

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

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


ファイルのマッピングがメモリ内で変更を行わなかった場合(利用可能な場合はバッキングストアをスワップに変更する場合)、ファイルは「バッキングストア」として再読み込みできます。メモリ。ただし、元のファイルはまだ開いているかマップされているため、これは問題になりません。置換ライブラリは、古いプロセスが開いていない新しい異なるファイルです。
スカペレン

1
@Skaperenあなたはメモリマップドファイルについて話していると思います。これらは、パッケージをアップグレードするときの問題ではありません。すべてのパッケージマネージャーは、古いファイルを上書きするのではなく、新しいファイルを作成して古いファイルを置き換えます。実際、これは実行中の実行可能ファイルは変更できず、リンク解除しかできないため、これを行う唯一の方法です。
パトリック

4

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

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

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

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

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

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

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


0

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

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

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

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

2
Tomcatの一部が再起動されたか、動的ライブラリがJavaレベル(たとえばdlopen()など)の下で使用されたため、ライブAPIが混在する可能性があります。
スカペレン

彼らはキャッシュがまばらな...なっている場合は任意のプログラムはトラブルを持っている必要があり、使用後に閉じ取得した場合-共有ライブラリを使用していても@Skaperen
ニルス

1
開いているファイル記述子には、ディスク上のデータをディレクトリ内のファイルの名前と同じように保持する能力があります。ディスク上にハードリンクまたは開いているファイル記述子がある限り、元のiノードは削除さません。キャッシュはそれとは何の関係もありません。現在、一部のプログラムは、ファイル記述子を使用していないときにファイル記述子を閉じるため、データが失われる可能性があります。
dmckee

@dmckeeそう。コアに近づいています。それでは、「通常の」プログラムの通常の動作は次のとおりです。ライブラリを開いて開いたままにするか、ライブラリをロードして閉じますか?
ニルス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.