Killing zombies in meetings

We have a jitsi server in the company that is used for some recurring meetings (i.e. meetings where we reuse the room name). Somehow some of my colleagues have managed to get a zombie connection to those meetings, i.e. whenever anybody connect to /meeting it seems like A, B and C are already there, but in fact the aren’t. It makes it hard to find out if everybody is actually there and the moderator rights are given to some of those zombie connections, so there is no real user that can kick them out.

But we all have root access to the server (maybe there are some meetings I don’t participate in, that have similar problems and where that’s not the case), so is there a way for us to see which meetings are active on the server, which participants they have and a way to close a connection a “participant” has to a meeting?

Running netstat -tnlp on the server, I can see a number of established connections, but I from that I can’t tell whether those are in use in ongoing meetings or zombies in meetings that are actually not active (from a suitable perspective).

Can I (in cooperation with the colleagues who have these zombie connections) do anything about them?

Are you using prosody 0.10? If so update to 0.11

? Have you gotten some things mixed up?

Prosody? We do have a prosody running, but I believe that to be quite unrelated.

You also cite something that is not my question.

(But just to comment on the only semi-relevant part of the quoted: I’m not the one who installed our internal jitsi server.)

If you are talking about ghost participants, those come from what I’ve mentioned. Many people reported the problem with 0.10 and upgrading to 0.11 fix that.

I don’t know which version our prosody is, and can’t check as I don’t remember which server it is on (but it is a different one from jitsi, on a different network).

Why would prosody be involved when it’s on a different server and prosody hasn’t been involved in some of the meetings (either in scheduling or inviting participants)? And the servers surely can’t communicate.

@grove one of the devs who actually built the platform is telling you what the problem likely is and you’re being snarky in your dissent, without even trying the suggested fix first. You can’t be serious about wanting to fix your problem.

  • Find out what version of Prosody your Jitsi server runs on. If you don’t know how to, search on google
  • If you don’t know your server architecture, no one can help you with that. Again, refer to the first point.
  • If many people have been said to report having the same problem on a previous version of Prosody and upgrading to a more current version fixed the problem, doesn’t it make sense that that’s the likely fix?

You clearly don’t understand the Jitsi environment if you’re questioning the place of Prosody. Perhaps you should spend some time leafing through the scores of information available, rather than stumping your feet on the ground insisting on things you’re clearly not knowledgeable about?

1 Like

I hadn’t looked enough at jitsi to realise that it depended on prosody. To me they were two pieces of software accomplishing quite different tasks, and we have been running prosody quite a lot longer (but I’ve realised that installation is pretty irrelevant) than we have had a jitsi installation, I could imagine some synergy between the two, so I assumed they were not related, but prosody maybe an optional dependency. That was wrong, sorry for not looking at the dependencies sooner.

Upgrading is a bit more work than I was prepared to put into this, also because I have colleagues (I’ll tell them that a newer prosody might help) who has plans to do other things with our jitsi installation.

This post was flagged by the community and is temporarily hidden.