Jitsi error in jvb.log

hello,

I’m on debian 10.

I have the following error in /var/log/jitsi/jvb.log

    OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
2020-04-13 10:00:38.579 INFORMATION: [1] NewConfig$1.invoke#88: Loaded NewConfig with origin: merge of system properties,system properties,reference.conf @ jar:file:/usr/share/jitsi-videobridge/jitsi-videobridge.jar!/reference.conf: 1,r$
2020-04-13 10:00:38.615 INFORMATION: [1] LegacyConfigFileLoader$Companion.load#40: Attempting to load legacy config file at path /etc/jitsi, videobridge, sip-communicator.properties
2020-04-13 10:00:38.622 INFORMATION: [1] LegacyConfigFileLoader$Companion.load#40: Attempting to load legacy config file at path /etc/jitsi, videobridge, sip-communicator.properties
2020-04-13 10:00:38.626 INFORMATION: [1] JitsiConfig$Companion.reload#40: Reloading.
2020-04-13 10:00:38.648 INFORMATION: [1] NewConfig$1.invoke#88: Loaded NewConfig with origin: merge of system properties,system properties,reference.conf @ jar:file:/usr/share/jitsi-videobridge/jitsi-videobridge.jar!/reference.conf: 1,r$
2020-04-13 10:00:38.648 INFORMATION: [1] LegacyConfigFileLoader$Companion.load#40: Attempting to load legacy config file at path /etc/jitsi, videobridge, sip-communicator.properties
2020-04-13 10:00:38.650 INFORMATION: [1] LegacyConfigFileLoader$Companion.load#40: Attempting to load legacy config file at path /etc/jitsi, videobridge, sip-communicator.properties
2020-04-13 10:00:38.709 INFORMATION: [13] ConfigurationActivator.start#45: Registered the LegacyConfigurationServiceShim in OSGi.
2020-04-13 10:00:38.715 INFORMATION: [13] AbstractVersionActivator.start#91: VersionService registered: JVB 2.1.169-ga28eb88e
2020-04-13 10:00:38.740 INFORMATION: [13] AbstractJettyBundleActivator.start#613: Not starting the Jetty service for org.jitsi.videobridge.rest.RESTBundleActivator(port=8080)
2020-04-13 10:00:38.752 INFORMATION: [13] AbstractJettyBundleActivator.start#613: Not starting the Jetty service for org.jitsi.videobridge.rest.PublicRESTBundleActivator(port=-1)
2020-04-13 10:00:38.755 INFORMATION: [13] AbstractJettyBundleActivator.start#613: Not starting the Jetty service for org.jitsi.videobridge.rest.PublicClearPortRedirectBundleActivator(port=8080)
2020-04-13 10:00:38.887 INFORMATION: [13] UlimitCheck.printUlimits#115: Running with open files limit 65000 (hard 65000), thread limit 65000 (hard 65000).
2020-04-13 10:00:38.891 INFORMATION: [13] VideobridgeExpireThread.start#92: Starting with 60 second interval.
2020-04-13 10:00:38.898 WARNUNG: [13] Videobridge.start#918: No authorized source regexp configured. Will accept requests from any source.
2020-04-13 10:00:38.940 INFORMATION: [19] Videobridge.createConference#326: create_conf, id=2823813477df2e01 gid=null logging=false
2020-04-13 10:00:38.968 INFORMATION: [19] TaskPools.<clinit>#81: TaskPools detected 4 processors, creating the CPU pool with that many threads
2020-04-13 10:00:39.187 INFORMATION: [13] JitsiConfig$Companion.reload#40: Reloading.
2020-04-13 10:00:39.205 INFORMATION: [13] NewConfig$1.invoke#88: Loaded NewConfig with origin: merge of system properties,system properties,reference.conf @ jar:file:/usr/share/jitsi-videobridge/jitsi-videobridge.jar!/reference.conf: 1,$
2020-04-13 10:00:39.205 INFORMATION: [13] LegacyConfigFileLoader$Companion.load#40: Attempting to load legacy config file at path /etc/jitsi, videobridge, sip-communicator.properties
2020-04-13 10:00:39.206 INFORMATION: [13] LegacyConfigFileLoader$Companion.load#40: Attempting to load legacy config file at path /etc/jitsi, videobridge, sip-communicator.properties
2020-04-13 10:00:39.285 INFORMATION: [13] OctoRelayService.start#62: Octo relay is disabled.
2020-04-13 10:00:39.340 INFORMATION: [23] org.ice4j.ice.harvest.StunMappingCandidateHarvester.discover: Discovered public address 88.218.224.165:42894/udp from STUN server 52.28.143.184:443/udp using local address 88.218.224.165:0/udp
2020-04-13 10:00:39.344 INFORMATION: [22] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Using org.ice4j.ice.harvest.StunMappingCandidateHarvester, face=/88.218.224.165, mask=/88.218.224.165
2020-04-13 10:00:39.345 INFORMATION: [22] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Initialized mapping harvesters (delay=135ms).  stunDiscoveryFailed=false
2020-04-13 10:00:39.349 INFORMATION: [19] org.ice4j.ice.harvest.AbstractUdpListener.<init>: Initialized AbstractUdpListener with address 88.218.224.165:10000/udp. Receive buffer size 10485760 (asked for 10485760)
2020-04-13 10:00:39.350 INFORMATION: [19] org.ice4j.ice.harvest.SinglePortUdpHarvester.<init>: Initialized SinglePortUdpHarvester with address 88.218.224.165:10000/udp
2020-04-13 10:00:39.376 WARNUNG: [24] [hostname=localhost id=shard] MucClient.lambda$getConnectAndLoginCallable$7#643: [MucClient id=shard hostname=localhost] error connecting
org.jivesoftware.smack.SmackException$ConnectionException: The following addresses failed: 'localhost:5222' failed because: localhost/127.0.0.1 exception: java.net.ConnectException: Verbindungsaufbau abgelehnt (Connection refused), loca$
        at org.jivesoftware.smack.SmackException$ConnectionException.from(SmackException.java:278)
        at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPConnection.java:619)
        at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:902)
        at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:383)
        at org.jitsi.xmpp.mucclient.MucClient.lambda$getConnectAndLoginCallable$7(MucClient.java:638)
        at org.jitsi.retry.RetryStrategy$TaskRunner.run(RetryStrategy.java:193)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)
