Repository navigation
dune ps misses the CLI shim and task wrappers; no way to stop what it lists #46
Description
On a machine with ~45 stale dune processes, dune ps listed 19 as "port unknown — is lsof installed?" and missed the one server that was actually serving, started through the dune shim as cli.ts dev.
Problems
- Matching only covers the generated
main.ts dev|serve, not the CLI run directly (cli.ts dev|serve,jsr:@dune/core@x/cli serve) ordeno task dev|servewrappers. - A server's wrapper, re-exec child and esbuild workers are listed as separate instances.
- A process that is running but not listening (hung or leftover) is reported as "port unknown".
- No way to stop what it lists.
Direction
dune psstays read-only and gets the matching/grouping/"not listening" fixes.- Stopping is a separate command,
dune stop <pid> | --port <n> | --idle | --all(SIGTERM;--forcefor SIGKILL; asks first; a target is always required). Open to naming/UX feedback.
Implemented in #37 (docs: duneorg/dune-docs#12). The longer-term design (instance registry plus hang detection) is tracked in #42.
Activity
refactor(cli): stopping moves out of `dune ps` into `dune stop`
docs(cli): dune stop replaces dune ps --stop / --idle
[-]dune ps misses the CLI shim and task wrappers, and can't tell stuck servers from healthy ones[/-][+]dune ps misses the CLI shim and task wrappers; no way to stop what it lists[/+]fix(cli): dune stop only acts on what it can verify
fix(cli): stricter "confirmed", no --allow-sys, honest permission errors
docs(cli): what 'confirmed' means for dune stop; permissions
feat(cli): dune ps finds the CLI and task wrappers and says "not list…
feat(cli): dune ps probes health and reads the instance registry (#53)
docs(cli): dune ps finds the dune CLI and task wrappers, reports "not…