Architecture mismatch in Debian package for jitsi-videobridge2

I roughly followed the quick install on a Debian 10 machine:

After fixing some other issues, jitsi still didn’t work, and when looking for the cause I found this in /var/log/jitsi/jvb.log:

java.lang.UnsatisfiedLinkError: /tmp/nativeutils24002775908616/libjnisctp.so: /tmp/nativeutils24002775908616/libjnisctp.so: verkeerde ELF-klasse: ELFCLASS64 (Possible cause: architecture word width mismatch)

I’m working on a 32-bit i686 machine, so I don’t expect 64-bit binaries to work. I tried to figure out why it seemingly tries to load a 64-bit library, and I found that libjnisctp.so is included in /usr/share/jitsi-videobridge/lib/jniwrapper-native-1.0-SNAPSHOT.jar, and it is indeed an amd64 binary.

That jar fie belongs to the jitsi-videobridge2 package. The architecture of this package seems to be set to “all”, which explains why my package manager installed it without complaints.

The way I understand Debian packages, this is incorrect: a package that depends on a certain binary architecture should be marked as specific to that architecture. I believe the current package will also lead to problems on other alternative binary architectures, e.g. ARM or PPC. Feel free to propose other solutions, but I suggest compiling and offering different jitsi-videobridge2 packages for different architectures.

1 Like

Having the same problem with Debian 10 on 32bit computer. Also, I can have a proper call with video and audio between 2 people. However, when the 3rd person joins, the channel is still on but video and audio do not work (Everyone connects through local network).

jvb.log:

SCTP JNI load: Linux OS detected
OpenJDK Client VM warning: You have loaded library /tmp/nativeutils9063611331728/libjnisctp.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
2020-04-04 14:33:02.808 SEVERE: [16] RecurringRunnableExecutor.run#230: The invocation of the method org.jitsi.videobridge.health.Health.run() threw an exception.
java.lang.UnsatisfiedLinkError: /tmp/nativeutils9063611331728/libjnisctp.so: /tmp/nativeutils9063611331728/libjnisctp.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1946)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1828)
	at java.lang.Runtime.load0(Runtime.java:810)
	at java.lang.System.load(System.java:1088)
	at cz.adamh.utils.NativeUtils.loadLibraryFromJar(NativeUtils.java:109)
	at org.jitsi_modified.sctp4j.SctpJni.<clinit>(SctpJni.java:31)
	at org.jitsi_modified.sctp4j.Sctp4j.init(Sctp4j.java:40)
	at org.jitsi.videobridge.sctp.SctpManager.<clinit>(SctpManager.java:54)
	at org.jitsi.videobridge.Endpoint.createSctpConnection(Endpoint.java:709)
	at org.jitsi.videobridge.health.Health.check(Health.java:93)
	at org.jitsi.videobridge.health.Health.doCheck(Health.java:161)
	at org.jitsi.videobridge.health.Health.doRun(Health.java:266)
	at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)
2020-04-04 14:33:12.809 INFO: [16] Videobridge.createConference#326: create_conf, id=c8901ed99fb8037f gid=null logging=false
2020-04-04 14:33:12.838 SEVERE: [16] RecurringRunnableExecutor.run#230: The invocation of the method org.jitsi.videobridge.health.Health.run() threw an exception.
java.lang.NoClassDefFoundError: Could not initialize class org.jitsi.videobridge.sctp.SctpManager
	at org.jitsi.videobridge.Endpoint.createSctpConnection(Endpoint.java:709)
	at org.jitsi.videobridge.health.Health.check(Health.java:93)
	at org.jitsi.videobridge.health.Health.doCheck(Health.java:161)
	at org.jitsi.videobridge.health.Health.doRun(Health.java:266)
	at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
	at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

I am running into the same problem trying to run the videobridge on aarch64.

same problem here installing jvb2 on a rpi4 4 GB with ubuntu 18.04 aarch64.
I installed libsctp.so from “ppa.launchpad.net/dreibh/ppa/ubuntu bionic main”, but we need libjnisctp.so, which is not available from there. See also https://github.com/dreibh/sctplib - certainly someone knows how to build this properly, unfortunately I don’t.

1 Like

I believe the relevant source code is this project:

It doesn’t seem to contain the sources for the .so file directly, but it does contain some build infrastructure and instructions. I’ll try and see if I can make a build that way.

1 Like

