https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/
...これらのストレージデーモンはinitramfsから始まり、通常の動作中に実行され続け、制御権がinitramfsに返された後にのみ終了し、initramfsによって終了します。したがって、概念的には、ルートファイルシステムのストレージメンテナンスに関連するストレージデーモンは、通常のシステムサービスよりもカーネルスレッドに似ています。 initシステム（例：systemd）の観点から、これらのサービスはsystemdが初期化される前に開始され、systemdの後まで維持されます。消えた。
しかし、systemdの起動後にinitramfsは削除されませんか？私のFedora 28システムはどこにもinitramfsがインストールされていません。 [*]
「ルートストアデーモン」が実行されるファイルシステムはどこにありますか？
彼らの観点から見ると、これはどのような姿でしょうか？たとえば、/dev実行時にフル機能にアクセスできますか？
[*]ディレクトリがありますが、/run/initramfs独立したRAMファイルシステム（tmpfsマウント）ではありません。ファイルがないいくつかのディレクトリとディレクトリ名を一覧表示する1つのファイルをrwtab除いて、空です。
$ findmnt -T /run/initramfs
TARGET SOURCE FSTYPE OPTIONS
/run tmpfs tmpfs rw,nosuid,nodev,seclabel,mode=755
$ find /run/initramfs -type d
/run/initramfs
/run/initramfs/state
/run/initramfs/state/var
/run/initramfs/state/var/lib
/run/initramfs/state/var/lib/dhclient
/run/initramfs/state/etc
/run/initramfs/state/etc/sysconfig
/run/initramfs/state/etc/sysconfig/network-scripts
/run/initramfs/log
$ find /run/initramfs -not -type d
/run/initramfs/rwtab
/run/initramfs/.need_shutdown
$ cat /run/initramfs/rwtab
files /etc/sysconfig/network-scripts
files /var/lib/dhclient
$ cat /run/initramfs/.need_shutdown
$
答え1
しかし、systemdの起動後にinitramfsは削除されませんか？
いいえ。 initramfsファイルシステム実際には削除できません。。
少なくともinitramfsがを使用して実装されるとsystemd呼び出されますが、umount()フラグは渡されますMNT_DETACH。また、見ることができますumount -l。
（このモードumount()はいいえ開いているファイルがある場合はブロックされます。 initramfsファイルシステムをマウントポイントから「分離」してマウントテーブル（/proc/mountsなど）から削除します。開いているすべてのファイルは引き続き使用できます。開いているファイルをすべて閉じた後、それからカーネルはファイルシステムのマウント解除を完了します。
「ルートストアデーモン」が実行されるファイルシステムはどこにありますか？彼らの観点から見ると、これはどのような姿でしょうか？
これ魂「RootStorageDaemons」は、存在し続けることを意味します。優れたinitramfs。
マウントの取り外しに加えて、MNT_DETACHすべてのサブマウントも分離します。したがって、ルートリポジトリデーモンは/ devおよび/ procマウントを含む重要なAPIファイルシステムを表示できません。これは本当に残酷です。
# unshare -m
\# umount -l /
\# findmnt
findmnt: can't read /proc/mounts: No such file or directory
\# ls /dev
\#
MNT_DETACHを使用した後、 systemdswitch_rootinitramfsでより伝統的なコマンドと一致し続け、pass削除initramfsで各ファイルを切断（）します。 （systemd関数はrm_rf_children()実際にこれを行いますrm -rf *。通常のようにデーモンを実行するための実行可能ファイルとライブラリファイルを含むすべての開いているファイルは引き続き機能します。ファイルへの最後の参照が閉じられると、そのリポジトリはカーネルによって解放されます。 。
これが本当なら、とても興味深いでしょう。ルートファイルシステムでファイルを開くRootStorageDaemonのバグに対する良い保護になります。また、/runファイルシステムのソケットを介して行われたRPC呼び出しと、ルートファイルシステムで実行されるデーモンに対する依存関係に対する部分的な保護も提供します。これらの操作を実行すると、デッドロック（循環依存関係）が発生する可能性があります。
しかし事実、ルートリポジトリデーモンを見ると、/proc/$PID/rootinitramfsではなくデフォルトのルートファイルシステムを指す可能性が高くなります。それでは、なぜこれが起こり、この状況でシステムはどのように機能しますか？
これは、initramfsがpivot_root()ルートファイルシステムに切り替えるために使用されるために発生します。マウントテーブルの変更に加えて、現在のすべてのプロセスのルートpivot_root()ディレクトリと現在の作業ディレクトリ（/proc/$PID/rootおよび）を確認します。/proc/$PID/cwdこれらのいずれかが古いルートファイルシステム（initramfs）のルートと一致すると、新しいルートファイルシステムに置き換えられます。これは実装の詳細として文書化されておりpivot_root()、プログラムはそれに依存してはいけません。
<del>システムは切り替えが可能pivot_root()なため動作します。systemd後ろにinitramfsに。したがって、ルートファイルシステムへの参照は、輝く新しいinitramfsへの参照に置き換えられます。</del>
/run（光沢のある新しいinitramfsのtmpfsがルートファイルシステムから渡される可能性があります/run。これはinitramfsから渡されます。この場合、initramfsを閉じてRootStorageDaemonと通信できると思います。デーモンは起動/runシーケンス中にソケットを開きます。