AUD: “no video” (yet working in settings, compatible browser, but very verbose log)

Hi!

I don’t like SaaSS, but I’d rather prefer my fellow who only use a browser to use something compatible with not using one and I can trust, so I installed jitsi there: meet.galex-713.eu.

First time it worked, then it took like 5-6 of CPU load while not being used, with a tons of java thread, so I did service jitsi-videobridge stop, and as it didn’t change anything (cpu load was still high and java still there), I did stop apache2 then prosody, and as it still didn’t do anything I did killall -9 java and it worked.

After noticing it didn’t work anymore, I uninstalled everything, using purge, then autoremove --purge, then tracked any .pid file remaining, anything beginning by “ji” (jitsi, jicofo, jigasi, etc.) or “prosody” and erased it, several times. And only after then I freshly reinstalled, with clean certificate and such.

And it still doesn’t work.

I asked friends to try it out and it doesn’t work for them, while other jitsi services such as framatalk.org work fine for us. We can see ourselves and our microphone input in the “settings” window without problem. Some of them even were unable to create new room and got 404 errors (so they joined “test” room with me), and I’m still unable to create the “galex-713” room too, it gives the very same 404 error.

Now I got the jvb.log: paste.debian.net/1061873/ (it’s so verbose I can’t directly tell what’s an abnormal error and what’s not, I don’t understand much anyway: whenever it’s related to a concept I may know, I’m totally unable to see it linked with any commandline program, configuration file or program I might interact with)

I guess you can check out the browser log yourself… I’m not very aware of how to use it, or even how to barely copy/paste stuff from it…

Any idea?

First time it worked.

Also, meet.galex-713.eu, and galex-713.eu so far, has directly (without any NAT) 4 public IPs, whose one v4 and one v6 you can find in DNS. I also have two other public IPv6 from another operator, and two local IPv4 behind a NAT behind another public IPv4. If that could cause problem.

Proxing bosh requests is not working try to open https://meet.galex-713.eu/http-bind, the output should look like https://meet.jit.si/http-bind.

As I guess jitsi installation is normally supposed to do, my prosody already have a virtual host enabling bosh (I enabled it for the main host now) and having correct certificate, and the apache virtual host it automatically created automatically redirect correctly http-bind, so I can’t get why is this not working. But now I get this is maybe the fault of prosody… which surprise me as only java stuff bugged me.

So here the virtual host jitsi created (it should be as normal, I guess): http://paste.debian.net/1061887/

Here the default prosody configuration: I’m under debian stable, maybe this changed from yours, or other installations: http://paste.debian.net/1061886/

Here prosody.log (prosody.err is empty), whole: http://paste.debian.net/1061885/

Mmmh… as you can see, I don’t see any line related to bosh at all in prosody.log when trying to connect (I tried to see contemporaneously with tail -f). Thinking to it, I can’t be sure, but maybe I should, so I tried to look at apache2/access.log the same way, and as I found nothing either, here error.log: http://paste.debian.net/1061888/

Here apache2 virtualhost config I have (I added gnutls support because otherwise it wasn’t working since my server always used gnutls): https://paste.debian.net/1061917/

What’s this error? why doesn’t it show on prosody side?

(Damn, I see how all the piece of software are interacting one between the others, it’s beautiful, so sad I can’t make it work)

Just to tell: bosh port is advertised as open according nmap localhost. Bosh works when called on port 5281 (https) from firefox and from both 5280 and 5281 from curl.

Apache seems to stall forever… any idea of why?

What other information can I bring?

Here aaaaaall the logs: https://paste.debian.net/1061999/

This came to my attention: “java.lang.RuntimeException: java.net.SocketException: Trop de fichiers ouverts (Error creating socket)” (“Trop de fichiers ouverts” means “Too many files opened”, sorry for the french, apparently the system being set in french is enough for jitsi to log errors in french (maybe it’s GNU libc translations though, not jitsi’s))

So I did sudo bash -c ‘for dir in /proc/*/fd ; do echo -n $dir:; ls $dir | wc -l ; done | sort -k2 -t: -n’

And indeed, process #21323, java, has 4096 files opened. So I did sudo ls --color -lv /proc/21323/fd/, and pretty much all of these are broken links to sockets. Why so much sockets? why did it work before and doesn’t it work anymore?

Here again a latest excerpt (256 lines) of my looong loooong jvb.log: http://paste.debian.net/1062001/

Here the javascript console I finally manage to more-or-less somehow copy-paste (but it has javascript filenames interleaved and has bits of french here and there): https://paste.debian.net/1062004/

After jvb restart, less files errors, but still doesn’t work: https://paste.debian.net/1062006/

Have you looked on fixing the http-bind? What is your webserver config for matching and proxing it? Is the address and port correct and is there a process listening on that address and port?

Yes I tried very hard and asked prosody and apache httpd people by both chat and mail and we think it’s related to apache but no more info.

Sorry I must have put confusingly too much informations in my previous posts if you didn’t see the apache vhost config I posted (https://paste.debian.net/1061917/), here a new version, with some tries, nothing changed in behavior: https://paste.debian.net/1062011/

And yes, as said, if you try to see at https://meet.galex-713.eu:5281/http-bind you’ll see the right message (“it works!”, etc. with the appropriate link to prosody doc’), same with http://meet.galex-713.eu:5280/http-bind if hsts doesn’t interfere, then you should try with curl (personally it works in localhost because no hsts). And there are not any apache log line popping when trying to get https://meet.galex-713.eu/http-bind, it just stalls forever.

So yeah that proxy is not working properly. Someone from prosody who said me they already did like that suggested me to change the bosh url in config.js to put something like https://meet.galex-713.eu:5281/http-bind, and now I got a different error, so maybe there was progress, maybe not, I am a bit lost as nobody from apache, prosody or here seems to see where does the problem comes from exactly…

Okay now I accidentally made it work, so to me that’s an even bigger problem.

So, whenever jvb.log says “too much file opened” I do “service jitsi-videobridge restart”, and now I saw these “component not connected” about “focus.meet.galex-713.eu” I saw several times in the logs I posted (in prosody’s ones, to be exact), I investigated for that hostname in your jitsi prosody config, and found a secret to be found only in jicofo config.

I checked with “service jicofo status”, and it said it worked fine, it only had this strangely empty log jicofo.log… But whatever…

So I did “service jicofo restart” and now it unexpectedly works. I just wanted that error to disappear, now done.

So, to resume: I had to change bosh address not to use local proxy again because it strangely doesn’t work (stalls forever), then to add CORBS support (both “consider_bosh_secure = true” and “cross_domain_bosh = true”, because I keep forgetting (or not understanding?) what each of these do, how, why, and why isn’t it there by default) in every single virtualhost and component because I kept having these cross-stuff errors in javascript console, then to restart jvb (“service jitsi-videobridge restart”) because it is, for single-person conversation from time to time, opening more than 4096 files (sockets, to be precise) at the same time, without closing any of these (why???), and then I had to restart jicofo so it to correctly connects to prosody (“service jicofo restart”, but I still don’t know what a component ever is, or how does it connects, or even what does jicofo does at all).

After installation it just worked. Since that “killall java” everything began to strangely going wrong, for reasons I totally ignore, even after total erasure and reinstallation. So the default must be working, but I had to tweak them to make it work again. I’m pretty sure there’s a problem here, I don’t know if it’s from me, you or debian. I’m afraid that it stops working again and I fell regularly obligated to do unknown dark magic to make it work again. I’d like to know what I did to make it stop working, and, even more, to make it work again.