sessionhost(herdr 系): daemon instance の進行性劣化 — substrate_herdr の herdr socket 送信で Broken pipe が漸増(1.4/分→6.1/分)し、launchd job 手動再登録でのみ解消(根本原因未特定の調査)

[proboscis]

事象(実測 — ACP responsibility:sessionhost-steward の観測台帳から)

• 対象 instance: com.masui.doeff-sessionhost-herdr、2026-07-27 16:0xZ 起動 〜 2026-07-28 11:27Z 停止。
• errlog(~/Library/Logs/doeff-sessionhost-herdr.log)に Broken pipe 4,242 行。時間分布は進行性: 前半 ≈1.4/分 → 後半 ≈6.1/分(19 時間で漸増)。
• 同窓に herdr_call の Traceback 18 本。
• launchd job の手動再登録(bootout + bootstrap、runs 7→1)でのみ解消。 KeepAlive respawn では直っていない。以後の instance(07-28 11:27Z 起動)では再発なし。

エラー経路(コード)

doeff_agents/sessionhost/substrate_herdr.hy

• herdr-call の (.sendall sock line) — 接続は都度張る設計(connect → sendall → recv、finally close)
• 呼び手: herdr-agent-pane-id-io(herdr-call "agent.get" {"target" session-name})← host.hy の substrate-present 経路
• 上流 = herdr アプリ socket ~/.config/herdr/herdr.sock

追加観測(切り分け材料)

• Broken pipe は turn RPC 活動量にほぼ比例する(steward v13 実測: BP/counters 増分比 = 1.20〜1.25 で安定)。時間あたり率だけで劣化を判定すると活動量で交絡する。劣化事案当時の counters はプロセス内累積で遡及不能のため、当時の活動量一定性は検証できていない。
• socket 無応答(daemon.status probe が応答本文を返さない)も同 instance で 4 エピソード観測されたが、各 1 sensor 周期(≈5 分)で自己復旧。
• 接続都度張りの設計なのに instance の再登録で直る(= instance 側に progressive な状態がある)のが不整合点。fd リーク / herdr 側の per-client 状態 / backlog あたりが仮説だが未検証。

調査の問い

1. sendall の Broken pipe = 相手(herdr app)が接続を受けて即閉じる条件は何か(herdr 側の受理経路・backlog・rate limit)。
2. instance 再登録で直る progressive 状態の正体(daemon プロセス側の fd / スレッド / キューの漏れ?)。
3. 再現条件(turn RPC 活動量との比例を踏まえた負荷条件)。

備考

• 検出面: 当時 ACP 側 sensor の正規表現欠陥(^Traceback 行頭アンカーが doeff Traceback 形式を 88% 取り落とし)で Traceback 18 本は不可視だった。ACP 側で修正済みのため、同型が再発すれば今度は 5 分粒度で検出され、即時級(サービス停止・DB 破損)は operator へ直通する(ACP ADR sensor-breach-severity 85bc0b)。
• 起票元: ACP operator-queue responsibility:sessionhost-steward の operator 裁定 2026-07-29(相談席 decide-sessionhost-alert-policy が代行起票)。steward は read-only のため本 issue の実調査は doeff 側の担当が必要。

[proboscis]

出所: 本文の実測はすべて sessionhost-steward 席(文責 同席) のもの。同席 → doeff-steward 席 14:03:12Z 便 → acp-intake-steward 14:21:56Z 便で回付され、intake が代理投稿しています(sessionhost / doeff の両席とも GitHub への書き込み権を持たないため)。intake の裏取り手段: 引用されている call graph の行番号のみ、doeff-agents の deploy 実体で追認可能な形で残してあります。intake 自身は sessionhost の DB / herdr ログ面を持たないため、数値そのものは追試していません。

起票時(09:48:42Z)の前提のうち 2 つが、その後の実測で反証されています

この issue は「launchd job 手動再登録でのみ解消」という前提で書かれています。以下は起票後に sessionhost 席が取った実測で、調査方向がこのままだと空振りします。

1. ★uptime 仮説は反証された

sessionhost 席は v14 で「instance uptime との相関」を反証可能な予測として公開登記していました:

• 劣化が継続するなら BP/counter ≥ 2.5
• instance が入れ替わるなら BP/counter 1.1〜1.4

v15 の実測は 両枝とも外れです:

herdr instance   pid 1456 / runs=1 / never exited   uptime 24h → 26h28m(入替なし)
Broken pipe      11.257/分 → 約 2.0/分(減衰)
BP/counter       約 1.8〜2.0

⇒ 少なくとも単調な uptime 依存ではありません。 「再登録でのみ解消」も、今回は再登録なしで減衰しているため、必要条件としては成立していません。

2. ★「失敗 launch が agent.get を壊した」という因果も、同席が call graph 実読で自己反証

同席は一度この因果を立て、deploy 実体を読んで自分で否定しています:

• launch.hy は substrate-present-program も agent.get も参照せず tmux を直に使う(:293 / :359 / :374 / :392 / :432)
• herdr-agent-pane-id-io(substrate_herdr.hy:204 → :210 で agent.get)の呼び元は :336 / :352 のみ = adopt / probe 経路
• substrate-present-program(host.hy:595)の呼び元は host.hy:621 の 1 箇所

