openclaw - ✅(Solved) Fix [Bug]: CLI: openclaw gateway status invokes systemctl --machine home@ --user locally and fails with Failed to connect to bus: Permission denied [4 pull requests, 1 participants]

Q: Expected behavior

`openclaw gateway status` should correctly detect/report the running systemd user service status when `systemctl --user status openclaw-gateway.service` works in the same session.

Maciej-Gierwatowski · 2026-04-06T15:14:55Z

[openclaw] openclaw gateway status fails to read systemd user service status because it calls systemctl --machine home@ --user ... and gets Failed to connect t… `openclaw gateway status` fails to read systemd user service status because it calls `systemctl --machine home@ --user ...` and gets `Failed to connect to bus: Permission denied` on a local host where `systemctl --user ...` works. # PR #62032: Fix: fall through to --user when sudo machine scope fails (Resolves #61959) - Repository: openclaw/openclaw - Author: Mlightsnow - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/62032 ## Description (problem / solution / changelog) Fixes #61959. `execSystemctlUser()` under sudo tried `systemctl --machine @ --user` and returned immediately even on failure. On systems where `systemd-machined` is unavailable or permissions are denied (e.g. Ubuntu 24.04 without machinectl access), this prevented the direct `systemctl --user` fallback from ever running. Now the sudo path falls through to the normal `--user` → machine fallback chain when the initial `--machine` attempt fails. Adds a test covering the sudo + permission-denied → `--user` fallback scenario. ## Changed files - `src/daemon/systemd.test.ts` (modified, +21/-0) - `src/daemon/systemd.ts` (modified, +14/-1) --- # PR #1: Clio/openclaw 61959 systemd unavailable - Repository: zfaustk/openclaw - Author: zfaustk - State: open | merged: False - Link: https://github.com/zfaustk/openclaw/pull/1 ## Description (problem / solution / changelog) ## Summary - Problem: `isSystemdUserServiceAvailable` treated `Failed to connect to bus: Permission denied` like a missing user-bus case and fell back to `systemctl --machine @ --user`. - Why it matters: permission-denied failures are not recoverable by the machine-user fallback, so the fallback adds noise and hides the real failure mode. - What changed: the daemon path now classifies permission-denied bus failures as non-fallbackable, and adds focused tests for both the classifier and the systemd availability flow. - What did NOT change (scope boundary): this PR does not change missing-user-bus handling, systemctl-missing handling, or unrelated daemon fallback paths. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor required for the fix - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #61959 - Related #61785 - [x] This PR fixes a bug or regression ## Root Cause (if applicable) - Root cause: the user-bus-unavailable classifier matched generic `Failed to connect to bus` text without carving out permission-denied failures. - Missing detection / guardrail: there was no focused test asserting that permission-denied bus errors must not trigger machine-user fallback. - Contributing context (if known): the previous stale PR lane (#61785) diverged and was replaced with this bounded daemon seam. ## Regression Test Plan (if applicable) - Coverage level that should have caught this: - [x] Unit test - [x] Seam / integration test - [ ] End-to-end test - [ ] Existing coverage already sufficient - Target test or file: `src/daemon/systemd-unavailable.test.ts`, `src/daemon/systemd.test.ts` - Scenario the test should lock in: `Failed to connect to bus: Permission denied` returns `false` from the user-bus-unavailable helper and does not retry via machine user scope. - Why this is the smallest reliable guardrail: the behavior is decided inside the daemon classifier and the immediate systemd availability seam. - Existing test that already covers this (if any): None. - If no new test is added, why not: N/A. ## User-visible / Behavior Changes - On permission-denied systemd user-bus failures, OpenClaw now stops after the direct `systemctl --user status` attempt instead of retrying with machine-user scope. ## Diagram (if applicable) ```text Before: [user bus failure: permission denied] -> classify as user bus unavailable -> retry with --machine @ --user After: [user bus failure: permission denied] -> classify as non-fallbackable -> return unavailable without retry ``` ## Security Impact (required) - 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) - If any `Yes`, explain risk + mitigation: N/A ## Repro + Verification ### Environment - OS: Linux container - Runtime/container: Node/Vitest workspace checkout - Model/provider: N/A - Integration/channel (if any): N/A - Relevant config (redacted): N/A ### Steps 1. Simulate `systemctl --user status` returning `Failed to connect to bus: Permission denied`. 2. Run `isSystemdUserServiceAvailable`. 3. Observe whether the code retries with machine-user scope. ### E

openclaw2026-04-06 15:14:55

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#61959•Fetched 2026-04-08 03:10:41

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Maciej-Gierwatowski

Participants

Maciej-Gierwatowski

Timeline (top)

cross-referenced ×4referenced ×4labeled ×2closed ×1

openclaw gateway status fails to read systemd user service status because it calls systemctl --machine home@ --user ... and gets Failed to connect to bus: Permission denied on a local host where systemctl --user ... works.

