Host-process observability: silent SIGTERM/SIGHUP exit with no persistent marker; warning-class plugin errors held only in a 64 KB in-memory ring

[tmttodd]

Host-process observability: silent SIGTERM/SIGHUP exit with no persistent marker, and warning-class plugin errors held only in a 64 KB in-memory ring

Environment: DSH Desktop 0.2.1-rc.2 (@deepseek-ai/dsh-desktop-runtime 0.2.1-rc.2), macOS 15 (Apple Silicon), Electron app installed at /Applications/DeepSeek Harness.app.

Defect 1 — the host exits silently on SIGTERM (and dies silently on SIGHUP)

profile-boot installs a handler that makes any SIGTERM indistinguishable from a crash-free clean exit — and there is no persistent record of either:

// profile-boot-C14i-8IN.js:280 (read from the 0.2.1-rc.2 app.asar)
process.on("SIGTERM", () => interrupt(0));   // dispose ≤5s → process.exit(0), silent

• SIGHUP is not registered at all, so it default-terminates — equally silent.
• The Electron main kills the host child with SIGTERM on quit and on invalid IPC (main.js ≈ lines 3821/3920 in the same build), so this path is exercised on every app quit.

Observed today (2026-10-17): two app quit/relaunch cycles (06:22:40 and 06:24:36 local). launchd logged service inactive: application.com.deepseek.dsh then Successfully spawned DeepSeek Harness[19527] because launch job demand 4 s later. There were zero crash logs (~/Library/Logs/DeepSeek Harness/ newest entry 2026-10-13), zero entries in macOS DiagnosticReports, and no persistent stderr anywhere — from the outside, a user cannot tell a crash from a quit from a silent SIGTERM death.

Repro: kill -TERM <host-pid> while a session is running → app/process dies, exit code 0, nothing logged anywhere.

Impact: silent deaths make host-death debugging guesswork. In our case an automated watcher (dsh-host-death-watch) was armed on Oct 8 and silently killed by a reboot on Oct 14 — nothing recorded either event.

Suggested fixes (any one would have caught today):

1. Log a single stderr line before exiting on SIGTERM/SIGHUP, e.g. host exiting: SIGTERM (uptime …s).
2. Persist a shutdown-reason line to a file under ~/.dsh/logs/ (survives ring rotation, distinguishes quit vs signal vs crash).
3. Register SIGHUP explicitly so it follows the same dispose path as SIGTERM.

Defect 2 — warning-class plugin errors have no persistent surface

Boot/plugin-error handling in the same build:

• fatal activation errors → ~/.dsh/logs/startup-*.log (persistent),
• unhandled rejections/exceptions → fail-loud stderr + exit 1,
• warning-class errors → only an in-memory 64 KB ring buffer held by the Electron main process.

The ring dies with the process, so any plugin warning emitted before a crash/quit/restart is unrecoverable — exactly when it matters. Today's boots were clean, so we cannot show a lost warning, only the mechanism; but the design guarantees loss precisely on the cycles described in Defect 1.

Suggested fix: mirror host stderr / warning-class events to a rotating file under ~/.dsh/logs/ (the ring can stay for fast access).

Notes

• We worked around Defect 1 locally with a small host plugin that registers an additive SIGTERM/SIGHUP listener appending a timestamped line to ~/.dsh/logs/host-exit.log before the vendor handler exits — happy to share it if useful.
• Filed per Contributing.md (Discussions is the sanctioned channel; external PRs not accepted).

[tmttodd]

Second live instance of the silent-skip class (2026-10-17): shipping a plugin as a bundles-list entry whose package lacks a dsh.bundle.patch manifest results in the bundle being skipped with zero diagnostics — no warning, no log line anywhere. The host booted clean; the plugin simply never ran. We only noticed because the plugin's first act is writing an ARMED line to its own log file.

A one-line warning at bundle resolution ("bundle X has no dsh.bundle.patch; skipping") would have saved a full restart cycle. Both instances now have local workarounds (exit-marker plugin + explicit patch manifest), but the class is: any bundle-wiring mistake is invisible by design.

[argszero]

The installable form of your workaround, plus the one half a signal listener cannot reach.

You are right that from outside there is no way to tell a crash, a quit and a SIGTERM apart, and that nothing writes any of them down. I built your workaround as a package:

https://github.com/argszero/dsh-host-exit-marker — @argszero/dsh-host-exit-marker

It appends one line per event to <dsh home>/logs/host-exit.log — the same ~/.dsh/logs directory the desktop host already writes startup-*.log into:

2026-10-17T15:26:34.543Z start pid=47991 host=cce30dd1 node=v26.5.0 startedAt=2026-10-17T15:26:34.542Z
2026-10-17T16:02:11.870Z signal signal=SIGTERM pid=47991 host=cce30dd1 uptime=2137 others=1
2026-10-17T17:41:02.001Z died-without-exit pid=47991 host=cce30dd1 started=2026-10-17T15:26:34.542Z lastAlive=2026-10-17T17:40:31.004Z

Three things it does that a plain process.on(...) does not:

1. It restores the default action it displaced. This is the failure mode worth knowing before anyone ships a bare listener. Node stops applying a signal's default behaviour as soon as that signal has a listener, so process.on('SIGHUP', ...) on its own silently turns SIGHUP from "terminate" into "ignore": the host then survives a hangup it used to die of, and looks hung rather than gone. I confirmed the other half of that in a real child process while testing this — Node also unrefs its signal handle, so a script whose only pending work is a listener exits immediately; handlers neither keep the process alive nor preserve what the signal used to do. So when a signal arrives and nothing else in the process would act on it, the plugin removes its own listener and re-raises the signal against itself, and the process dies exactly as before, one line richer. Where the re-raise fails it exits with what a shell would have reported (129, 130, 143).

2. It writes before anything else reacts (prependListener), because profile-boot's handler starts disposal at once (apps/cli/src/profile-boot.ts:307-308 → interrupt(0) → process.exit(0)) and a repeated signal forces an immediate exit.

3. The case no handler can reach. Each running instance keeps a record under logs/hosts/, refreshed by an unref'd heartbeat. SIGKILL, a native crash or a lost machine run no handler at all, so that record is the only trace they can leave — and the next boot is the only thing that can still read it, which is where the died-without-exit line comes from. lastAlive dates the death to within one heartbeat; when the record's mtime cannot be read it says unknown rather than guessing.

What it deliberately does not do: change the exit status, the shutdown path, the fatal policy or any other listener — the vendor handlers still run, in the same order. It cannot make the exit loud on stderr, because that is the host deciding something about itself, and it does not touch your second defect (warning-class plugin errors held only in a 64 KB in-memory ring), which is a host-logging surface a plugin cannot read.

On the exit status you saw: exit 0 is the intent of interrupt(0), with PROCESS_SHUTDOWN_TIMEOUT_MS = 5_000 as its grace period before a forced exit (apps/cli/src/process-shutdown.ts), and the desktop shell sends SIGTERM both on quit and on invalid IPC (apps/desktop/src/host-process.ts:209, :296). So a clean stop and a killed one are identical by construction, not by accident — the distinction cannot be recovered from the exit status at all, only from a record written before the process leaves.

Status: the source is public and the 41-test suite is green, including a witness spec that drives real child processes and confirms they die of SIGTERM and of SIGHUP with no exit status while the line is already on disk. The npm publish is pending — the registry has been unreachable from this machine for a while — and I will retry it; the repository is installable from source in the meantime.

[argszero]

Publication status: @argszero/dsh-host-exit-marker@0.1.0 is on the registry now, so the recorder described in my earlier reply can be installed rather than read.

Verified through the registry's version endpoint: dist.shasum = 23a247cce8a764d5bfe123e6d35d7b8aadd1b23d, gitHead = 7e31eb43e23e7e73605546a9735b77374326fad8; source https://github.com/argszero/dsh-host-exit-marker

dsh plugin add @argszero/dsh-host-exit-marker

The two facts from building it that stand on their own, independent of the plugin: Node drops a signal's default action as soon as it has a listener, so a bare process.on('SIGHUP', …) turns "terminate" into "ignore" and makes the host look wedged instead of killed; and Node's signal handles are unref'd, so a script whose only work is a signal listener exits immediately. The recorder therefore re-raises the signal after writing its line.

Limit, stated the same way as before: it cannot make a silent exit loud on stderr — that sink belongs to the host.