良いところに目を付けています。
結論から言うと systemdに「1つの統一されたキャッシュ機構」があるわけではなく、用途ごとに異なる技術で「状態・キャッシュ・永続情報」を保持しています。
それを Linuxカーネルの仕組み＋systemd独自設計で成立させています。
以下、仕組みを分解して説明します。
1. systemdにおける「キャッシュ」という言葉の正体
systemd文脈で「キャッシュ」と呼ばれがちなものは、実際には次の3種類に分かれます。
永続状態（state）
ランタイム状態（runtime state）
ログ・ジャーナル（journal）
systemdは「再起動しても覚えている情報」と「再起動したら消える情報」を意図的に分離しています。
2. 永続的に保管される仕組み（再起動後も残る）
2.1 /var/lib/systemd/ — 永続状態の中枢
ここに保存されるのは systemd自身が管理する状態データです。
例：
サービスの失敗カウンタ
有効化（enable/disable）状態
ジョブの結果
技術的特徴：
通常のファイルシステム（ext4, xfsなど）
systemdが独自フォーマットで管理
fsync を適切に使い、クラッシュ耐性を確保
つまり
**「DB」ではなく「堅牢に書き込まれたファイル状態」**です。
2.2 systemd-journald（ログの永続化）
技術の核心
メモリ＋ディスクのハイブリッドログ
バイナリログ
インデックス付きログ構造
保存先：
永続化有効時：/var/log/journal/
一時ログ：/run/log/journal/
内部構造：
mmap（メモリマップドI/O）
追記型ファイル
ハッシュインデックスによる高速検索
なぜ消えないのか：
3. 一時的に保管される仕組み（再起動で消える）
3.1 /run/ — tmpfsによる揮発ストレージ
/run は systemd起動時にマウントされる tmpfs（メモリ上の仮想FS）。
保存されるもの：
PIDファイル
ソケット状態
サービスのランタイム情報
技術：
RAM上（スワップされる場合あり）
シャットダウンで完全消去
高速・低レイテンシ
これは
**キャッシュというより「現在の状態スナップショット」**です。
4. systemdが「キャッシュを保管し続けられる理由」
4.1 カーネルのページキャッシュを積極活用
systemd自身は
つまり：
ファイルはディスクに書かれる
読み込みはカーネルがRAMにキャッシュ
systemdは「普通にファイルを読むだけ」
4.2 明示的な永続化ポリシー
systemdは設計段階から：
という強いポリシー分離をしています。
これにより
キャッシュが「いつの間にか残る」
逆に「必要なものが消える」
という事故を防いでいます。
5. systemdはなぜ独自キャッシュDBを作らなかったのか
理由は明確です。
再起動耐性は FSの責任
キャッシュ管理は カーネルの責任
systemdは オーケストレーターに徹する
そのため
Redisのような常駐DBは不要
SQLiteすら基本使わない
「ファイル＋tmpfs＋journal」で完結
これは UNIX哲学を現代化した設計です。
6. まとめ（要点だけ）
systemdの「キャッシュ」は単一機構ではない
技術的内訳は：
キャッシュ保持の実体は：
Linuxカーネルのページキャッシュ
systemdの明確な保存ポリシー
DB的なものは使わず、FSとカーネルに全面委任
この記事へのコメント