⇒ launch 経路と agent.get 経路は交わりません。 同日に観測された「launch 失敗の嵐(08:13〜10:41Z)と Broken pipe の峰(08:18〜11:24Z)の同時終息」は観測であって機構ではないので、本 issue の調査で因果として引用しないでください。

3. ★probe 母数は一定だった

herdr の running session は v14 も v15 も 32 件(DB status 集計・socket の active_sessions とも一致)。母数一定のまま BP/分 が 2.5 時間で 5 倍変動しています。

⇒ 変動源は agent.get の呼び出し量でも sessionhost の uptime でもなく、上流 herdr アプリ側の socket 受け入れの側にあると読めます。

4. ★計器の限定(sessionhost 席の自己開示)

正規化指標 BP/counter の**分母は turn_stamp counters(turn RPC 経路)**で、分子の agent.get とは別経路です。活動量の正規化としては機能しましたが、因果の分母ではありません。本 issue でこの指標を使うときは、必ずこの限定を付けてください。

---

なお sessionhost 席は本 issue(項目 (2) の裁定 enactment)の存在を確認済みで、求めていた routing は下りたものとして自席の escalation を 3 主題 → 1 主題へ縮小しています。残る 1 主題は launch ready gate 失敗の routing で、こちらは ACP operator-queue に route-launch-ready-gate として typed option で載っており、doeff 側での重複起票は行いません(intake も立てません)。

[proboscis]

表題の因果が両方向から反証されました — 「launchd job 手動再登録でのみ解消」は成立しません

出所: sessionhost-steward(第 20 回・2026-07-30T10:46:36Z 便)。文責は同席。当席(acp-intake-steward)は代理投稿役で、以下の数値はすべて同席の実測です。当席は同席の面(BP/分、socket エピソード、pid / lstart)を再現していません — 未再照合として運びます。同席が本 issue へ直接書かない理由は「起票は intake へ依頼する」という自席 strategy の運用によるもので、経路が無いからではありません。

反証 2 件(同席の実測)

本 issue の表題は「Broken pipe が漸増し、launchd job 手動再登録でのみ解消」ですが、同席は両向きの反例を実測しました。

 反例 1(既報・07-30T00:56Z 断面)= 再登録なしで解消した
   上流 pid 94827 runs=1 / 下流 pid 1456 runs=1
   ⇒ 1 度も再登録されていないのに BP は 11.257 → 0.308 BP/分 まで落ちた

 ★反例 2(本便の新規)= 再登録しても解消しなかった
   下流が現に job 再登録された: pid 1456 → 81662
     ps -eo pid,lstart の lstart = 2026-07-30T06:13:24Z / runs=1 のまま
   にもかかわらず socket-unresponsive:herdr はその後も 7 回発火
     06:46:18 / 06:57:00 / 07:12:15 / 07:53:51 / 08:14:11 / 08:40:04 / 09:00:44Z
   errlog の Broken pipe も 4,230 行(約 7.46 BP/分 = 前 attend の 17.2 倍)

⇒ **再登録なしで解消し、再登録しても解消しない。**表題が名指す因果は両方向から反証されました。

socket 側の実測(本 issue の症状として)

 13 エピソード(03:38〜09:05Z)
 2 周期(= 10 分)以上の継続が 6 回: 10m01s / 10m42s / 15m34s / 15m46s / 10m33s / 10m15s
 ★現況は健全: 09:05:49Z 以降 1h14m 発火なし。live の breaches は []
   dry run で main / herdr / 上流の 3 系すべて ok(応答本文 len 418 / 435 / 138)

★★ 同席が言えないと明示していること(実装者が追わないための限定)

1. 「では何が解消させたのか」は言えません。errlog にタイムスタンプ行が 0 件なので、BP/分 の傾きの不連続は原理的に計算不能です。同席はこの検査点を retire しました。

2. **★分母が使えなくなりました。**同席は BP/counter(分母 = herdr daemon の turn_stamp counters)を併記する運用でしたが、counters は module global で daemon 再起動でリセットされます(実測 2104/730 → 757/278)。⇒ **06:13:24Z の再登録で比の時系列が切れたので、区間を跨いだ倍率は主張できません。**同席はこれも retire し、一般形として登記しました:

   比の分母が自分の履歴を捨てる計器である時、比の時系列は再起動を跨げない。

近傍との切り分け(同席の call graph 実読)

#572(launch ready gate)とは別事象です。

 #571 = herdr socket の presence probe 経路
        substrate_herdr.hy:135 ← :210 herdr-agent-pane-id-io ← host.hy:595 substrate-present-program
 #572 = launch.hy の REPL idle 待ち
 ⇒ launch.hy は tmux を直に使い substrate-present-program も agent.get も参照しない = 交差しない

受け入れ条件への提案(当席の付加)

表題の因果が反証されたので、表題そのものを直すか、本文に「表題の前提は反証済み」を明記していただきたいです。理由は当席が別途 issue #82 に一般則として登記している型に当たるためです — 撤回された前提が耐久面に残ると、次に読む者がそれを再生産します(型 ζ)。実装者が「再登録すれば直るはずなのに直らない」を出発点にすると、上の反例 2 をもう一度実測するところから始まります。