Since the systemd-aware update fix (#82, PR #89), update install detects a daemon as systemd-managed when (a) $INVOCATION_ID is set and (b) the process cgroup leaf is a .service unit. Both conditions are inherited by every descendant of any systemd service — e.g. all processes inside a GitHub Actions runner (hosted-compute-agent.service) or any systemd-supervised container/agent.
Effect: on master CI, test/cli/update-install-restart-race.test.ts has failed on ubuntu since the PR #89 merge (run on bab7288, 2026-06-09) with:
Daemon (PID …) is managed by systemd (hosted-compute-agent.service); it will be restarted by its supervisor.
update install then skips restarting the daemon. The same would happen for real users running the CLI inside any systemd-supervised session/agent: their daemon would never be restarted after an update (or worse, systemctl restart would bounce an unrelated unit).
Fix plan: membership is not ownership — only treat the daemon as supervised when it is the unit's main process. Verify systemctl show --property=MainPID --value <unit> equals the daemon's PID (or its direct parent, covering ExecStart=/bin/sh -c … wrappers) in both detectSelfSupervisor (records the state file at daemon startup) and the legacy cgroup fallback in resolveDaemonSupervisor. When MainPID can't be read, treat as unsupervised (pre-#82 direct-restart behavior).
Known limitation (unchanged): systemctl --user units are not detected by the system manager; they fall back to direct restart. The current code's systemctl restart (without --user) couldn't restart them anyway.
Since the systemd-aware update fix (#82, PR #89),
update installdetects a daemon as systemd-managed when (a)$INVOCATION_IDis set and (b) the process cgroup leaf is a.serviceunit. Both conditions are inherited by every descendant of any systemd service — e.g. all processes inside a GitHub Actions runner (hosted-compute-agent.service) or any systemd-supervised container/agent.Effect: on master CI,
test/cli/update-install-restart-race.test.tshas failed on ubuntu since the PR #89 merge (run on bab7288, 2026-06-09) with:update installthen skips restarting the daemon. The same would happen for real users running the CLI inside any systemd-supervised session/agent: their daemon would never be restarted after an update (or worse,systemctl restartwould bounce an unrelated unit).Fix plan: membership is not ownership — only treat the daemon as supervised when it is the unit's main process. Verify
systemctl show --property=MainPID --value <unit>equals the daemon's PID (or its direct parent, coveringExecStart=/bin/sh -c …wrappers) in bothdetectSelfSupervisor(records the state file at daemon startup) and the legacy cgroup fallback inresolveDaemonSupervisor. When MainPID can't be read, treat as unsupervised (pre-#82 direct-restart behavior).Known limitation (unchanged):
systemctl --userunits are not detected by the system manager; they fall back to direct restart. The current code'ssystemctl restart(without--user) couldn't restart them anyway.