共有ライブラリに依存するプログラムの実行中に共有ライブラリを削除しても安全ですか？

通常、文書はそうではありません。実際にdeleteを使用すると、削除されますが、rm開いているすべてのファイルハンドルも閉じた後にのみ可能です。ファイルがプロセスのメモリにマッピングされても、これが適用されると確信しています。その後、rmファイルを再度開くことはできませんが、データとマッピングはそのまま残ります。

ファイルデータの「バージョン」が1つだけで、すべての読み取り、書き込み、共有マッピングが同じデータにアクセスするため、ファイルの変更は別の話です。ここにゴミを書くと、そのファイルでコードを実行するプロセスもゴミを得ることになります。 Linuxでは、実行可能ファイルを使用してこれを実行することはできず、エラー（「テキストファイルを使用中」）が発生しますが、共有ライブラリに対するこれらの保護はありません。

（試してみるcp -a /bin/cat /tmp/cat; /tmp/cat &ことができます。次に試してください。echo 123 >> /tmp/cat次にfg戻りcat、Ctrl-Cを押して閉じます。）

rm技術的には、これは実際にファイルをまったく削除せずにファイル名だけを削除すると言うことができます。ファイルは複数の名前を持つことができ、それをハードリンクと呼びます。ただし、これは基本的に同じファイルの複数の名前にすぎません。実際の削除は、一般的に姓が削除され始めますが、やや独立しています。

私の考えでは、プログラムが実行されている場合、ライブラリから必要なすべてのデータがメモリにロードされるため、そう思います。

実行可能データの読み取り必要なときだけ179 134 080そうしないと、Google Chrome（バイナリの現在のバイト単位）などの重いアプリケーションを実行するのに長い時間がかかります。また、WindowsのWinRARを使用すると、2^64 - 1最大サイズの自動解凍アーカイブを作成できます。カーネルが起動する前にすべてのコードをRAMにロードする必要がある場合、そのコードを抽出することはできません。

ライブラリがすでにメモリにあり、ディスクのライブラリが変更されてプログラムがクラッシュするのはなぜですか？

全体がメモリ内にあるわけではなく、実行プロセスにのみマップされます。カーネルが実際にライブラリのコードを実行することを決定した場合、そのコードはキャッシュされますが、それまではディスクドライブにのみ残ります。

ライブラリが実行され、読み込まれてキャッシュされていても、カーネルにメモリが足りなくなってもキャッシュできます。

実際にファイルを交換し、カーネルが実行を要求した機能を見つけようとするため、競合が発生します。ファイルを上書きすると、これらの関数はゴミになり、アプリケーションがクラッシュします。

ライブラリがメモリに存在しない場合、ディスクから削除してもプログラムを実行し続けることができるのはなぜですか？ライブラリのデータはどこで読むのですか？

Linuxカーネルで使用されるUnixアーキテクチャでは、開いているファイルを削除できます。ファイルへのハンドルの数が0より大きいので、ファイルはいいえ最後のノブが閉じるまで技術的に取り外します。

共有ライブラリに依存するプログラムの実行中に共有ライブラリを削除しても安全ですか？

はい、完璧です。そのようなライブラリを上書きすることは安全ではありません。カーネルは古い（削除された）ライブラリを使用しているため、再交換するのは安全です。これにより、システムを再起動せずにほぼすべてのライブラリを交換できます。これを交換する場合にのみ、それを使用するすべてのアプリケーションを再起動する必要があります。

最後に、Linuxカーネルは数年前にパッチが適用され、独自の動的置換が可能になりました。https://ostechnix.com/5-kernel-live-patching-tools-that-will-help-to-run-linux-servers-without-reboots/