#[Bug] Gateway service check fails with "No medium found" on WSL2 despite systemd running correctly

1 messages · Page 1 of 1 (latest)

ripe needle
#

[Bug Report] Gateway service check failed: systemctl is-enabled unavailable — No medium found (WSL2 + user service)

Environment:

  • OS: Windows 11 with WSL2 (Ubuntu)
  • Host: LAPTOP-6MDVC4PE
  • OpenClaw version: 2026.4.15 (041266a)
  • Deployment: Local, running as systemd user service (openclaw-gateway.service)
  • systemd version: 255.4-1ubuntu8.15

Issue:
The gateway health check repeatedly throws the following error every ~10 seconds:

Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found

What I verified:

  • systemd is active and running (ps -p 1 -o comm=systemd)
  • D-Bus is healthy (systemctl status dbusactive (running))
  • The service is enabled (systemctl is-enabled openclaw-gatewayenabled)
  • Both DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR are present in the user session:
    • DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
    • XDG_RUNTIME_DIR=/run/user/1000/
  • Running systemctl is-enabled openclaw-gateway manually from the terminal works fine with no errors.

Root cause (suspected):
The health check subprocess spawned by OpenClaw does not inherit the necessary environment variables (DBUS_SESSION_BUS_ADDRESS, XDG_RUNTIME_DIR) from the parent process. As a result, it cannot connect to the D-Bus session bus even though everything is properly configured.

Impact:
The error itself does not affect functionality — the gateway runs normally, Telegram channel works, and the webchat UI connects successfully. However, the repeated error spam in the logs makes it harder to identify real issues.

Suggested fix:
When spawning the subprocess for the service check, ensure it inherits the user session environment variables, or explicitly pass DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR. Alternatively, consider using systemctl --user is-enabled instead of the system-level call when running in a user service context.

hearty sierraBOT
crystal creekBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

hearty sierraBOT
sick cargoBOT
#

Quick check: the local docs path I expected isn’t there, so I’m switching to the installed docs plus a tighter source search to avoid binary noise.

#

I found the relevant code and tests. There’s already WSL2-specific coverage in the repo, so I’m checking whether your exact No medium found case is expected to be handled or if it’s a regression in 2026.4.15.

#

This looks like a real bug.

Small correction, current code already uses systemctl --user, and on main it explicitly treats Failed to connect to bus / No medium found as a user-bus-unavailable case. There are tests for that path too. So I don’t think this is just “it forgot --user”.

What it looks like instead is:

  • 2026.4.15 is still surfacing that probe as an error in the polling/status path
  • the gateway itself keeps working, but the service-enabled check is noisy on WSL2 user-service setups

So your local diagnosis is directionally right, but I’d frame the fix as: treat this probe failure as non-fatal in the health/status loop, or make the fallback/user-bus handling consistent there.

I’d file this on GitHub as a bug, this is maintainer territory:
https://github.com/openclaw/openclaw/issues

Your report is already solid. I’d just add:

  • openclaw status --all
ripe needle
#

Here's the output with gateway running:

OS: linux 6.6.87.2-microsoft-standard-WSL2 (x64)
OpenClaw: 2026.4.15 (041266a) | Node: 22.22.2
Gateway service: systemd installed · enabled · running (pid 81232, state active)
Gateway: reachable 54ms · auth token OK
Telegram: ON · OK

Notable warnings:
⚠️ Gateway service check failed: No medium found (the bug being reported)
⚠️ Service uses Node from nvm — may break after upgrades

Full output: https://gist.github.com/...

sick cargoBOT
#

Nice, that pretty much confirms it.

The important part is:

  • systemd installed · enabled · running
  • gateway reachable, auth OK
  • Telegram OK
  • but the probe still warns No medium found

So this really does look like a false-negative service probe, not an actual gateway/service failure.

Two notes:

  • the No medium found warning looks like the real bug
  • the nvm warning is separate, useful, but unrelated to this WSL2 probe issue

If you file the GitHub issue, I’d include exactly this status block plus the gist. It makes the contradiction very clear:

ripe needle
#

Yes please, help me turn it into a tight GitHub issue body!

sick cargoBOT
#

Yep, paste this as-is and tweak anything you want:

Title
False-positive gateway service warning on WSL2 user service: systemctl is-enabled unavailable: Failed to connect to bus: No medium found

Body

## Summary

On WSL2, OpenClaw reports a repeated gateway service check failure even though the gateway service is installed, enabled, running, and the gateway itself is healthy.

The warning appears roughly every 10 seconds:

```text
Gateway service check failed: Error: systemctl is-enabled unavailable: Failed to connect to bus: No medium found
#

This looks like a false-negative service probe rather than a real service failure.

## Environment

- OS: Windows 11 with WSL2 (Ubuntu)
- Host: `LAPTOP-6MDVC4PE`
- OpenClaw: `2026.4.15 (041266a)`
- Node: `22.22.2`
- systemd: `255.4-1ubuntu8.15`
- Deployment: local, running as systemd user service (`openclaw-gateway.service`)

## Actual behavior

`openclaw status` reports the service and gateway as healthy:
#

```text
OS: linux 6.6.87.2-microsoft-standard-WSL2 (x64)
OpenClaw: 2026.4.15 (041266a) | Node: 22.22.2
Gateway service: systemd installed · enabled · running (pid 81232, state active)
Gateway: reachable 54ms · auth token OK
Telegram: ON · OK

Notable warnings:
⚠️ Gateway service check failed: No medium found
⚠️ Service uses Node from nvm — may break after upgrades

The nvm warning seems unrelated. The relevant issue is the repeated No medium found service check failure.

#
## Expected behavior

If the gateway service is installed, enabled, and running, and the gateway is reachable, OpenClaw should not emit repeated service-check failures.

At minimum, this probe failure should be treated as non-fatal / degraded / unknown instead of noisy repeated warnings.

## What I verified

- `systemd` is active inside WSL2 (`ps -p 1 -o comm=` → `systemd`)
- D-Bus is healthy
- The gateway service is enabled
- The gateway service is running
- The gateway itself is reachable and functioning normally
- Telegram works
- The web UI connects successfully
#
- `DBUS_SESSION_BUS_ADDRESS` and `XDG_RUNTIME_DIR` are present in the interactive user session:
  - `DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus`
  - `XDG_RUNTIME_DIR=/run/user/1000/`
- Manual `systemctl` checks from the shell succeed

## Suspected cause

Possibly the subprocess used for the service-enabled probe does not have the same usable user-bus context as the interactive shell, or WSL2 user-bus handling is inconsistent in the polling/status path.

This looks like a service probe bug, not an actual gateway failure.

## Impact

Functionality appears unaffected, but the repeated error spam makes it harder to spot real issues in logs and status output.