Error installing Miro SFU

[nebulon]

Right, so the issue is, that docker uses/used random free ports for logging on the system and sometimes those conflict with the port range for mirotalk. This is why it "randomly" happens. The fix is in the platform, pending a Cloudron release, not a mirotalk package.

[shrey]

@nebulon
Just tried setting up the MiroTalk SFU for the first time.

I'm a bit surprised that it's marked as stable, as currently, it's pretty impractical trying to get it to work.
Because:

1. I was able to get it to work only after repeated cycles of editing the port, and starting Installation.
2. Even when installed, when i try to restart the app after a modification in the config.js file, the same vicious cycle starts again.

Is there no workaround for now?

[jdaviescoates]

@shrey Are you on Cloudron 7.7.2? Because I think the port clash issue is supposed to have been fixed on that.

[shrey]

@jdaviescoates yes, I'm on 7.7.2

[nebulon]

If this happens again maybe you can run ss -lpn | grep 40092 (change the port depending on the reported port clash). Then check the process id and identify which process/container is occupying that port. So maybe there are other processes which randomly pick ports and caus the conflict, which are not tracked by the platform yet.

[jdaviescoates]

@nebulon said in Error installing Miro SFU:

If this happens again maybe you can run ss -lpn | grep 40092

Run that where exactly?

[nebulon]

on the host system. You may also use other tools like lsof to figure out which process is occupying that port by chance

[jdaviescoates]

@nebulon said in Error installing Miro SFU:

on the host system

That still isn't very clear, but I think you mean SSH into the server, and run it there, right?

I don't even have this problem at present, just asking for the greater good

[nebulon]

Yes sorry for the confusion, so I mean SSH into the Ubuntu server itself (in contrast to a webterminal into the app container).

[jdaviescoates]

I just spotted that my MiroTalk has errored out with this again:

Docker Error: (HTTP code 500) server error - driver failed programming external connectivity on endpoint 16628ecd-d520-4174-ab00-d1eee973101a (8041bbc62efcf050c988cabb0c91fb4d516ac1b3076532b1d284c4f34fadf506): failed to bind port 0.0.0.0:40020/tcp: listen tcp4 0.0.0.0:40020: bind: address already in use

Hitting the retry button in repair didn't work the first time, but it did work the second time

[nebulon]

Yes this is a known issue we have seen rarely. Somehow docker hasn't freed up the port yet. A retry fixes the issue, but we haven't been able to reproduce this reliably for debugging and fixing.