signal daemon exited (source=process code=1 signal=null) | Friends of the Crustacean 🦞🤝 | Page 1

static lotus Apr 20, 2026, 3:47 PM

#

New to OpenClaw. Just installed on an Ubuntu VM inside VirtualBox on my local Windows desktop. Having trouble with connecting it to Signal. Help?

Probe failed · fetch failed | connect ECONNREFUSED 127.0.0.1:8080

A snippet of OpenClaw logs for signal look something like:

$ openclaw logs | grep "signal"
...
2026-04-20T15:35:01.209Z info gateway/channels/signal {"subsystem":"gateway/channels/signal"} [default] starting provider (http://127.0.0.1:8080)
2026-04-20T15:35:01.299Z info gateway/channels/signal {"subsystem":"gateway/channels/signal"} signal-cli: Error: LinkageError occurred while loading main class org.asamk.signal.Main
2026-04-20T15:35:01.301Z info gateway/channels/signal {"subsystem":"gateway/channels/signal"} signal-cli: java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 69.0), this version of the Java Runtime only recognizes class file versions up to 65.0
2026-04-20T15:35:01.352Z error gateway/channels/signal {"subsystem":"gateway/channels/signal"} signal daemon exited (source=process code=1 signal=null)
2026-04-20T15:35:01.353Z error gateway/channels/signal {"subsystem":"gateway/channels/signal"} [default] channel exited: signal daemon exited (source=process code=1 signal=null)
...

This makes it look like my Java isn't up to date, but as far as I can tell everything is up to date:

$ openclaw --version
OpenClaw 2026.4.15 (041266a)
$ signal-cli --version
signal-cli 0.14.2
$ java -version
openjdk version "26" 2026-03-17
OpenJDK Runtime Environment (build 26+35-snap)
OpenJDK 64-Bit Server VM (build 26+35-snap, mixed mode, sharing)

I can send/receive signal messages from the command line just fine!

Any hints?

upbeat juncoBOT Apr 20, 2026, 3:47 PM

#

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

low gustBOT Apr 20, 2026, 3:47 PM

#

wise geyserBOT Apr 20, 2026, 3:50 PM

#

Yep, ECONNREFUSED 127.0.0.1:8080 is just the downstream symptom. signal-cli is crashing before it can bind the daemon port.

The key line is this:

class file version 69 = Java 25
runtime only recognizes up to 65 = Java 21

So the process OpenClaw launches is not seeing the same runtime you see in your shell.

Most likely causes:

OpenClaw is using a different signal-cli than your shell
The gateway runs as a systemd --user service, so it has a different PATH / Java env

Try this first:

#

openclaw config get channels.signal.cliPath
command -v signal-cli
readlink -f "$(command -v signal-cli)"
file "$(readlink -f "$(command -v signal-cli)")"

If channels.signal.cliPath is different, point OpenClaw at the working binary explicitly:

openclaw config set channels.signal.cliPath "$(readlink -f "$(command -v signal-cli)")"
openclaw gateway restart
openclaw channels status --probe

If that working binary is the Linux native signal-cli build, even better, because that sidesteps the Java mismatch completely.

#

If it still fails, check what the gateway service is actually running with:

systemctl --user show openclaw-gateway.service -p Environment -p ExecStart

My bet is that your shell has the good signal-cli / Java, but the service is launching an older JVM-backed one.

Docs:

If you paste the output of those 5 commands, I can narrow it down pretty fast.

static lotus Apr 20, 2026, 4:02 PM

#

openclaw config get channels.signal.cliPath
command -v signal-cli
readlink -f "$(command -v signal-cli)"
file "$(readlink -f "$(command -v signal-cli)")"

Gives me:

🦞 OpenClaw 2026.4.15 (041266a) — If it works, it's automation; if it breaks, it's a "learning opportunity."

signal-cli
/usr/local/bin/signal-cli
/opt/signal-cli-0.14.2/bin/signal-cli
/opt/signal-cli-0.14.2/bin/signal-cli: POSIX shell script, Unicode text, UTF-8 text executable, with very long lines (1536)

systemctl --user show openclaw-gateway.service -p Environment -p ExecStart gives me:

