Jitsi-meet nightly (mar 29) on ubuntu 18.04 worked, but not after reboot, nginx won't start

I installed per the doc, and it was buggy, so installed again using nightly and it seemed to be working. Then I restarted my server and nginx wouldn’t start because of a conflict with turnserver for port 443. I figure services are not starting in the right order after a server restart? I tried to shut down services I thought were jitsi related and i issued a kill on the turnserver process, but still I couldn’t start nginx.

Is it me? Is this already a known bug? Should I post a big to the github repo?

Had the same issue - I added:

org.jitsi.videobridge.TCP_HARVESTER_PORT=4443

to /etc/jitsi/videobridge/sip-communicator.properties

Restarted “jitsi-videobridge” (probably “jitsi-videobridge2” with the nightly), and then “nignx”. Have not rebooted since to confirm however.

You mean PORT=443, right?

Whoops, I think you should disregard my reply all together, I missed where you said you were working with turnserver - I’m not. My issue was videobridge was camping on 443 if it started earlier than nignx, and that forced it to not. (Clearly it’s getting late and I should go to bed).

We, we all need our sleep, but if you happen to be up, I just followed the instruction guide so I’m not “working with turnserver”. I just see it as being the thing that’s using port 443. I don’t understand how the pieces of jitsi work together, but I’m assuming that it’s nginx that’s supposed to grab 443…

Ah. Yes, it is - and if nginx gets there first, videobridge drops back to 4443 - the config I pasted forces it to try 4443 first (or maybe only).

Was nginx misconfigured by the jitsi-meet install to conflict with itself? I killed what was using 443 and did this sequence:

Nothing using 443

root@xxx:/etc/nginx/sites-available# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 633/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 848/sshd
tcp6 0 0 :::22 :::* LISTEN 848/sshd
udp 0 0 127.0.0.53:53 0.0.0.0:* 633/systemd-resolve

But can’t start nginx

root@xxx:/etc/nginx/sites-available# systemctl start nginx
Job for nginx.service failed because the control process exited with error code.
See “systemctl status nginx.service” and “journalctl -xe” for details.

Why? 443 already in use, so it’s some sort of nginx misconfiguration, it conflicting with itself?

root@xxx:/etc/nginx/sites-available# systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2020-03-30 03:24:00 UTC; 5s ago
Docs: man:nginx(8)
Process: 2014 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=1/FAILURE)
Process: 2004 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)

Mar 30 03:23:58 xxx systemd[1]: Starting A high performance web server and a reverse proxy server…
Mar 30 03:23:58 xxx nginx[2014]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 30 03:23:58 xxx nginx[2014]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 30 03:23:59 xxx nginx[2014]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 30 03:23:59 xxx nginx[2014]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 30 03:24:00 xxx nginx[2014]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 30 03:24:00 xxx nginx[2014]: nginx: [emerg] still could not bind()
Mar 30 03:24:00 xxx systemd[1]: nginx.service: Control process exited, code=exited status=1
Mar 30 03:24:00 xxx systemd[1]: nginx.service: Failed with result ‘exit-code’.
Mar 30 03:24:00 xxx systemd[1]: Failed to start A high performance web server and a reverse proxy server.

Same behavior here with fresh install on Debian 10.3

Try to replace in /etc/nginx/modules-enabled/60-jitsi-meet.conf the port 443 with 4443 that works for me.

Hi Thomas,
Can you use the Turn server with this modification ?

I have the same problem but your solution doesn’t works for me.
Fresh install of jitsi meet and nginx on Ubuntu 18.04, as detailed in the quick install guide.

Ok, for me the nginx starts but i have no video and sound.

Can confirm this issue: the services haven’t been enabled by default. Therefore, …

 # systemctl enable prosody
 # systemctl enable jitsi-videobridge2
 # systemctl enable jicofo

has lead to a well-known setup without any errors in the logfiles. But still no video or audio…

Can you please paaste your Prosody config file?

Hi Ive followed this as well after it looks like theres a nginx conflict with 443. The problem I have now is that setting up a room if anyone tries to join it instantly crashes the room and it attempts to rety.
Ive read it might not be JVB and prosody not matching up passwords? But not sure as this wasnt in the quickguide install.
Im using a VM on Digital Ocean
My JVB log at
/var/log/jitsi/
2020-03-30 12:23:18.418 INFO: [18] Videobridge.createConference#326: create_conf, id=f05250cd75a83b97 gid=null logging=false
2020-03-30 12:23:18.425 INFO: [18] Health.doRun#294: Performed a successful health check in 7ms. Sticky failure: false
2020-03-30 12:23:20.705 INFO: [24] [hostname=localhost id=shard] MucClient.lambda$getConnectAndLoginCallable$7#648: Logging in.
2020-03-30 12:23:20.705 SEVERE: [24] RetryStrategy$TaskRunner.run#198: org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:292)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1100)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.lang.Thread.run(Thread.java:748)

I also had the situation that messy_one reported following the install guide. When researching that I saw discussion that talked about some bug fixes being fixed in the nightly, so I tried the nightly and got the problems in the original post. So… I’ll just post an issue to github and I’ll reference this discussion.

I posted this: https://github.com/jitsi/jitsi-meet/issues/5487

Interesting Ctrager, thanks. I’ve still no idea why if anyone trys to join my room it instantly crashes the room and get “attempting to rejoin message”.Its like the room will only work for me via the web browser.
If anyone try’s to connect via the phone app. The room crashes for both of us.
There must be some extra configuration elsewhere. If anyone has experienced this or know the solution please let me know.

For me, I just put all virtual hosts on nginx to listen to 4444 in replacement to 443 and it does the trick, but i still have an issue with jvb ip config, i’ll create my own post if i don’t find by myself.