MiroTalk Update regularly fails after update

[djxx]

Description

MiroTalk SFU regularly gets stuck during the automatic update process:

Docker Error: (HTTP code 500) server error - failed to set up container networking: driver failed programming external connectivity on endpoint a877975d-38be-4088-bc92-e0d7a486a818 (2e5adaa635a95bd65ca0f290712065d444528e3420c49f2f88323b40c62caaa5): failed to bind host port for 0.0.0.0:40014:172.18.16.130:40014/tcp: address already in use

Steps to reproduce

Not sure. It happens during updates though.

Troubleshooting Already Performed

I've stopped the app, tried to retry the upgrade, retry the configure task. Sometimes it works after a few tries, other times I have to restart the server first.

System Details

Hetzner
vServer
4 Core "AMD EPYC-Milan Processor"
16.37 GB RAM & 4.29 GB Swap

Cloudron Version

9.0.15

Ubuntu Version

24.04

Output of cloudron-support --troubleshoot

Linux: 6.8.0-88-generic
Ubuntu: noble 24.04
Execution environment: kvm
Processor: AMD EPYC-Milan Processor
BIOS NotSpecified  CPU @ 2.0GHz x 4
RAM: 15989992KB
Disk: /dev/sda1        44G
[OK]	node version is correct
[OK]	IPv6 is enabled in kernel. No public IPv6 address
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[OK]	Service 'mysql' is running and healthy
[OK]	Service 'postgresql' is running and healthy
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.0.15 is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	Dashboard is reachable via domain name
[WARN]	Domain domain.com expiry check skipped because whois does not have this information
[OK]	unbound is running

[james]

Hello @djxx
This is a common issue and has been reported multiple times.
Please try to stop the app, wait a minute and then attempt the update process again.
If this still fails, please stop the app again.
Then connect with ssh to your server.

Since your error is the following:

Docker Error: (HTTP code 500) server error - failed to set up container networking: driver failed programming external connectivity on endpoint a877975d-38be-4088-bc92-e0d7a486a818 (2e5adaa635a95bd65ca0f290712065d444528e3420c49f2f88323b40c62caaa5): failed to bind host port for 0.0.0.0:40014:172.18.16.130:40014/tcp: address already in use

it reveals you have changed the ports to 40000 'ish.
Could you please confirm what port you have chosen?
From the ports you have chosen you can run the following command in ssh to see if any other application is already using the the ports:
If you have chosen 40000 then the Mirotalk app uses 100 ports of so 40000 to 40100.

lsof -i :40000-40100

[djxx]

@james Thanks for the quick reply. I didn't change any ports manually. Could it be that this and another application are conflicting and it's not being detected?

I'll run this lsof command next time it happens to see if I can identify the culprit.

[avatar1024]

I have had that happened with Mirotalk too,. Sometimes update get stuck. Happens less often these days but still sometimes. I either have to restart the app or remove and reinstall.

[MiroTalk]

Port allocation behavior

By default, when SFU_SERVER is set to false, the application uses a range of 100 ports.

when SFU_SERVER=true it allocate ports starting from 40000 default + CPU core eg if your server has 4CPU so become 40000 - 40003 (only 3 ports needed)

More about: https://mediasoup.discourse.group/t/mediasoups-webrtcserver-concerning-firewall-settings-and-port-binding/5965/5

---

Cloudron integration

To support this behavior on Cloudron, SFU_SERVER should be exposed as a toggle (switch button) in the MiroTalk SFU app settings (Location).
When the switch is enabled, the port allocation logic in start.sh can be updated something as follows:

# Enable / disable SFU server (default: false)
readonly SFU_SERVER="${SFU_SERVER:-false}"

# Number of CPU cores (used only when SFU is enabled)
readonly CPU_CORES="$(nproc)"

# Base TCP port (default: 25000)
readonly SFU_TCP_BASE="${SFU_TCP:-25000}"

if [[ "$SFU_SERVER" == "true" ]]; then
    # SFU enabled:
    # allocate one port per CPU core
    readonly SFU_MAX_PORT=$(( SFU_TCP_BASE + CPU_CORES - 1 ))
else
    # Default behavior:
    # allocate 100 ports starting from the base port
    readonly SFU_MAX_PORT=$(( SFU_TCP_BASE + 100 ))
fi

---

Benefits of this approach

• Fewer ports allocated
  Only the ports that are actually needed are opened, especially in SFU mode.

• Reduced port conflicts
  Smaller port ranges significantly lower the chance of clashes with other services on the same host.

• Better Cloudron compatibility
  Minimal port exposure aligns well with Cloudron’s strict networking and security model.

• Scales with hardware
  Port allocation automatically adapts to the number of CPU cores available.

• User control
  Exposing SFU_SERVER as a switch allows users to explicitly choose whether to run in SFU mode or keep the default behavior.

[james]

Hello @mirotalk
Does this have any other effects?