dsh-home-hosted 0.7.5 → 0.7.6

package/docs/DESIGN.md

@@ -38,7 +38,7 @@ its page.
 `onPortConflict: kill` arrived in home-hosted 0.6.0 and `persistent` in 0.6.3, and an older panel
 handed either key can refuse to *boot* from the config. The plugin used to consult the answering
 panel's version and refuse or drop them (`KILL_UNSUPPORTED`). That is gone on purpose: it pins
-`home-hosted@^0.7.19` and autostarts its own copy, so a panel older than those keys is only reachable by
+`home-hosted@^0.7.20` and autostarts its own copy, so a panel older than those keys is only reachable by
 deliberately preferring an old global install — and this is pre-1.0. Supporting older panels again means
 bringing that check back from history, not re-deriving it.
 

package/docs/PANEL.md

@@ -38,7 +38,16 @@ a `null` at all — exactly the two whose schema is `… | null` — while the p
 drift was real but latent; it is fixed because a copy of the panel's function is a fork of its
 semantics, and the next field to allow `null` would have made it reachable.
 
-Verified against a real 0.7.19 panel and its own CLI: `PATCH {port:null}` deletes the key; only `port`
+**0.7.20 is one fix, and it found a live bug here.** It teaches that a pid is not an identity: the OS
+recycles pids and a zombie still answers signal 0, so the panel's `up`/`status`/`down` now decide with
+the pid *plus* `run.json`'s `startedAt`, and `down` refuses to signal a pid it cannot prove is the
+panel. This plugin's two generated hand-over helpers had re-derived the weak predicate and escalated
+`SIGTERM`→`SIGKILL` on "the pid answers" — **measured** by running the generated script against a live
+`sleep` holding the recorded pid, and watching the stranger's own `SIGTERM` handler fire. A takeover
+could therefore kill an unrelated process. Both helpers now leave every signal to the CLI's own `down`,
+which is the only component that can prove identity; what they kept is a wait, never a signal.
+
+Verified against a real 0.7.20 panel and its own CLI: `PATCH {port:null}` deletes the key; only `port`
 and `bootstrap` have a schema that admits `null`; `_hh` is still exactly four routes; and every route,
 subcommand and flag this plugin drives is unchanged. The console **file** — `.hh/.logs/home-hosted.log`
 plus its `.1`, and the 5 MB rotation — is unchanged too, and this plugin's reader still matches

package/lib/index.js

@@ -2863,7 +2863,7 @@ import { createRequire } from "node:module";
 import fs11 from "node:fs";
 import path9 from "node:path";
 import process5 from "node:process";