Root Cause

Fix Action

Fix / Workaround

Affected: Local CLI usage on this Ubuntu host (user ai) when running openclaw gateway status. Severity: Annoying (status reporting broken); gateway itself remains reachable (openclaw gateway probe shows reachable yes). Frequency: Always (observed consistently before and after upgrade to 2026.4.5). Consequence: Misleading status output and inability to rely on openclaw gateway status for service/runtime reporting; must use systemctl --user and/or openclaw gateway probe instead.

PR fix notes

PR #62032: Fix: fall through to --user when sudo machine scope fails (Resolves #61959)

Repository: openclaw/openclaw
Author: Mlightsnow
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/62032

Description (problem / solution / changelog)

Fixes #61959.

execSystemctlUser() under sudo tried systemctl --machine <user>@ --user and returned immediately even on failure. On systems where systemd-machined is unavailable or permissions are denied (e.g. Ubuntu 24.04 without machinectl access), this prevented the direct systemctl --user fallback from ever running.

Now the sudo path falls through to the normal --user → machine fallback chain when the initial --machine attempt fails.

Adds a test covering the sudo + permission-denied → --user fallback scenario.

Changed files

src/daemon/systemd.test.ts (modified, +21/-0)
src/daemon/systemd.ts (modified, +14/-1)

PR #1: Clio/openclaw 61959 systemd unavailable

Repository: zfaustk/openclaw
Author: zfaustk
State: open | merged: False
Link: https://github.com/zfaustk/openclaw/pull/1

Description (problem / solution / changelog)

Summary

Problem: isSystemdUserServiceAvailable treated Failed to connect to bus: Permission denied like a missing user-bus case and fell back to systemctl --machine <user>@ --user.
Why it matters: permission-denied failures are not recoverable by the machine-user fallback, so the fallback adds noise and hides the real failure mode.
What changed: the daemon path now classifies permission-denied bus failures as non-fallbackable, and adds focused tests for both the classifier and the systemd availability flow.
What did NOT change (scope boundary): this PR does not change missing-user-bus handling, systemctl-missing handling, or unrelated daemon fallback paths.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #61959
Related #61785
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: the user-bus-unavailable classifier matched generic Failed to connect to bus text without carving out permission-denied failures.
Missing detection / guardrail: there was no focused test asserting that permission-denied bus errors must not trigger machine-user fallback.
Contributing context (if known): the previous stale PR lane (#61785) diverged and was replaced with this bounded daemon seam.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/daemon/systemd-unavailable.test.ts, src/daemon/systemd.test.ts
Scenario the test should lock in: Failed to connect to bus: Permission denied returns false from the user-bus-unavailable helper and does not retry via machine user scope.
Why this is the smallest reliable guardrail: the behavior is decided inside the daemon classifier and the immediate systemd availability seam.
Existing test that already covers this (if any): None.
If no new test is added, why not: N/A.

User-visible / Behavior Changes

On permission-denied systemd user-bus failures, OpenClaw now stops after the direct systemctl --user status attempt instead of retrying with machine-user scope.

Diagram (if applicable)

Before:
[user bus failure: permission denied] -> classify as user bus unavailable -> retry with --machine <user>@ --user

After:
[user bus failure: permission denied] -> classify as non-fallbackable -> return unavailable without retry

Security Impact (required)

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)
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: Linux container
Runtime/container: Node/Vitest workspace checkout
Model/provider: N/A
Integration/channel (if any): N/A
Relevant config (redacted): N/A

Steps

Simulate systemctl --user status returning Failed to connect to bus: Permission denied.
Run isSystemdUserServiceAvailable.
Observe whether the code retries with machine-user scope.

Expected

The permission-denied error is not treated as missing user-bus state.
No --machine <user>@ --user retry happens.

Actual

Before this patch, the error could trigger the fallback path.
After this patch, the helper returns false and the retry is skipped.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios: focused Vitest run for src/daemon/systemd.test.ts and src/daemon/systemd-unavailable.test.ts; compare diff matches the intended three-file seam.
Edge cases checked: generic missing-user-bus matching remains intact; permission-denied path no longer classifies as missing user bus.
What you did not verify: full repository CI matrix on the fork branch.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: another systemd stderr variant that includes both bus text and permission wording may still need explicit classification.
- Mitigation: the new tests lock the exact reported failure mode from #61959 and keep the classifier seam easy to extend.

Changed files

src/daemon/systemd-unavailable.test.ts (modified, +9/-0)
src/daemon/systemd-unavailable.ts (modified, +3/-0)
src/daemon/systemd.test.ts (modified, +16/-0)

PR #62037: Clio/openclaw 61959 systemd unavailable

Repository: openclaw/openclaw
Author: zfaustk
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/62037

