#35147 acpmux: a SIGTERM stop names its sender

Leo, 2026-11-04: "i feel like the restarted after nightly update does too many layout shifts/flicker renderings and takes too long to reconnect acpmux or whatever". Data: manaflow-ai/cmuxterm-hq#6338 (comments 6597127823 and 6626332314), bench in #34697.

After an update relaunch on macOS the old acpmux daemon sometimes logs stopping: SIGTERM (a restart handoff) about 1.1 s after the app quit and about 5 s before the new app starts. Its agent host is lost with it, so the next daemon resumes the streaming turn on a fresh agent. Nothing in the log says who sent the signal. The app, the bench and acpmux itself have no code that sends SIGTERM to the daemon on that path. The daemon and its hosts each lead their own session, so a process-group kill can't explain it.

This PR makes the daemon say who sent it. A SA_SIGINFO action next to tokio's own records si_pid; both go through signal-hook-registry, which runs every action registered for the signal. The action does only an atomic store, so it is async-signal-safe. The stop line then reads stopping: SIGTERM from pid N (command), parent M (command) (a restart handoff). A fleet bench run at this head (relaunch-reconnect:warm+update:4) is collecting the sender for the fix that follows.

Test

• Red/green: cargo test -p acpmux --test daemon_lifecycle a_sigterm_stop_names_its_sender fails at the red commit (no sender on the stop line) and passes at the head.
• Unit: daemon::term_sender::tests (ps row parsing; this process is described with its command).

Observed / Not run

• See the run results below.

Performance

metric	before	after	delta	harness
work per SIGTERM	0	1 atomic store + 2 ps reads on the stop path	stop path only	code read; no hot path

Risk

Low: only the daemon's SIGTERM stop path changes, plus one extra signal action. If the action can't be registered, the daemon logs a warning and stops as before.

Changelog

none

Agent session: agent session

🤖 Generated with Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Names the SIGTERM sender on the acpmux daemon's stop line so an unexplained SIGTERM after a NIGHTLY update relaunch on macOS can be traced.

The daemon now logs stopping: SIGTERM from pid N (command), parent M (command) instead of the plain stopping: SIGTERM (a restart handoff). A SA_SIGINFO action records the sender's pid via signal-hook-registry; the action only does an atomic store, so it is async-signal-safe. It is registered only after tokio's own stream exists, so SIGTERM's default action is never replaced. The sender's command and parent are read from ps at stop time. The lookup is a reviewed process-scan exception: it reads one kernel-named pid once on the stop path and enumerates nothing. If the action can't be registered, the daemon warns and stops as before.

Low risk: only the SIGTERM stop path changes, plus one extra signal action.