Fresh installed StratoStrechServer (Debian9) - Jitsi behaves strange (unable to create new native thread java.lang.OutOfMemoryError: unable to create new native thread)

Install & Config
#1

Hih - some an irritating problems with a fresh installation on debian 9 stretch.
I just installed my Strato server (or let them do it) and then installed jitsi:

1  . .bashrc
2  apt-get -y update && apt-get full-upgrade
3  apt-get -y install apache2
4  wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
5  sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
6  apt-get install apt-transport-https
7  apt-get -y update
8  apt-get -y install jitsi-meet
9  /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

I can reach the host - i can open a meeting but meeting.example.com/stayathome … (using chrome on windows 10 64 bit prof. latest updates)

  • there is no option to protect it via password
  • if i send a invitation, the other user can’t join my room - he opens a second room with the same name
  • if he opens a room - same as above - two rooms - but we can’t join - everyone just sees it on room
  • if i invite a third person … three rooms - everyone just sees his room
  • if i open a second browser on the same computer an open meeting.example.com/stayathome - another new room …
    Whats that? Please give me a hand. What further information do you need? Where are some helpfull logsfiles? Or where are my thoughts on the wrong way …
    I found a logfile:
    Jicofo 2020-03-29 20:07:40.696 SCHWERWIEGEND: [16] util.UtilActivator.uncaughtException().122 An uncaught exception occurred in thread=Thread[pool-5-thread-1,5,main] and message was: unable to create new native thread
    java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Thread.java:717)
    at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957)
    at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1025)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
    Jicofo 2020-03-29 20:07:48.359 SCHWERWIEGEND: [39] org.jitsi.xmpp.component.ComponentBase.log() Ping timeout for ID: ngyFr-221
#2

I had the same Problem. Switched to another Server Provider. Everything is working great now.

#3

as i found in an other post the server needs 8GB of RAM… :frowning: - would be nice to see the hardware requirements before installation :wink:

#4

i just updated my server to 8GB of RAM and restartet Jitsi again (systemctl status jitsi-videobridge2.service) - nothing has been changed.

#5

Hi Fensterkreuz,

please check How to debug jicofo memory errors? (jitsi-meet participants not seeing each other.)

May it will solve your problem too.

My jitsi-meet is running on a virtual Debian 9 with 8GB, also rent from strato (no idea how “1&1” came in my mind…).
I use this server since a couple of month for some other applications, means jitsi-meet is running there in addition with others - without any problem.

#6

Default deployments on systems using systemd will have low default values for maximum processes and open files. If the used bridge will expect higher number of participants the default values need to be adjusted (the default values are good for less than 100 participants). To update the values edit /etc/systemd/system.conf and make sure you have the following values:

**DefaultLimitNOFILE=65000**
**DefaultLimitNPROC=65000**
**DefaultTasksMax=65000**

be advised RTFM is always true … be attentive and look closely. It works ! Thank you

#7

and a reboot (or maybe # systemctl daemon-reexec did not tried this)

#8

DID updating this config file fix your error?