Description (problem / solution / changelog)

Summary

Problem: isSystemdUserServiceAvailable treated Failed to connect to bus: Permission denied like a missing user-bus case and fell back to systemctl --machine <user>@ --user.
Why it matters: permission-denied failures are not recoverable by the machine-user fallback, so the fallback adds noise and hides the real failure mode.
What changed: the daemon path now classifies permission-denied bus failures as non-fallbackable, and adds focused tests for both the classifier and the systemd availability flow.
What did NOT change (scope boundary): this PR does not change missing-user-bus handling, systemctl-missing handling, or unrelated daemon fallback paths.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #61959
Related #61785
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: the user-bus-unavailable classifier matched generic Failed to connect to bus text without carving out permission-denied failures.
Missing detection / guardrail: there was no focused test asserting that permission-denied bus errors must not trigger machine-user fallback.
Contributing context (if known): the previous stale PR lane (#61785) diverged and was replaced with this bounded daemon seam.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/daemon/systemd-unavailable.test.ts, src/daemon/systemd.test.ts
Scenario the test should lock in: Failed to connect to bus: Permission denied returns false from the user-bus-unavailable helper and does not retry via machine user scope.
Why this is the smallest reliable guardrail: the behavior is decided inside the daemon classifier and the immediate systemd availability seam.
Existing test that already covers this (if any): None.
If no new test is added, why not: N/A.

User-visible / Behavior Changes

On permission-denied systemd user-bus failures, OpenClaw now stops after the direct systemctl --user status attempt instead of retrying with machine-user scope.

Diagram (if applicable)

Before:
[user bus failure: permission denied] -> classify as user bus unavailable -> retry with --machine <user>@ --user

After:
[user bus failure: permission denied] -> classify as non-fallbackable -> return unavailable without retry

Security Impact (required)

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)
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: Linux container
Runtime/container: Node/Vitest workspace checkout
Model/provider: N/A
Integration/channel (if any): N/A
Relevant config (redacted): N/A

Steps

Simulate systemctl --user status returning Failed to connect to bus: Permission denied.
Run isSystemdUserServiceAvailable.
Observe whether the code retries with machine-user scope.

Expected

The permission-denied error is not treated as missing user-bus state.
No --machine <user>@ --user retry happens.

Actual

Before this patch, the error could trigger the fallback path.
After this patch, the helper returns false and the retry is skipped.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios: focused Vitest run for src/daemon/systemd.test.ts and src/daemon/systemd-unavailable.test.ts; compare diff matches the intended three-file seam.
Edge cases checked: generic missing-user-bus matching remains intact; permission-denied path no longer classifies as missing user bus.
What you did not verify: full repository CI matrix on the fork branch.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: another systemd stderr variant that includes both bus text and permission wording may still need explicit classification.
- Mitigation: the new tests lock the exact reported failure mode from #61959 and keep the classifier seam easy to extend.

Changed files

src/daemon/systemd-unavailable.test.ts (modified, +9/-0)
src/daemon/systemd-unavailable.ts (modified, +3/-0)
src/daemon/systemd.test.ts (modified, +16/-0)

PR #62337: fix(daemon): skip machine-scope fallback on permission-denied bus errors

Repository: openclaw/openclaw
Author: Aftabbs
State: closed | merged: True
Link: https://github.com/openclaw/openclaw/pull/62337

Description (problem / solution / changelog)

Summary

Fixes #61959

When openclaw gateway status is invoked locally (not under sudo), systemctl --user status fails with:

Failed to connect to bus: Permission denied

Because isSystemdUserBusUnavailableDetail matches this message broadly, shouldFallbackToMachineUserScope returns true and the code retries with --machine home@ --user (where home is the system hostname, not a username). This produces the confusing error seen in the issue.

Root cause

Permission denied means the bus socket exists but the current process cannot connect to it. Retrying with --machine user@ targets the same bus infrastructure and will fail identically. The fallback only makes sense when the bus is genuinely absent (e.g. XDG_RUNTIME_DIR / DBUS_SESSION_BUS_ADDRESS not set).

Changes

shouldFallbackToMachineUserScope: returns false when the error contains "permission denied", even if it also matches the broader "failed to connect to bus" pattern.
execSystemctlUser sudo path: previously returned the machine-scope result unconditionally (success or failure). Now tries machine scope first, and if it fails, falls through to a direct --user attempt. This gives a meaningful result in environments where machine scope is unavailable but a user session bus is accessible.

Tests added

"does not fall back to machine scope when --user fails with permission denied" — asserts only one execFile call is made.
"falls back to direct --user when machine scope fails under sudo" — asserts the two-step retry works correctly.

Changed files

CHANGELOG.md (modified, +1/-0)
src/daemon/systemd.test.ts (modified, +34/-0)
src/daemon/systemd.ts (modified, +9/-2)

Code Example

