Jicofo new config (jicofo.conf) are not being loaded

Hello!

So far, we have not used the new config file “jicofo.conf”, we have only been using sip-communicator.properties.
But now, we are trying to config ‘average-participant-stress’ that seems to only be available in the new config format.

Although I added “-Dconfig.file=/etc/jitsi/jicofo/jicofo.conf” to JAVA_SYS_PROPS, this file does not seem to be loaded. Jicofo keeps only loading sip-communicator.properties.

Would you guys have any suggestions about how debug it?

These are the logs:

Jicofo 2020-12-21 19:42:38.360 INFO: [10] org.jitsi.impl.configuration.ConfigurationServiceImpl.log() config.file=/etc/jitsi/jicofo/jicofo.conf
...
Jicofo 2020-12-21 19:42:38.825 INFO: [10] JitsiConfig.log() Initialized newConfig: merge of system properties,/etc/jitsi/jicofo/jicofo.conf: 1,system properties,reference.conf @ jar:file:/usr/share/jicofo/jicofo.jar!/reference.conf: 1,reference.conf @ jar:file:/usr/share/jicofo/lib/ice4j-3.0-21-g3a55627.jar!/reference.conf: 1
Jicofo 2020-12-21 19:42:38.826 INFO: [10] org.jitsi.config.ReadOnlyConfigurationService.log() loading config file at path /config/sip-communicator.properties
Jicofo 2020-12-21 19:42:38.827 INFO: [10] JitsiConfig.log() Initialized legacyConfig: sip communicator props (no description provided)

Thank you!

When you run ps aux | grep -i jicofo, what do you see? Do you see the -Dconfig.file argument passed there?

Thank you for your message,
Yes, this is what I see:

jicofo     201  0.1  0.3 13159532 127540 ?     Ssl  19:42   0:11 java -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djdk.tls.ephemeralDHKeySize=2048 -Dconfig.file=/etc/jitsi/jicofo/jicofo.conf -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/ -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=config -Djava.util.logging.config.file=/config/logging.properties -cp /usr/share/jicofo/jicofo.jar:/usr/share/jicofo/lib/agafua-syslog-0.4.jar:/usr/share/jicofo/lib/annotations-15.0.jar...

I made a simple jicofo.conf, just with one option, that I could easily test if it is being loaded, the health check. But it does not work.

jicofo {
  health {
    enabled = true
  }
}

However, it does work when I place org.jitsi.jicofo.health.ENABLE_HEALTH_CHECKS=true in the sip-communicator.properties.

Did you omit it completely from sip-communicator.properties when you were trying to verify it in jicofo.conf? For backwards compatibility, we always check for a value in sip-communciator.properties first.

Yes, I tested it again to confirm it.
This is the cat /config/sip-communicator.properties:

org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED=true
org.jitsi.jicofo.BRIDGE_MUC=jvbbrewery@internal-muc.<my-domain>
org.jitsi.jicofo.XMPP_MUC_COMPONENT_PREFIX=muc
org.jitsi.jicofo.BridgeSelector.BRIDGE_SELECTION_STRATEGY=IntraRegionBridgeSelectionStrategy

We apt install jicofo=1.0-644-1 in the container jitsi/base-java:stable-4627-1

This is the /etc/services.d/jicofo/run

#!/usr/bin/with-contenv bash

JAVA_SYS_PROPS="-Dconfig.file=/etc/jitsi/jicofo/jicofo.conf -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/ -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=config -Djava.util.logging.config.file=/config/logging.properties"
DAEMON=/usr/share/jicofo/jicofo.sh
DAEMON_DIR=/usr/share/jicofo/
DAEMON_OPTS="--domain=$XMPP_DOMAIN --host=$XMPP_SERVER --secret=$JICOFO_COMPONENT_SECRET --user_name=$JICOFO_AUTH_USER --user_domain=$XMPP_AUTH_DOMAIN --user_password=$JICOFO_AUTH_PASSWORD"

exec s6-setuidgid jicofo /bin/bash -c "cd $DAEMON_DIR; JAVA_SYS_PROPS=\"$JAVA_SYS_PROPS\" exec $DAEMON $DAEMON_OPTS"

This has been running for a while without a problem. The only problem is that we cannot load configs from /etc/jitsi/jicofo/jicofo.conf.

Can you try setting org.jitsi.config.level = FINE in logging.properties ? And then try again and attach your jicofo log?

@bbaldino
reproduced it.
I wonder about these messages:

Jicofo 2020-12-22 09:02:30.460 INFO: [13] org.jitsi.impl.configuration.ConfigurationServiceImpl.log() failed to find jitsi-defaults.properties with class loader, will continue without it.
Jicofo 2020-12-22 09:02:30.463 INFO: [13] org.jitsi.impl.configuration.ConfigurationServiceImpl.log() Normal classloader
Jicofo 2020-12-22 09:02:30.469 INFO: [13] org.jitsi.impl.configuration.ConfigurationServiceImpl.log() failed to find jitsi-default-overrides.properties with class loader, will continue without it.

edit: this is with unstable not quite last version. I will try to update right now.
edit2: no it works. I did something stuuupid.

task-pools {
  jicofo.task-pools.shared-pool-max-threads=350
 }

instead of

task-pools {
  shared-pool-max-threads=350
 }

Yes, sure, it is attached. Thank you!

studio-jicofo.log (42.1 KB)

Thank you for your test @gpatel-fr!

From those logs it does appear it’s loading jicofo.conf:

Jicofo 2020-12-22 11:11:18.769 INFO: [10] JitsiConfig.log() Initialized newConfig: merge of system properties,/etc/jitsi/jicofo/jicofo.conf: 1,system properties,reference.conf @ jar:file:/usr/share/jicofo/jicofo.jar!/reference.conf: 1,reference.conf @ jar:file:/usr/share/jicofo/lib/ice4j-3.0-21-g3a55627.jar!/reference.conf: 1

Which key are you trying to override? jicofo.health.enabled? I’m not seeing that even accessed in the logs, it seems. Which version of Jicofo is this?

Yes, this is the key jicofo.health.enabled, but I only used this because that was easy for me to test if it jicofo.conf was loaded or not. The real key that I need is jicofo.bridge.average-participant-stress. The version of Jicofo is 1.0-644-1.

This is the file and its content:
-rw-r--r-- 1 root root 45 Dec 21 22:20 /etc/jitsi/jicofo/jicofo.conf

jicofo {
  health {
    enabled = true
  }
}

Ah, well this would explain why…that version of Jicofo doesn’t even have that field defined in new config :slight_smile: I didn’t realize we hadn’t done a stable Jicofo release in so long.

You can look at supported config params for that version of Jicofo here

:man_facepalming: This is true…
Sorry for your that. And thank you very much for your help.
It is loading the config, but it is not performing what I expect.
But, for sure it is just because I misunderstood the idea of average-participant-stress configuration.

So, I created a new post to not mix the subjects:

Thank you very much!

1 Like