fix: prevent gateway double-spawn when process undetected by listProcesses()#293
Closed
amit183239 wants to merge 1 commit intocloudflare:mainfrom
Closed
fix: prevent gateway double-spawn when process undetected by listProcesses()#293amit183239 wants to merge 1 commit intocloudflare:mainfrom
amit183239 wants to merge 1 commit intocloudflare:mainfrom
Conversation
…esses() Fixes cloudflare#289 Two changes to avoid the "gateway already running / port in use" error that occurs when the container already has a running gateway that findExistingMoltbotProcess() fails to detect: 1. Broaden command matching to also check for `/usr/local/bin/start-openclaw.sh` (full path), so invocations via `bash /usr/local/bin/start-openclaw.sh` are recognised. 2. Add a TCP port pre-check in ensureMoltbotGateway() before spawning. If port 18789 is already listening, the gateway is up regardless of what listProcesses() returned, so we skip the spawn entirely.
andreasjansson
pushed a commit
to andreasjansson/moltworker
that referenced
this pull request
Mar 25, 2026
Fixes cloudflare#289 When the gateway is already running but listProcesses() fails to detect it (e.g. the command string appears in an unexpected form), a second spawn attempt causes 'port already in use' errors. Add a TCP port probe (nc -z) as a safety net before spawning. If port 18789 is already listening, the gateway is definitively running — return null to signal 'gateway is up' without a process handle. All callers only need the gateway to be reachable; none use the returned Process object. This avoids the bug in cloudflare#293 where the port-check fallback tried to return an arbitrary running process from listProcesses(), which could be a completely unrelated process (rclone sync, shell session, etc.), and fell through to spawn on no match — defeating the safety net.
This was referenced Mar 25, 2026
andreasjansson
pushed a commit
that referenced
this pull request
Mar 25, 2026
Fixes #289 When the gateway is already running but listProcesses() fails to detect it (e.g. the command string appears in an unexpected form), a second spawn attempt causes 'port already in use' errors. Add a TCP port probe (nc -z) as a safety net before spawning. If port 18789 is already listening, the gateway is definitively running — return null to signal 'gateway is up' without a process handle. All callers only need the gateway to be reachable; none use the returned Process object. This avoids the bug in #293 where the port-check fallback tried to return an arbitrary running process from listProcesses(), which could be a completely unrelated process (rclone sync, shell session, etc.), and fell through to spawn on no match — defeating the safety net.
andreasjansson
pushed a commit
that referenced
this pull request
Mar 27, 2026
Fixes #289 When the gateway is already running but listProcesses() fails to detect it (e.g. the command string appears in an unexpected form), a second spawn attempt causes 'port already in use' errors. Add a TCP port probe (nc -z) as a safety net before spawning. If port 18789 is already listening, the gateway is definitively running — return null to signal 'gateway is up' without a process handle. All callers only need the gateway to be reachable; none use the returned Process object. This avoids the bug in #293 where the port-check fallback tried to return an arbitrary running process from listProcesses(), which could be a completely unrelated process (rclone sync, shell session, etc.), and fell through to spawn on no match — defeating the safety net.
andreasjansson
pushed a commit
that referenced
this pull request
Mar 27, 2026
Fixes #289 When the gateway is already running but listProcesses() fails to detect it (e.g. the command string appears in an unexpected form), a second spawn attempt causes 'port already in use' errors. Add a TCP port probe (nc -z) as a safety net before spawning. If port 18789 is already listening, the gateway is definitively running — return null to signal 'gateway is up' without a process handle. All callers only need the gateway to be reachable; none use the returned Process object. This avoids the bug in #293 where the port-check fallback tried to return an arbitrary running process from listProcesses(), which could be a completely unrelated process (rclone sync, shell session, etc.), and fell through to spawn on no match — defeating the safety net.
andreasjansson
pushed a commit
that referenced
this pull request
Mar 27, 2026
Fixes #289 When the gateway is already running but listProcesses() fails to detect it (e.g. the command string appears in an unexpected form), a second spawn attempt causes 'port already in use' errors. Add a TCP port probe (nc -z) as a safety net before spawning. If port 18789 is already listening, the gateway is definitively running — return null to signal 'gateway is up' without a process handle. All callers only need the gateway to be reachable; none use the returned Process object. This avoids the bug in #293 where the port-check fallback tried to return an arbitrary running process from listProcesses(), which could be a completely unrelated process (rclone sync, shell session, etc.), and fell through to spawn on no match — defeating the safety net.
andreasjansson
pushed a commit
that referenced
this pull request
Mar 27, 2026
Fixes #289 When the gateway is already running but listProcesses() fails to detect it (e.g. the command string appears in an unexpected form), a second spawn attempt causes 'port already in use' errors. Add a TCP port probe (nc -z) as a safety net before spawning. If port 18789 is already listening, the gateway is definitively running — return null to signal 'gateway is up' without a process handle. All callers only need the gateway to be reachable; none use the returned Process object. This avoids the bug in #293 where the port-check fallback tried to return an arbitrary running process from listProcesses(), which could be a completely unrelated process (rclone sync, shell session, etc.), and fell through to spawn on no match — defeating the safety net.
Member
|
Superseded by PRs #336 and #337 (both merged Mar 27-28), which implemented the same port probe safety net plus additional fixes: reliable process kill via |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #289
Summary
findExistingMoltbotProcess()matches command strings likestart-openclaw.shandopenclaw gateway, but the sandbox process list may expose the process asbash /usr/local/bin/start-openclaw.sh(full path with shell prefix), which the existing checks missensureMoltbotGateway()spawns a second instance which immediately fails with:gateway already running (pid N); lock timeout after 5000msandPort 18789 is already in useChanges
Broader command matching — also match
/usr/local/bin/start-openclaw.sh(full path) so bash-invoked scripts are detected correctlyTCP port pre-check before spawning — before starting a new process, probe port
18789via TCP. If it's already listening, the gateway is running regardless of whatlistProcesses()returned, so skip the spawn entirely. Acts as a safety net against any future process-detection gaps.