ExecStart={ path=/snap/node/11398/bin/node ; argv[]=/snap/node/11398/bin/node /home/my-openclaw/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789 ; ignore_errors=no ; start_time=[Mon 2026-04-20 15:28:16 UTC] ; stop_time=[n/a] ; pid=13912 ; code=(null) ; status=0/0 }
Environment=HOME=/home/my-openclaw TMPDIR=/tmp PATH=/snap/node/11398/bin:/home/my-openclaw/.local/bin:/home/my-openclaw/.npm-global/bin:/home/my-openclaw/bin:/home/my-openclaw/.volta/bin:/home/my-openclaw/.asdf/shims:/home/my-openclaw/.bun/bin:/home/my-openclaw/.nvm/current/bin:/home/my-openclaw/.fnm/current/bin:/home/my-openclaw/.local/share/pnpm:/usr/local/bin:/usr/bin:/bin OPENCLAW_GATEWAY_PORT=18789 OPENCLAW_SYSTEMD_UNIT=openclaw-gateway.service "OPENCLAW_WINDOWS_TASK_NAME=OpenClaw Gateway" OPENCLAW_SERVICE_MARKER=openclaw OPENCLAW_SERVICE_KIND=gateway OPENCLAW_SERVICE_VERSION=2026.4.15

wise geyserBOT Apr 20, 2026, 4:03 PM

#

I think we found it.

channels.signal.cliPath is unset, so OpenClaw is just running signal-cli from the gateway service PATH.

And your service PATH is:

PATH=...:/usr/local/bin:/usr/bin:/bin

Notice what's missing: /snap/bin

So if your Java 26 is coming from Snap, the gateway service never sees it. It will fall back to some other java on /usr/bin, which is very likely Java 21, and that matches the error exactly (69 vs 65).

A couple quick checks from your normal shell:

#

command -v java
readlink -f "$(command -v java)"
echo "$PATH"

If that Java resolves under /snap, that's the smoking gun.

Best next step

Reinstall the gateway service from a shell where the correct Java is on PATH:

openclaw gateway install --force
openclaw gateway restart
openclaw channels status --probe

#

Then verify the service PATH again:

systemctl --user show openclaw-gateway.service -p Environment

You want /snap/bin in there, or you want java to resolve to a non-snap Java 25+/26 under /usr/bin style paths.

If that still doesn't fix it

Then I'd do one of these:

install Java 25+/26 in a standard non-snap location, or
switch to the Linux native signal-cli build so Java stops mattering here

Docs:

#

If you paste command -v java + readlink -f "$(command -v java)", I can tell you pretty quickly which of those two paths is best.

static lotus Apr 20, 2026, 4:52 PM

#

Ok. Unfortunately, your Best next step didn't seem to end up changing anything.

I didn't want to mess with non-snap Java or change my currently-working-outside-openclaw signal-cli, so I did this instead:

I went into ~/.config/systemd/user/openclaw-gateway.service to add:

Environment=JAVA_HOME=/snap/openjdk/current/jdk
Environment=PATH=.../snap/openjdk/current/jdk/bin:...

Then restarted my system, and that worked.

wise geyserBOT Apr 20, 2026, 4:53 PM

#

Nice, that makes sense. Good catch.

That confirms it was the systemd service env, not Signal itself. My earlier suggestion got close, but the missing piece was that the service needed the Snap Java path explicitly.

One small caveat: editing ~/.config/systemd/user/openclaw-gateway.service directly can get overwritten by reinstall/update. The cleaner long-term version is a systemd drop-in like:

# ~/.config/systemd/user/openclaw-gateway.service.d/override.conf
[Service]
Environment=JAVA_HOME=/snap/openjdk/current/jdk
Environment=PATH=/snap/openjdk/current/jdk/bin:/snap/bin:/usr/local/bin:/usr/bin:/bin

then:

#

systemctl --user daemon-reload
openclaw gateway restart

Thanks for reporting back, this is a really useful Ubuntu/Snap gotcha.

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

#signal daemon exited (source=process code=1 signal=null)

Best next step

If that still doesn't fix it