gists

待機の本体: scripts/inbox_watcher.sh が queue/inbox/<agent>.yaml を inotifywait で監視。変更イベントが来るまでブロックして待機。

どういう意味？ inotifywait って何？ これは「エージェント宛ての指示ファイル（YAML）が更新されるのを、Linux の仕組みで“待ち受ける”」という説明です。

文の意味（かみ砕き）

• scripts/inbox_watcher.sh というシェルスクリプトが動く
• queue/inbox/<agent>.yaml（<agent>はエージェント名などに置き換わる）というファイルを監視する
• そのファイルが 書き換えられた／作られた／移動された などの「変更イベント」が起きるまで、スクリプトは何もせず ブロック（待機） する
• 変更が起きた瞬間に起きて処理を再開する

要するに「ポーリング（何秒ごとにファイルを見に行く）ではなく、OSから通知が来るまで寝て待つ」方式です。

inotifywait って何？

inotifywait は Linux の inotify（ファイル変更通知） という機能を使って、

• ファイル/ディレクトリの変更（作成、更新、削除、移動など）を監視し
• 変更が起きたらその時点で戻ってくる（=待機が解除される）

ためのコマンドです。通常は inotify-tools というパッケージに入っています。

例

inotifywait -e modify queue/inbox/agent1.yaml

このコマンドは agent1.yaml が更新（modify）されるまで待ち続け、更新されたら終了（あるいは次の処理へ）します。

ループで使うと「更新があるたびに処理」を作れます：

while inotifywait -e modify queue/inbox/agent1.yaml; do
  echo "updated!"
done

「ブロックして待機」って？

CPUを使って延々チェックするのではなく、変更が来るまで処理が止まった状態になります（効率が良い）。

必要なら、その inbox_watcher.sh の中身を貼ってくれれば、どのイベントを監視してどう動く設計かも具体的に説明できます。

inotifywait ってどう実装されてるの？ 自分でファイル監視処理をつくるより効率がいいのかな？

inotifywait は「Linuxカーネルが持っているファイル変更通知機能（inotify）」を、シェルから使いやすい形にしたコマンドです。実装はざっくり言うと “カーネルに監視登録して、イベントが来るまで寝る” だけです。

---

1) inotifywait はどう実装されてる？（内部の仕組み）

inotifywait 自体は inotify-tools というユーザー空間ツールの一部で、根っこは Linux の inotify API を呼んでいます。

典型的な流れ（概念）は以下です：

1. inotify インスタンスを作る
   • inotify_init1()（または inotify_init()）を呼ぶ
   • これは「イベント受信用のファイルディスクリプタ（fd）」を返します
2. 監視したいパスを登録する
   • inotify_add_watch(fd, path, mask)
   • mask に IN_MODIFY, IN_CLOSE_WRITE, IN_CREATE, IN_MOVED_TO など監視したいイベント種別を指定
3. イベントが来るまでブロックして待つ
   • read(fd, buf, ...) を呼ぶ
   • イベントが無ければここで ブロック（スリープ） します
   • イベントが来ると read() が返って、イベント構造体（struct inotify_event）がバッファに入ってくる
4. イベントを解釈して表示し、必要なら継続監視
   • inotifywait はそれを人間が見やすい形式に整形して標準出力に出す
   • -m（monitor）を付けると終了せずに読み続ける（イベントごとに出力）

つまり、実装の核心は 「inotify の fd を read して待つ」 で、ポーリングは基本しません。

---

2) 自分でファイル監視を作るより効率いい？

結論：普通は inotify（= inotifywait の方式）の方が圧倒的に効率的です。
理由は「無駄なチェックをしない」からです。

ポーリング（自作しがちな方法）

例：1秒ごとに stat() して更新時刻を比較する、など

• 長所：どのOSでも比較的作りやすい・単純
• 短所：
  • 変更が無くても常に定期的に stat() 等のシステムコールが走る
  • 監視対象が増えるほど負荷が比例して増える
  • チェック間隔次第で「検知が遅い」or「負荷が高い」のトレードオフ

inotify（inotifywait）

• 長所：
  • 変更が起きた時だけユーザー空間に通知される
  • 待っている間はブロックされて寝るので、CPU負荷がほぼゼロに近い
  • 監視対象が多くても「変更が少ない」なら非常に軽い
• 短所（重要）：
  • ローカルのLinux上のファイルに強い一方、NFSなどネットワークFSでは期待通りに動かないことがある
  • 監視は「inodeに対する変更」や「ディレクトリエントリの変更」なので、運用次第で取りこぼしやすいイベントがある（後述）
  • OS依存（Linux固有）

---

3) 実務で気をつけるポイント（YAML監視でよくある罠）

「ファイルを更新」する方法によって、欲しいイベントが変わります。

罠1：エディタ/プログラムが “原子置換” する

多くのツールは安全のために

1) 一時ファイルに書く
2) rename() で元ファイルを置き換える（原子的）

という手順を取ります。

この場合、元ファイルへの IN_MODIFY が来ないことがあります。代わりにディレクトリ側で

• IN_MOVED_TO（新しいファイルが移動してきた）
• IN_CREATE（新規作成された）
• IN_DELETE / IN_MOVED_FROM（古い方が消えた/移動した）

みたいなイベントになります。

対策：しばしば「ファイル1個」より 親ディレクトリを監視し、 create/moved_to/close_write などを見る方が堅いです。

罠2：どのイベントを見るべき？

「書き込み途中で反応したくない」なら IN_CLOSE_WRITE（書き込みでcloseされた）を見るのが定番です。
IN_MODIFY だと書き込み途中に何度も来る可能性があります。

罠3：取りこぼし（キューオーバーフロー）

イベントが短時間に大量発生するとキューが溢れて IN_Q_OVERFLOW が出ることがあります。
その場合は「確実性が落ちた」ので、再スキャン（ファイルを読み直して状態復元）が必要になります。

---

4) まとめ：inotifywait を使う価値

• 待機中のCPU負荷が極小（ポーリングより効率的）
• 変更が来た瞬間に起きるので レイテンシが小さい
• ただし「modifyを見る」だけだと運用によっては外すので、監視イベントや監視対象（ファイル vs ディレクトリ）の設計が大事

---

inbox_watcher.sh が実際にどのイベント（modify/close_write/moved_to など）で待っているか、監視対象がファイル単体かディレクトリかで堅牢性がかなり変わります。スクリプトの該当部分（inotifywait行）を貼ってくれれば、「この書き方だと取りこぼす可能性がある/ない」まで具体的に指摘できます。

This site is open source. Improve this page.