Rocket.Chat Fails Due to TCP Broker Port Conflict (`EADDRINUSE` on :::XXXXX) - FIXED

Open
  • Is something wrong?
#248 7 comments 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
docker, mongodb
Domain
databases, devops

Research direction

No repository files, tests, or entry points are named. Start with the Mongo shell and the rocketchat_apps collection described in the issue, then inspect the Docker container logs after a restore; done would mean restarting without EADDRINUSE and allowing apps to load.

Written by the indexing model from the issue text.

Description

🛠️ Rocket.Chat Fails Due to TCP Broker Port Conflict (EADDRINUSE on :::41403) — FIXED
❗ The Problem

After restoring a Rocket.Chat instance via mongorestore (including rocketchat_apps collection), and running it behind Docker + Traefik, the platform appeared to start fine, but the logs were filled with:

ERROR .../TRANSPORTER: Server error. Error: listen EADDRINUSE: address already in use :::41403

This caused:

  • App Engine Deno subprocesses to fail.
  • Rocket.Chat UI to partially load (but no app could be loaded).
  • Broker reconnection attempts every 5 seconds.
  • No listening process actually bound to port 41403 inside the container.
🧪 What Was Tried (and Failed)
  • Setting sysctl net.ipv6.conf.all.disable_ipv6=1 inside the container.
  • Verifying exposed ports using ss, netstat, etc. — no explicit conflict.
  • Explicitly setting BROKER_TRANSPORTER and ROCKETCHAT_APPS_ENGINE_BROKER_TRANSPORTER to different loopback addresses/ports.
  • No known issue from Traefik side (proxy working perfectly).

Nothing helped.

✅ The Actual Root Cause & Fix

Turns out the issue was that two Rocket.Chat apps were already marked as manually_enabled in the DB, and both attempted to spin up their own Moleculer broker, causing an internal port collision on ::41403.

💥 Fix (run inside Mongo shell):

use rocketchat
db.rocketchat_apps.updateMany({}, { $set: { status: 'disabled' } })

🌀 After restarting the container, the broker booted cleanly, no more EADDRINUSE, and apps could be re-enabled one by one via the UI or DB.

🧰 Config Reference (doesn’t help alone!)

⚠️ These env vars alone didn’t solve anything unless the DB apps were disabled.

rocketchat:
  image: rocketchat/rocket.chat:latest
  environment:
    BROKER_TRANSPORTER: tcp://0.0.0.0:42000
    ROCKETCHAT_APPS_ENGINE_BROKER_TRANSPORTER: tcp://127.0.0.1:42000
  sysctls:
    - net.ipv6.conf.all.disable_ipv6=1
💡 Suggestions

  • Rocket.Chat should check for multiple apps trying to bind the same broker port.

  • Perhaps include a startup flag like:

    DISABLE_ALL_APPS_ON_BOOT=true

    …to prevent these port conflicts after database restores or migrations.

  • At the very least, if EADDRINUSE is detected, auto-disable the crashing app with an informative log.

💬 Hope this helps someone who is restoring or migrating Rocket.Chat and hitting this obscure bug.

Let me know if logs or further context are useful!

Dominant language
Dockerfile
Stars
336
Forks
226
Avg merge
21d 4h
Merged PRs (30d)
1

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from RocketChat/Docker.Official.Image

All issues in RocketChat/Docker.Official.Image

Similar issues

More Databases issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.