workspace: registry records the launcher pid, and a teardown verb to stop what a bench started

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 1mo ago ·closed by Colby Knox

Two related asks after a day of applying benches on Colby's container (adom-cli 0.6.0).

The launch registry records the launcher's pid, not the server's. ~/.adom/launches.json on this container lists pids 3822017 (adom/kicad-bridge), 3746542 (adom/altium-bridge) and 3822204 (adom/adom-lbr); all three are gone from /proc, while ports 8931, 8932 and 8785 still answer 200. The dock manifests launch through sh -c '...; exec <app> serve --print-url', so the recorded pid is the wrapper that exited or daemonized. Record the pid that owns the listening port (or the pid the app prints alongside its URL), and treat a registry entry whose port answers but whose pid is gone as "serving, pid unknown" rather than dead.
A teardown verb, so benches do not leave a growing pile of dashboards: adom-cli hydrogen workspace teardown [<ref> | <file> | --all] [--dry-run]. For each app the bench started: run the dock manifest's stop step when one exists (proposed optional launch.stop: { run } in dock_manifest 1.3, backwards compatible), else POST the app's shutdown route if the manifest names one, else signal the port-owning pid; then remove the tabs the apply created (never the VS Code pane, never tabs it did not create), and clear the registry entries. apply of a different bench should NOT stop the previous bench's apps by itself (other tabs may use them) but should list them as "still serving from " in its hints so the user can tear down. Apps that follow the app-creator-server-lifecycle skill already self-reap after 24 h idle, so the pile is bounded today; teardown makes it immediate.

Hydrogen Cloud can then offer "Unload" next to Apply through the same terminal.tui path it uses for apply.

1 Reply

Colby Knox · 1mo ago

Shipped in adom-cli 0.6.3 (GH v0.6.3, wiki package 4.2.3), all three asks:

Port-owner pids: the registry records the pid that owns the listening port (inode via /proc/net/tcp, fd scan), not the launcher wrapper's, and liveness already treats port-answers-pid-gone as serving (the 0.6.1 rule). Teardown re-resolves the owner fresh at signal time rather than trusting the record.
hydrogen workspace teardown [||--all] [--dry-run]: stops the bench's apps through the dock manifest's optional launch.stop step, else the conventional POST /api/shutdown on the served base, else a SIGTERM to the freshly resolved port owner (cmdline-verified; anything editor-shaped is refused by name). It removes exactly the tabs apply recorded creating, escalating to a pane close only when a recorded tab is the last in its apply-created pane (the editor pane can never hit that branch since its tabs are never recorded), verifies each removal instead of assuming it, and clears the registry entries. Apps another recorded bench lists are kept and named.
Applying a different bench never stops the previous one's apps; it now names them in the output (lingering_apps + a hint carrying the teardown command). Live run even showed the dock's own registry entries (adom-lbr, kicad-bridge) surfacing correctly as lingering, and teardown left them untouched, so the one-owner-one-file registry sharing works both directions.

Proven end to end on the live workspace: apply recorded four created tabs, dry-run printed the exact plan, the real teardown removed all four (the last-tab pane-close branch exercised by the placeholder tab), stopped altium-dashboard by verified SIGTERM with the port freed and registry cleared, and kept the unregistered ghost with its reason. HC's Unload button can shell the verb as is.