fix(restart): skip unavailable lsof in initial scan#76364
Conversation
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Keep open: current main still warns on the initial missing-lsof stale-PID scan, and this PR is the linked candidate fix, but it is not merge-ready because proof is missing, the branch is conflicting, and the patch broadens silent handling to permission failures without enough justification. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review. So I’m closing this here because the remaining work is already tracked in the canonical issue. Review detailsBest possible solution: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review. Do we have a high-confidence way to reproduce the issue? Yes, at source level: current main can fall back to bare Is this the best way to solve the issue? No, not as submitted. Suppressing ENOENT is the right direction, but sharing the silent path with EACCES/EPERM in the initial scan may hide permission diagnostics; a narrower fix or explicit maintainer approval is safer. Security review: Security review cleared: The diff only changes restart error classification and tests; it does not touch secrets, dependencies, workflows, lockfiles, permissions, or supply-chain surfaces. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 68e06b9ea148. |
|
Heads up: this PR needs to be updated against current |
Co-authored-by: Neil <[email protected]>
4b1dfc6 to
6514273
Compare
|
Land-ready proof for
Validation:
Known proof gap: no separate Alpine Gateway build was run. The live proof covers the reporter's Debian/Ubuntu environment and the same OS-independent Node No blocking findings. This is the smallest correct owner-boundary fix, and contributor credit is preserved in the commit trailer. |
|
Merged via squash.
|
Co-authored-by: Peter Steinberger <[email protected]>
What Problem This Solves
Service-mode Gateway startup runs a stale-process scan before binding its port. On minimal Debian, Ubuntu, and Alpine-style hosts where
lsofis not installed, Node reportsENOENT; OpenClaw treated that expected absence as a warning even though startup continued normally.Fixes #76352.
Why This Change Was Made
The initial scan now skips only the exact
ENOENTmissing-command case. Permission failures (EACCES/EPERM), timeouts, unknown spawn failures, and unexpected nonzerolsofexits remain warnings because they mean an installed command or runtime path failed unexpectedly.This intentionally stays separate from post-kill port polling, where broader permanent-error classification controls retry behavior rather than operator diagnostics.
User Impact
Minimal Linux hosts can start the Gateway without a misleading missing-
lsofwarning. Real permission, timeout, and command failures remain visible for diagnosis.Evidence
ENOENTwarning; the other 56 stale-process tests passed.restart-stale-pids57,ports-lsof3).coreandcoreTestsin 3m01s.node:24-bookworm-slim: assertedlsofabsent and service mode enabled, reached/healthzin about 3.1s, and emitted no missing-lsofstale-scan warning.tbx_01kx5742mgqja5kjc423m7qyq2(golden-barnacle), stopped after proof.ENOENT, non-executable command →EACCES, and timeout →ETIMEDOUT, all with null exit status. This matches the official Node child-process contract.Co-authored-by: Neil [email protected]