I’m running a Jitsi on a Ubuntu 18.04 server with 24 cpu-cores available in a proxmox VM.
I experience that Jicofo uses 100% of one cpu-core after the latest update. Without any conferences running.
This has to be a bug somehow, but there are no errors in any of the logs.
Can anyone confirm this?
These are the package version after the update this morning
I can confirm this, on a bare metal install (no VM) on Ubuntu 18.04. Filtering the jicofo.log file to lines with SEVERE since the update time, I get the following lines:
Jicofo 2020-05-01 08:28:41.006 SEVERE: [20] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.connectionClosedOnError().647 XMPP connection closed on error: system-shutdown You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
Jicofo 2020-05-01 08:28:41.025 SEVERE: [20] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.sendStanza().732 No connection - unable to send packet: <presence to='org.jitsi.jicofo.health.health-37ca3791a6051cb@conference.floridsdorf.mittenin.at/focus' id='RPk2A-293349'><x xmlns='http://jabber.org/protocol/muc'></x><etherpad xmlns='http://jitsi.org/jitmeet/etherpad'>a6a706bfe2cb4e73a68b36610c30128f</etherpad><versions xmlns='http://jitsi.org/jitmeet'><component xmlns='http://jitsi.org/jitmeet' name='xmpp'>Prosody(0.10.0,Linux)</component><component xmlns='http://jitsi.org/jitmeet' name='focus'>JiCoFo(1.0.549,Linux)</component></versions><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://jitsi.org' ver='n+eoWkt+V9Kbk4H9z2I7uDWU+68='/><conference-properties xmlns='http://jitsi.org/protocol/focus'><property xmlns='http://jitsi.org/protocol/focus' key='created-ms' value='1588314511520'/><property xmlns='http://jitsi.org/protocol/focus' key='octo-enabled' value='false'/><property xmlns='http://jitsi.org/protocol/focus' key='bridge-count' value='0'/></conference-properties></presence>
Jicofo 2020-05-01 08:28:41.511 SEVERE: [37] org.jitsi.jicofo.health.Health.log() No MUC service found on XMPP domain or Jicofo has not finished initial components discovery yet
Jicofo 2020-05-01 08:28:41.512 SEVERE: [37] org.jitsi.jicofo.health.Health.log() Health check failed in PT0.001S:
Jicofo 2020-05-01 08:28:42.190 SEVERE: [35] org.jivesoftware.whack.ExternalComponentManager.error()
Jicofo 2020-05-01 08:28:47.243 SEVERE: [1154] org.jitsi.xmpp.component.ComponentBase.log() Ping timeout for ID: RPk2A-293386
Jicofo 2020-05-01 08:28:54.777 SEVERE: [18] org.jitsi.jicofo.xmpp.BaseBrewery.start().191 Failed to create room: JvbBrewery@internal.auth.floridsdorf.mittenin.at
Jicofo 2020-05-01 08:28:54.840 SEVERE: [18] org.jitsi.impl.protocol.xmpp.OpSetSimpleCapsImpl.getFeatures().144 Failed to discover features for jitsi-videobridge.floridsdorf.mittenin.at: XMPP error reply received from jitsi-videobridge.floridsdorf.mittenin.at: XMPPError: service-unavailable - wait
Jicofo 2020-05-01 08:28:54.844 SEVERE: [18] org.jitsi.impl.protocol.xmpp.OpSetSimpleCapsImpl.getFeatures().144 Failed to discover features for focus.floridsdorf.mittenin.at: XMPP error reply received from focus.floridsdorf.mittenin.at: XMPPError: service-unavailable - wait
Jicofo 2020-05-01 08:51:45.998 SEVERE: [18] org.jitsi.jicofo.xmpp.BaseBrewery.start().191 Failed to create room: JvbBrewery@internal.auth.floridsdorf.mittenin.at
Jicofo 2020-05-01 08:51:46.060 SEVERE: [18] org.jitsi.impl.protocol.xmpp.OpSetSimpleCapsImpl.getFeatures().144 Failed to discover features for jitsi-videobridge.floridsdorf.mittenin.at: XMPP error reply received from jitsi-videobridge.floridsdorf.mittenin.at: XMPPError: service-unavailable - wait
Jicofo 2020-05-01 08:51:46.063 SEVERE: [18] org.jitsi.impl.protocol.xmpp.OpSetSimpleCapsImpl.getFeatures().144 Failed to discover features for focus.floridsdorf.mittenin.at: XMPP error reply received from focus.floridsdorf.mittenin.at: XMPPError: service-unavailable - wait
I single conference runs fine, video, audio and screensharing works as usual.
Same here - one conference with three participants seems to run ok.
BUT I don’t get any SEVERE entries in the jicofo.log - only normal INFO ones.
Still, this should be looked into by the developers, I guess
Downloading “jicofo_1.0-549-1_all.deb” and running “dpkg -i jicofo_1.0-549-1_all.deb” does the trick, without downgrading the other packages, too. At least for my installation.
Right, so forcing the downgrade of just the jicofo-package to 1.0-549-1 was possible for you.
But there must have been a reason for that package to be upgraded, one should think?
And “mistersixt” suggests above that it’s a loop-issue that causes the problem.
It would be better to fix the problem - if possible. And since it doesn’t seem to break anything I’m not quite sure what to choose here. Downgrade or leave it as it is…?
Of course a fix for the problem is needed, hopefully the developers will find and fix the bug (and adjust the package) soon. In the meantime it is up to the users whether to stick with the “new” version, whether to downgrade to the previous release, or to downgrade just the “jicofo” package.
Do we have a discussion here for alpha/beta testing (and reporting issues like this) ? I would like to do a test before upgrading the stable version on the production environment and submit a bug report (if there is any bug)