SCTP JNI load: Linux OS detected
SCTP lib loaded
=====>: org_jitsi_modified_sctp4j_SctpJni.c calling init
=====>: org_jitsi_modified_sctp4j_SctpJni.c about to set SCTP_DEBUG_ALL

can someone help?

thank you :slight_smile:

I just had to restart jicofo.

I had the sampe issue. Please let me know how can I fix this ?

@akalana on debian 10

service jicofo restart

Thank you very much for the quick response. I did it. But issue is the same. And I am using Ubunu 18.04. Please have a look.

@akalana have you tried:

service jitsi-videobridge2 restart

?

when you access your jitsi instance on domain (webinterface) - whats in the console of your browser?

I already restart the JVB. And there are no errors in the console.

JVB 1 sip-communicator.properties file

JVB 2 sip-communicator.properties file

@akalana can you clearify what the problem is?

I need to test my octo setup is successfully works or not. Please let me know how can I test it.

@akalana sorry but on this topic I can’t help

maybe you can find someone here: Testing Octo Setup

Thank you very much for your support.

@akalana you are welcome - hope you are going to find your solution :slight_smile:

1 Like

@akalana I can see that your Octo relay is not starting up

@msansnom Tahnk you very much for the quick response. Please help me to sort out Octo relay issue.

I had the same issue, in my case, I was not able to bind to the local listen address on port 4096.

On JVB 1 use netcat to listen to port 4096 with UDP: nc -v -u -l -p 4096

On JVB 2 use netcat to connect to JVB 1 on 4096: nc -v -u -p 54321 bindaddress/publicaddress 4096

In my case, I had set the bind address the same as the public address which was causing issues for Octo Relay to be created. It looks like you didn’t do that, so maybe it is a firewall issue. Check the status of port 4096 using ufw or if you are on AWS check your security group’s inbound access rules.

@msansnom
I also have listened from JVB1’s netcat and then tried to connect from JVB2. It’s working without a problem. I’ve already opened the UDP 4096 from the AWS security group. When restart, after doing all that stuff, it appears OCTO relay is disabled. Feels like whether it’s an issue of the STUN/TURN server.
Another thing is, aren’t we supposed to set the particular server’s public address as the public address? Orelse it isn’t our jitsi meet server’s public address.isn’t that?I have applied it like that. But when restart, this issue occurs.

The public address is the public address of the JVB.

Can you try setting the local bind address to localhost as a test? I tried that first before setting to local IP.

@msansnom Yes I tried both ways but the thing is issue is same.

Looking at your other post, I realize you have inline comments that are not properly commented out. Remove all the # the address to bind to locally, # the port to bind to # the region that the … etc. They are being parsed.

@msansnom
Thank you very much. Finally I was able to fix the issue. There were two reasons for that, one was the issue of commets. And the other one, it was needed to give the Local IP as the bind address.
My first step has already completed. Then I’ll try to route to the specific JVB according to the search GeoIP’s location.