-var EXPECTED_RANGE = "^0.7.19";
+var EXPECTED_RANGE = "^0.7.20";
 var MIN_SUPPORTED_VERSION = "0.7.0";
 function pinnedManifestPath() {
   try {
@@ -4229,18 +4229,27 @@ log('stopping the answering panel: ' + STOP.join(' '))
 const stopped = spawnSync(STOP[0], STOP.slice(1), { stdio: 'ignore', timeout: 90000 })
 log('down exited ' + String(stopped.status ?? stopped.error))
 
-if (alive(OLD_PID)) {
-  log('the panel is still alive; sending SIGTERM')
-  try { process.kill(OLD_PID, 'SIGTERM') } catch {}
+/**
+ * Never signal OLD_PID from here.
+ *
+ * The CLI's own 'down' is the only thing that may stop the panel, and it already escalates
+ * (SIGTERM, then SIGKILL) for a panel it can prove is alive. A pid is not an identity: the OS
+ * recycles pids, so the number in run.json may belong to an unrelated process, and this helper
+ * has no birth time to tell them apart. Signalling on "the pid answers" is how a takeover
+ * SIGTERMs a stranger \u2014 measured, before this guard existed.
+ *
+ * 'down' succeeds on both real cases, so there is usually nothing to wait for: it returns once
+ * the panel exited, and since home-hosted 0.7.20 the start below succeeds even when the recorded
+ * pid was recycled (its 'up' overwrites a record it cannot prove is live), where earlier releases
+ * refused with "already running". The wait is kept for a 'down' that did not report success, and
+ * it never signals.
+ */
+if (stopped.status !== 0 && alive(OLD_PID)) {
+  log('down did not report success and the recorded pid is still alive; waiting, and NOT signalling it \u2014 it may not be the panel any more')
   for (let i = 0; i < 40 && alive(OLD_PID); i += 1)
     await sleep(250)
-}
-
-if (alive(OLD_PID)) {
-  log('still alive; sending SIGKILL')
-  try { process.kill(OLD_PID, 'SIGKILL') } catch {}
-  for (let i = 0; i < 20 && alive(OLD_PID); i += 1)
-    await sleep(250)
+  if (alive(OLD_PID))
+    log('the recorded pid is still alive after waiting; the start below may be refused')
 }
 
 for (const step of STEPS) {
@@ -4295,22 +4304,22 @@ log('stopping the answering panel: ' + PROGRAM + ' ' + DOWN_ARGS.join(' '))
 const down = spawnSync(PROGRAM, DOWN_ARGS, { env: { ...process.env, ...ENV }, stdio: 'ignore' })
 log('down exited ' + String(down.status))
 
-for (let i = 0; i < 40 && alive(OLD_PID); i += 1)
+/**
+ * Never signal OLD_PID from here \u2014 see the same guard in the activation helper.
+ *
+ * 'down' is the only thing that may stop the panel, and it escalates for a panel it can prove is
+ * alive. This helper has no birth time, so "the pid answers" cannot tell the panel from a stranger
+ * that inherited the number; signalling on it SIGTERMs an unrelated process.
+ *
+ * A takeover of a live panel ends with the panel stopped either way: 'down' stops it, and it
+ * escalates itself when the panel ignores SIGTERM. A pid that is still alive after a successful
+ * 'down' is therefore not the panel, and the start below must not race it.
+ */
+for (let i = 0; i < 40 && down.status !== 0 && alive(OLD_PID); i += 1)
   await sleep(250)
 
-if (alive(OLD_PID)) {
-  log('still alive; sending SIGTERM')
-  try { process.kill(OLD_PID, 'SIGTERM') } catch {}
-  for (let i = 0; i < 40 && alive(OLD_PID); i += 1)
-    await sleep(250)
-}
-
-if (alive(OLD_PID)) {
-  log('still alive; sending SIGKILL')
-  try { process.kill(OLD_PID, 'SIGKILL') } catch {}
-  for (let i = 0; i < 20 && alive(OLD_PID); i += 1)
-    await sleep(250)
-}
+if (down.status !== 0 && alive(OLD_PID))
+  log('down did not report success and the recorded pid is still alive; NOT signalling it \u2014 it may not be the panel any more')
 
 log('starting ' + PROGRAM + ' ' + ARGS.join(' '))
 const result = spawnSync(PROGRAM, ARGS, { env: { ...process.env, ...ENV }, stdio: 'ignore' })
@@ -5171,7 +5180,6 @@ var HomeHostedService = class extends Service {
     const runtime = this.runtime();
     const stored = readStoredToken(this.options.stateDir);
     const enrolledOnDisk = apiTokenEnrolled(this.options.home);
-    const reachable = runtime !== null && (pidAlive(runtime.pid) || await probePanel(runtime.url));
     const answered = runtime !== null && await probePanel(runtime.url);
     let token = "unknown";
     let tokenVerified = false;
@@ -5397,6 +5405,15 @@ var HomeHostedService = class extends Service {
     }
     writeConfig(this.options.home, upsertEntry(raw, entry), this.writtenBy(), workspace);
   }
+  /**
+   * Is a panel up and watching this workspace's config?
+   *
+   * Deliberately still `pid alive OR answering`, unlike the status read: this only chooses between
+   * one write and two, and a live pid errs toward the *cautious* two-step write (add disabled, then
+   * flip autostart) for a panel too wedged to answer — whose watcher may still fire and would start
+   * a new autostart entry at once. A recycled pid therefore costs a redundant second write, which is
+   * the harmless direction; the harmful one was signalling it, which no helper here does any more.
+   */
   async panelRunning() {
     const runtime = this.runtime();
     return runtime !== null && (pidAlive(runtime.pid) || await probePanel(runtime.url));