ここ実行ファイルを書き換えることができ、プロセスが正しく実行されると言います。プロセスが再起動すると、再び読み込まれます。
ただし、プロセスの実行中に（開発サーバーからテストサーバーにscpを使用して）バイナリを交換しようとすると、「ファイルが使用中」と表示されます。共有ライブラリファイル（* .so）を置き換えると、それを関連付けるすべてのプロセスが中断されます。
なぜこれですか？私は何を逃したことがありませんか？プロセスを停止/衝突させることなくバイナリを置き換えるにはどうすればよいですか？
答え1
で述べたようにアップグレード後もソフトウェアパッケージがまだ正常に動作するのはなぜですか？、ファイル名の代わりに inode にロックが設定されます。バイナリファイルをロードして実行すると、ファイルは使用中としてマークされます。そのため、ファイルに書き込もうとすると、ETXTBSY（ファイル使用中）エラーが発生します。
これで共有ライブラリの場合、状況は少し異なります。ライブラリはメモリをプロセスのアドレス空間にマッピングしますmmap()。指定することはできますが、MAP_DENYWRITE少なくともLinuxのGlibcはそれを自動的に無視します（マンページによると、自由にソースを確認してください）。これを確認してください。ワイヤー。したがって、実際にファイルに書き込むことができ、メモリがマップされているので、すべての変更がほぼすぐに表示されます。つまり、頑張れば管理できます。 レンガライブラリをコンピュータに上書きします。
したがって、正しい更新方法は次のとおりです。
ファイルを削除すると、ファイルシステムからデータへの参照が削除され、そのファイルを使用したい新しく作成されたアプリケーションからアクセスできなくなり、ファイルを開いたりマッピングしたりするすべての人がデータにアクセスできるようになります。
更新されたコンテンツで新しいファイルを作成します。
新しく作成されたプロセスは最新のコンテンツを使用し、実行中のアプリケーションは以前のバージョンにアクセスします。これが通常のパッケージ管理ユーティリティが実行する作業です。これはリスクがまったくないわけではないことに注意してください。たとえば、dlsym()コードを動的にロードするアプリケーション（ユーザーと友達）は、ライブラリのAPIが自動的に変更されると問題が発生します。
本物の人になりたいなら、本物安全を維持するには、システムをシャットダウンし、別のOSインスタンスからファイルシステムをマウントし、更新されたシステムを再度更新して起動します。
答え2
rpm アップグレードの効果は同じです。つまり、競合なしでバイナリとライブラリを実行します。
では、違いは何ですか？
- ファイルのリンク解除
- 同じ名前で新しいファイルを作成する
これはファイルを適切な場所に置き換えません。使用中のバイナリファイルを参照するinodeは、そのファイルを開いたままにした最後のオブジェクトが完了するまで「使用中」のままです。新しいファイルは新しい inode 番号で生成されます。
今scp、またはcp所定の位置にあるファイルを置き換えようとします。これにより、inodeが参照する内容が変更されます。説明したように動作しません。