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

[fgirolami29]

🛠️ 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!

---

[Gummikavalier]

We have been hit by this problem too on RC 7.10.0 and docker-compose deployment.

We had only Poll and Giphy apps enabled. We did not restart node-processes / docker images for few days. We usually do, so this has gone undetected earlier. Within a week we started witnessing "grey messages" where the messages seemed to fail to be sent randomly. (They succeeded but did not refresh to black text unless you did a reload on the client.)

After restarting services in the morning, we still had 300 000 internal established connections between the node processes in the evening. So these accumulated really fast in some particular conditions.

We have now disabled the apps, both in the admin UI and in the database as well. I'll report back if the issue persists or not.

[Gummikavalier]

At first we disabled all apps, and this helped to the issue. Then we enabled official Poll app again. The situation remained stable and still no runaway amounts of local established connections at the end of the day.

Our experience on the matter is now that what may affect the issue is either Giphy app or running more than one app in RC's app framework.

[Gummikavalier]

The issue repeated also with just Poll app enabled within couple of days. Now disabled all apps.

[reetp]

This is not really the corrrect repo.

See the comment here.

https://github.com/RocketChat/Docker.Official.Image#docker-compose

This is probably a duplicate here and is probably better opened/followed up in the main repo than here.

RocketChat/Rocket.Chat#36268

RocketChat/Rocket.Chat#35590

[Gummikavalier]

Thanks reetp! 👍

[Gummikavalier]

Just ending for our particular case with this error:

We haven't had issues since putting label into our compose.yml:

    labels:
      traefik.enable: "false"

Not sure if this really matters, but we ran 6 days without issues with it.

Later we also set up NATS server to ease up with multi-instance communication flow as well. This seems to be the recommended scenario these days for multi-instance.

We also didn't have TCP_PORT (only PORT) variable in use, and that was recommended as well. TCP_PORT is required for mesh structured notification streams communication internally between the instances when not using NATS. The port should not be the same than PORT value, and if not specified, instances choose a random port number for it, making the issue scenario more complicated.
But since using network_mode=host may actually change things a bit, I didn't look into it further. I'll do so if there are reasons to remove NATS server from the setup at some point.

[reetp]

For me this seemed to work flawlessly on two of my instances that I have done so far:

RocketChat/Rocket.Chat#36268 (comment)

Seems if you don't have NATS you need to specify the TCP_PORT