#Log file swamped with `warn bonjour` entries

1 messages · Page 1 of 1 (latest)

tawny plover
#

My log file is full of once-a-minute 'warn bonjour' entries that (a) I don't understand, and (b) make it impossible to find anything else. Here's an excerpt...

cn@openclaw:~$ oc logs --limit 200 --plain

🦞 OpenClaw 2026.3.8 (3caab92) — The lobster in your shell. 🦞

│
◇ Doctor warnings ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and allowFrom) is │
│ empty — all group messages will be silently dropped. Add sender IDs to │
│ channels.telegram.groupAllowFrom or channels.telegram.allowFrom, or set groupPolicy to │
│ "open". │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
│
◇
Log file: /tmp/openclaw/openclaw-2026-03-14.log
2026-03-14T00:23:32.194Z warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (2)._openclaw-gw._tcp.local. host=openclaw-(2).local. port=18789 state=probing)
2026-03-14T00:24:32.195Z warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (2)._openclaw-gw._tcp.local. host=openclaw-(2).local. port=18789 state=probing)
2026-03-14T00:25:32.204Z warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (2)._openclaw-gw._tcp.local. host=openclaw-(2).local. port=18789 state=probing)
2026-03-14T00:26:32.197Z warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (2)._openclaw-gw._tcp.local. host=openclaw-(2).local. port=18789 state=probing)

cinder pierBOT
#

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

real mantleBOT
#

Those warn bonjour lines are the Gateway’s LAN discovery beacon (mDNS / DNS‑SD). It’s a convenience feature so nodes / apps can auto-find your gateway on the local network — it’s not required for normal “I know the URL + token” operation.

What your log is saying:

  • watchdog detected non-announced service; attempting re-advertise
  • state=probing
  • instance name openclaw (2)...local.

That usually means the mDNS service never makes it from probing → announced (common causes: multicast blocked, or a naming/hostname conflict; the (2) suffix is a big hint there’s a conflict somewhere).

Option A (recommended if you don’t need LAN auto-discovery): disable Bonjour

Set this env var and restart the gateway:

  • OPENCLAW_DISABLE_BONJOUR=1

Best place (so it also applies when running as a service): ~/.openclaw/.env, then:

# 
openclaw gateway restart

Docs: https://docs.openclaw.ai/gateway/bonjour (see “Disabling / configuration”)

Option B (if you do want Bonjour discovery to work): fix the underlying cause

Things to check:

  1. Hostname / instance name simplicity
    Your advertised name includes spaces + parentheses (openclaw (2)), and the docs explicitly call out that “complex names / punctuation can confuse resolvers”. Renaming the machine to something boring like openclaw2 and restarting the gateway often fixes this.

  2. Multicast/mDNS blocked
    If this is on a VPS, inside some Docker/network setups, or on restrictive Wi‑Fi, mDNS just won’t work reliably. In that case: disable it (Option A) and use SSH/Tailscale.

  3. Duplicate gateway beacons
    If you actually have two gateways advertising the same service on the LAN, you’ll see conflicts. (The (2) suffix typically appears when the name is already taken.)

#

Making the logs usable right now (filtering)

Since openclaw logs doesn’t have a built-in exclude flag, just pipe-filter:

openclaw logs --plain --limit 500 | rg -v " warn bonjour "

(or --json | jq 'select(.subsystem != "bonjour")' if you prefer structured filtering.)

If after disabling Bonjour you still see spam, that’d be a bug — worth filing an issue with the snippet + your OS/network context: https://github.com/openclaw/openclaw/issues

tawny plover
#

Please help me track down the possible conflict. Also walk me through setting the environment variable in "ELI5" mode.

real mantleBOT
#

Yep — that (2) in openclaw (2)._openclaw-gw._tcp.local. is the smoking gun: Bonjour/mDNS is trying to advertise the gateway, but the name “openclaw” is already taken on your LAN (or it thinks it is), so it auto-picks a “(2)” suffix… and then gets stuck in state=probing, so the watchdog re-tries every minute.

Below is (1) how to find the conflicting thing, and (2) ELI5 how to set OPENCLAW_DISABLE_BONJOUR=1.

1) Tracking down the conflict (practical checklist)

A. Check whether you accidentally have two gateways on the same box

This is the “easy” conflict to prove/kill.

Run on the gateway host:

openclaw gateway status
ss -ltnp | rg ":18789"
# 
ps aux | rg -i "openclaw|oc " | rg -v rg

What you’re looking for:

  • More than one openclaw/oc process
  • More than one process bound to :18789

If you find duplicates, stop the extra one (or reboot if things are wedged).

B. Browse for _openclaw-gw._tcp on the LAN (this finds the “other box”)

Do this from any machine on the same LAN (often easiest from a Mac):

macOS:

# 
dns-sd -B _openclaw-gw._tcp local.

Then resolve one of the results:

dns-sd -L "<instance name>" _openclaw-gw._tcp local.

Linux (if you have avahi tools):

avahi-browse -rt _openclaw-gw._tcp

If you see two gateways, you’ve found the conflict.

  • One of them will likely be advertising as openclaw._openclaw-gw._tcp.local.
  • Your machine is trying to become openclaw (2)…
#

If you see zero gateways at all, then it’s more likely multicast/mDNS is blocked on that network (or the gateway host can’t send/receive mDNS properly). In that case, disabling Bonjour is usually the right move anyway.

C. Check for a hostname collision (not just OpenClaw)

It can also be as simple as: you have two devices named openclaw on the LAN (common with cloned VMs / old installs / Raspberry Pis).

From any machine on the LAN, try:

ping openclaw.local

If that resolves to a machine that is not the one you expect, you’ve found the collision.

2) ELI5: set OPENCLAW_DISABLE_BONJOUR=1

#

Think of an “environment variable” as a sticky note you leave for programs at startup: “hey, run with this setting.”

Because your gateway likely runs as a service, the most reliable place to put that sticky note is:

~/.openclaw/.env

Step-by-step

  1. Open (or create) the file:
nano ~/.openclaw/.env
  1. Add this line (exactly):
OPENCLAW_DISABLE_BONJOUR=1
#

  1. Save + exit (Ctrl+O, Enter, then Ctrl+X in nano)

  2. Restart the gateway:

openclaw gateway restart
  1. Confirm the spam is gone:
openclaw logs --limit 200 --plain | rg -n "bonjour"

To undo later: remove that line (or change 1 to 0) and restart again.

Docs that mention this explicitly: https://docs.openclaw.ai/gateway/bonjour (see “Disabling / configuration”)