Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix openclaw gateway restart fails to restart service (SIGTERM instead of SIGUSR1) [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#44507•Fetched 2026-04-08 00:45:59
View on GitHub
Comments
0
Participants
1
Timeline
11
Reactions
0
Author
hooya754hooya754
Participants
hooya754hooya754
Timeline (top)
referenced ×9cross-referenced ×2

When running openclaw gateway restart, the Gateway service stops but fails to restart. Only a manual system restart (or computer reboot) restores the service.

Error Message

2026-03-13T07:27:33.133+08:00 [gateway] signal SIGTERM received
2026-03-13T07:27:33.138+08:00 [gateway] received SIGTERM; shutting down
2026-03-13T07:27:33.229+08:00 [gmail-watcher] gmail watcher stopped
# ← No restart after this point

Root Cause

When running openclaw gateway restart, the Gateway service stops but fails to restart. Only a manual system restart (or computer reboot) restores the service.

Fix Action

Workaround

launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway

PR fix notes

PR #46868: fix: remove premature SIGTERM in launchd gateway restart (closes #44507)

Description (problem / solution / changelog)

Summary

  • Problem: openclaw gateway restart sends SIGTERM to the gateway process via cleanStaleGatewayProcessesSync before launchctl kickstart -k can manage the restart through launchd. The premature termination causes a race condition with launchd own restart mechanism, resulting in the service failing to come back up.
  • Why it matters: Users must manually run launchctl kickstart -k to recover the gateway after a restart command.
  • What changed: Removed the cleanStaleGatewayProcessesSync call from restartLaunchAgent along with the now-unused resolveLaunchAgentGatewayPort and parseGatewayPortFromProgramArguments helper functions. launchctl kickstart -k already handles stopping and restarting the service, and runDaemonRestart post-restart health check handles stale PIDs if needed.
  • What did NOT change (scope boundary): No changes to the unmanaged restart path (SIGUSR1), systemd/schtasks restart, or any other launchd lifecycle operations.

Change Type

  • Bug fix

Scope

  • Gateway / orchestration

Linked Issue/PR

  • Closes #44507

User-visible / Behavior Changes

openclaw gateway restart on macOS now correctly restarts the gateway service. The restart is handled entirely through launchctl kickstart -k, which properly manages the cycle through launchd.

Security Impact

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Steps

  1. Run openclaw gateway restart on macOS with LaunchAgent installed
  2. Observe gateway logs

Expected

  • Gateway restarts successfully via launchd

Actual (before fix)

  • Gateway receives SIGTERM and shuts down completely
  • Service does not restart

Evidence

  • Failing test/log before + passing after
  • All 23 launchd tests pass

Human Verification

  • Verified scenarios: oxlint clean, tsgo clean, all launchd tests pass (23/23)
  • Edge cases checked: kickstart -k fallback to bootstrap still works
  • What you did NOT verify: runtime end-to-end testing with actual macOS LaunchAgent

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Failure Recovery

  • How to disable/revert: revert this commit

Risks and Mitigations

None

Changed files

  • docs/.generated/config-baseline.json (modified, +1696/-108)
  • src/context-engine/registry.ts (modified, +67/-9)
  • src/daemon/launchd.ts (modified, +46/-42)

Code Example

2026-03-13T07:27:33.133+08:00 [gateway] signal SIGTERM received
2026-03-13T07:27:33.138+08:00 [gateway] received SIGTERM; shutting down
2026-03-13T07:27:33.229+08:00 [gmail-watcher] gmail watcher stopped
# ← No restart after this point

---

launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway
RAW_BUFFERClick to expand / collapse

Description

When running openclaw gateway restart, the Gateway service stops but fails to restart. Only a manual system restart (or computer reboot) restores the service.

Steps to Reproduce

  1. Run openclaw gateway restart
  2. Observe that the Gateway stops
  3. Wait - service does not automatically restart

Expected Behavior

The Gateway should restart smoothly using SIGUSR1 signal (in-process restart).

Actual Behavior

  • Gateway receives SIGTERM and shuts down completely
  • No automatic restart occurs
  • Logs show: [gateway] signal SIGTERM received instead of [gateway] signal SIGUSR1 received

Environment

  • OpenClaw: 2026.3.8
  • OS: macOS (Darwin)
  • Service: LaunchAgent (launchd)

Logs

2026-03-13T07:27:33.133+08:00 [gateway] signal SIGTERM received
2026-03-13T07:27:33.138+08:00 [gateway] received SIGTERM; shutting down
2026-03-13T07:27:33.229+08:00 [gmail-watcher] gmail watcher stopped
# ← No restart after this point

Workaround

launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway

extent analysis

Fix Plan

The fix involves modifying the openclaw gateway restart command to send a SIGUSR1 signal instead of SIGTERM, and configuring the LaunchAgent to handle this signal for in-process restart.

Steps to Fix

  • Modify the openclaw gateway restart command to send SIGUSR1:
kill -SIGUSR1 $(pgrep openclaw-gateway)
  • Update the LaunchAgent configuration to handle SIGUSR1 for in-process restart:
<key>Sockets</key>
<dict>
    <key>com.openclaw.gateway</key>
    <dict>
        <key>SIGUSR1</key>
        <true/>
    </dict>
</dict>

Add the following code to the Gateway service to handle SIGUSR1:

import signal
import sys

def restart_gateway(signum, frame):
    # Restart logic here
    print("Restarting Gateway...")

signal.signal(signal.SIGUSR1, restart_gateway)

Verification

Run openclaw gateway restart and verify that the Gateway service restarts smoothly. Check the logs for the presence of [gateway] signal SIGUSR1 received instead of [gateway] signal SIGTERM received.

Extra Tips

  • Ensure that the LaunchAgent configuration is updated correctly to handle SIGUSR1.
  • Test the openclaw gateway restart command multiple times to ensure that the Gateway service restarts reliably.
  • Consider adding error handling to the restart logic to handle any potential issues during restart.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#device allocation#model download#tokenizer error#prompt formatting#chain error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING