Jitsi-Meet - Videobridge broken after reboot

I configured Jitsi on NixOS 20.09 using an external load-balancer which provides SSL termination and the host running NixOS is behind a NAT router. So far so good, it is working until I reboot the NixOS machine. Videobridge reports the following error (journalctl --unit jitsi-videobridge2). It works again, if I restart videobridge (sudo systemctl restart jitsi-videobridge2);

Here is my configuration:

  services.jitsi-meet = {
    enable = true;
    hostName = "meet.nowhere.tld";
    nginx.enable = true;
  services.jitsi-videobridge = {
    openFirewall = true;
    nat = {
      localAddress = "";
      publicAddress = "<MY-EXTERNAL-IPv4-IP>";
  services.nginx.virtualHosts."meet.nowhere.tld".enableACME = false;
  services.nginx.virtualHosts."meet.nowhere.tld".forceSSL = false;

Any ideas, why videobridge is working after I manually restart the service (sudo systemctl restart jitsi-videobridge2)?

Update: I included a link to the logs.

1 Like

your logs got strangely truncated on this post? not sure why?

This must be something to do with the way systemd is spinning up the services. It depending onsomething that isn’t available yet?

However, it seems the service sets up a systemd service that does depend on

after = [ "network.target" ]

which makes it wait for the network stack to come up before it runs the service.

the (partial incompete) error log you posted, it’s failing trying to connecting XMPP. Is it trying
to connect to some XMPP server somewhere (localhost/other) that not had chance to spin up yet?

Maybe it’s trying to connect to the jitsi service component, and that’s not had chance to start yet.

This smells like service startup ordering problem to me, or some kind a race connection between the networking stack, firewall and/or application startup.

Just ideas…

1 Like

Thank you. I updated my post with logs included from a gist. Yeah I’m also thinking about a race condition with the start ordering. Unfortunately I don’t have a clue currently.