openclaw gateway status (excerpt):

Runtime: unknown (systemctl --user unavailable: Failed to connect to bus: Permission denied
Failed to read server status: Transport endpoint is not connected)


`systemctl --user status openclaw-gateway.service --no-pager` (excerpt):

Active: active (running)


`systemctl --machine home@ --user status`:

Failed to connect to bus: Permission denied
Failed to read server status: Transport endpoint is not connected


`strace` of `openclaw gateway status`:

execve("/usr/bin/systemctl", ["systemctl", "--machine", "home@", "--user", "status"], ...)
execve("/usr/bin/systemctl", ["systemctl", "--machine", "home@", "--user", "is-enabled", "openclaw-gateway.service"], ...)


Session env confirms user bus exists:

XDG_RUNTIME_DIR=/run/user/1001
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus


Host identifiers:

hostname: home
/etc/hostname: home

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Summary

Steps to reproduce

On Ubuntu 24.04.4, run OpenClaw Gateway as a systemd user service (openclaw-gateway.service) for user ai (UID 1001).
Confirm systemctl --user status openclaw-gateway.service shows active (running).
Run openclaw gateway status.
Observe it reports systemctl --user unavailable: Failed to connect to bus: Permission denied.
(Evidence) strace shows OpenClaw executes systemctl --machine home@ --user ....

Expected behavior

openclaw gateway status should correctly detect/report the running systemd user service status when systemctl --user status openclaw-gateway.service works in the same session.

Actual behavior

openclaw gateway status reports:

Service: systemd (disabled)
Runtime: unknown (systemctl --user unavailable: Failed to connect to bus: Permission denied Failed to read server status: Transport endpoint is not connected) even though the service is active and systemctl --user works.

OpenClaw version

2026.4.5

Operating system

Ubuntu 24.04.4 LTS

Install method

npm global

Model

gpt-5.2

Provider / routing chain

openclaw (CLI) -> local gateway (ws://127.0.0.1:18789, LAN 192.168.1.53:18789) -> providers (as configured)

Additional provider/model setup details

Gateway is reachable locally (openclaw gateway probe connects to ws://127.0.0.1:18789; RPC ok). Web UI access is via Caddy reverse proxy on the same machine using https://openclaw.lan (resolved via /etc/hosts) with a local certificate. No wide-area discovery (Bonjour shows 0; wide-area discovery unknown).

Logs, screenshots, and evidence

openclaw gateway status (excerpt):

Runtime: unknown (systemctl --user unavailable: Failed to connect to bus: Permission denied
Failed to read server status: Transport endpoint is not connected)


`systemctl --user status openclaw-gateway.service --no-pager` (excerpt):

Active: active (running)


`systemctl --machine home@ --user status`:

Failed to connect to bus: Permission denied
Failed to read server status: Transport endpoint is not connected


`strace` of `openclaw gateway status`:

execve("/usr/bin/systemctl", ["systemctl", "--machine", "home@", "--user", "status"], ...)
execve("/usr/bin/systemctl", ["systemctl", "--machine", "home@", "--user", "is-enabled", "openclaw-gateway.service"], ...)


Session env confirms user bus exists:

XDG_RUNTIME_DIR=/run/user/1001
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus


Host identifiers:

hostname: home
/etc/hostname: home

Impact and severity

Additional information

openclaw gateway probe reports reachable gateway and RPC OK while openclaw gateway status reports systemd user services unavailable.
machinectl list produced no output in this environment.

extent analysis

TL;DR

The issue can likely be fixed by modifying the openclaw gateway status command to use systemctl --user instead of systemctl --machine home@ --user to check the systemd user service status.

Guidance

The root cause of the issue seems to be the use of --machine home@ in the systemctl command, which is causing a permission denied error when trying to connect to the bus.
To verify this, try running systemctl --user status openclaw-gateway.service and compare the output with openclaw gateway status.
Modify the openclaw gateway status command to use systemctl --user instead of systemctl --machine home@ --user to check the systemd user service status.
Check the openclaw configuration to see if there is an option to specify the systemctl command to use, and update it to use systemctl --user if possible.

Example

No code snippet is provided as the issue seems to be related to the command used by openclaw gateway status rather than a code issue.

Notes

The issue seems to be specific to the openclaw gateway status command and the use of --machine home@ in the systemctl command. The openclaw gateway probe command is not affected and reports the gateway as reachable.

Recommendation

Apply workaround: Modify the openclaw gateway status command to use systemctl --user instead of systemctl --machine home@ --user to check the systemd user service status, as this seems to be the root cause of the issue.

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?

FAQ

Expected behavior

openclaw gateway status should correctly detect/report the running systemd user service status when systemctl --user status openclaw-gateway.service works in the same session.

#dependency conflict #environment setup #docker error #permission error #memory optimization

Still need to ship something?

×6

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