Error installing Miro SFU

[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.