I also found that repository after searching for libjnisctp.so, and was able to compile a version of the module that worked on aarch64. It did require a lot of hacky modifications to the build files to get the whole thing to compile, and in the end it built a .jar file that still contained a prebuilt version of the module. I had to replace the prebuilt module with the newly combined version to get the .jar to include the right version, but the videobridge is now running on an aarch64 server.

2 Likes

congrats, for my skills this seems too hacky - yesterday I decided to run my jitsi-meet instance in a debian 9.12 lxc3 container on a small centos 7.7 host (Gigabyte Brix w/i3-7100U) for now and perhaps try later with aarch64/rpi4 again.

Could you elaborate a bit more on how you did this? I would like to do the same for i686 Debian 9.

Where did you find the C sources for the libjnisctp.so - can’t we simply compile this and replace the .so in the JAR?

Best regards

--------- a few hours later -------
I did it the hard way. I compiled the whole jitsi-sctp package. Now it runs.

I also managed to get it running, but only when both devices are on the same network, using P2P. could you test if it still works with one device on another network(mobile data or so)?

I managed to build an i386 version of libjnisctp.so. I was planning to report on how I did it, but, sorry, it was too much of a nightmare to remember all the details. One hack I applied was, since jitsi-sctp depends on javah for its building and openjdk-11-jdk does not include javah, I made a script that emulated javah based on javac -h. I still didn’t manage to build a complete .jar file, but at least I got far enough to get this .so file:

http://ultimatestunts.nl/tmp/libjnisctp-linux-i386.so
SHA256sum: be53d3463936c68cb5e9440b2eb1c8e1fcb0a893659d7d0a44ae0495314562e1
On a quick glance, it seems to provide a similar set of symbols as the original libjnisctp.so.

I replaced libjnisctp.so in my installation with this file, and JVB now starts up without complaining or crashing. My Jitsi still doesn’t work though, so I can’t confirm this .so file is right. If it works for you, please let me know.

One of the other problems I encountered on my i686 machine is that Java tries to allocate too much virtual memory. I fixed this by adding VIDEOBRIDGE_MAX_MEMORY=1024m to /etc/jitsi/videobridge/config and adding -Xmx1024m to JAVA_SYS_PROPS in /etc/jitsi/jicofo/config. I hope this helps you, although, as I said, my setup still doesn’t work.

1 Like

Update: I managed to make a working Jitsi set-up, by completely re-installing Jitsi after removing and purging Jitsi’s packages and their dependencies (like nginx). Although I’m not happy with my current set-up yet, at least I’ll know the source of my issues if I move in small steps, and keep testing after every small change.

I’d like to share with you that, without the .so file replaced, Jitsi works with 2 participants (probably P2P mode), and breaks when a 3rd participant joins (probably non-P2P mode, where JVB becomes necessary). With the .so file replaced, Jitsi keeps working with 3 participants, so for now I assume my .so file is good.

This means I have a work-around for this issue. I still consider it an open issue though, that the jitsi-videobridge2 package doesn’t work out of the box for non-amd64 architectures.

Yes it seems to work. I had some strange behavior with more than 2 peers first. Not everyone could see everyone … But now I can’t reproduce this anymore. I guess this was not related to the sctp arch issue.

If you want to go the long way then

  • git clone jitsi-sctp
  • git clone usrsctp

The important thing is that usrsctp has to go to the right subdir in the jitsi-sctp tree:
jitsi-sctp-master/usrsctp/usrsctp

The other important thing is that you have to compile jitsi-sctp in two steps:
The first mvn package will partly fail. But you will find a libjnisctp-linux-i386.so in jitsi-sctp-master/jniwrapper/native/target

Copy this to native/src/main/resources/lib/linux/libjnisctp.so

After this, mvn package -DdeployNewJnilib will build the new jniwrapper-native-1.0-SNAPSHOT.jar (also in jitsi-sctp-master/jniwrapper/native/target )

Sometimes i have some problems when users are using firefox. With chromium everything is ok.
Anyway you can check /var/log/jitsi/jvb.log to see if it loads correctly jniwrapper-native.jar

Take a look here too https://github.com/jitsi/docker-jitsi-meet/issues/195
There are useful hints on the same problem. I compiled on aarch64 using dubit0 Dockerfile, and there is another good news: jitsi can work with 3+ participants without the need to compile anything, using websocket instead of data channels

Yes Firefox seem to have some issues.

The native JAR I built can be loaded without issue…

Thanks for the hint with the websockets! This sounds like and interesting alternative…