Unable to find an available Jibri, but Jibri service was running


I installed jitsi-meet normally. And the jibri service
sudo systemctl restart jibri
You can now turn it on.

However, when I press the record button while entering the room, the /var/log/jitsi/jibri/log.0.txt does not have a related error and it says that it is authenticated as follows

2018-07-27 02:37:56.177 INFO: [40] class org.jitsi.xmpp.mucclient.MucClient.reconnectingIn() [record-test: auth.z.webzook.net@] Xmpp connection status: reconnecting in 0
2018-07-27 02:37:56.177 INFO: [40] class org.jitsi.xmpp.mucclient.MucClient.reconnectingIn() [record-test: auth.z.webzook.net@] Xmpp connection status: reconnecting in 0
2018-07-27 02:37:56.243 INFO: [40] class org.jitsi.xmpp.mucclient.MucClient.connected() [record-test: auth.z.webzook.net@] Xmpp connection status: connected
2018-07-27 02:37:56.267 INFO: [40] class org.jitsi.xmpp.mucclient.MucClient.authenticated() [record-test: auth.z.webzook.net@] Xmpp connection status: authenticated (resume from previous? false)

An error message is printed in the jicofo log.

Jicofo 2018-07-27 07:13:00.228 SEVERE: [90] org.jitsi.jicofo.recording.jibri.JibriSession.log() Unable to find an available Jibri, can’t start
Jicofo 2018-07-27 07:13:00.229 INFO: [90] org.jitsi.jicofo.recording.jibri.JibriRecorder.log() Failed to start a Jibri session, no Jibris available

root@z:/var/log/jitsi/jibri# ps -ef|grep jibri
jibri 20803 1 0 07:12 ? 00:00:03 java -Djava.util.logging.config.file=/etc/jitsi/jibri/logging.properties -jar /opt/jitsi jibri/jibri.jar --config /etc/jitsi/jibri/config.json
jibri 20806 1 0 07:12 ? 00:00:00 /usr/lib/xorg/Xorg -nocursor -noreset +extension RANDR +extension RENDER -logfile /tmp/xorg.log -config /etc/jitsi/jibri/xorg-video-dummy.conf :0
jibri 20807 1 0 07:12 ? 00:00:00 /usr/bin/icewm-session
jibri 20814 20807 0 07:12 ? 00:00:00 icewmbg
jibri 20815 20807 0 07:12 ? 00:00:00 icewm --notify
jibri 20830 20807 0 07:12 ? 00:00:00 icewmtray --notify
root 20881 2115 0 07:20 pts/0 00:00:00 grep --color=auto jibri

The services associated with jibri are also turned on.

I think jicofo does not recognize the jibri service that is on.
Looking at other issues, I do not think there is a case like me.

This is my configuration file

jibri was received via apt-get install jibri for the java version.


/* eslint-disable no-unused-vars, no-var */

var config = {

// Connection

hosts: {
    // XMPP domain.
    domain: 'z.webzook.net',

    // XMPP MUC domain. FIXME: use XEP-0030 to discover it.
    muc: 'conference.z.webzook.net'

    // focus: 'focus.z.webzook.net',

// BOSH URL. FIXME: use XEP-0156 to discover it.
bosh: '//z.webzook.net/http-bind',

// The name of client node advertised in XEP-0115 'c' stanza
clientNode: 'http://jitsi.org/jitsimeet',


testing: {
    // Enables experimental simulcast support on Firefox.
    enableFirefoxSimulcast: false,

    p2pTestMode: false


// Suspend sending video if bandwidth estimation is too low. This may cause
// problems with audio playback. Disabled until these are fixed.
disableSuspendVideo: true,

// The ID of the jidesha extension for Chrome.
desktopSharingChromeExtId: null,

// Whether desktop sharing should be disabled on Chrome.
desktopSharingChromeDisabled: true,

// The media sources to use when using screen sharing with the Chrome
// extension.
desktopSharingChromeSources: [ 'screen', 'window', 'tab' ],

// Required version of Chrome extension
desktopSharingChromeMinExtVersion: '0.1',

// Whether desktop sharing should be disabled on Firefox.
desktopSharingFirefoxDisabled: false,

// Whether to enable file recording or not.
fileRecordingsEnabled: true,
// liveStreamingEnabled: true,

hiddenDomain: 'recorder.z.webzook.net',
// Misc

channelLastN: -1,

// will be joined when no room is specified.
enableWelcomePage: true,

minHDHeight: 540,

enableUserRolesBasedOnToken: false,


p2p: {
    enabled: true,
    // The STUN servers that will be used in the peer to peer connections
    stunServers: [
        { urls: 'stun:stun.l.google.com:19302' },
        { urls: 'stun:stun1.l.google.com:19302' },
        { urls: 'stun:stun2.l.google.com:19302' }
    // is supported).
    preferH264: true
    // backToP2PDelay: 5

// the user region as seen by the server.
deploymentInfo: {
    // shard: "shard1",
    // region: "europe",
    // userRegion: "asia"


/* eslint-enable no-unused-vars, no-var */

############################# /etc/jitsi/jicofo/config









JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=jicofo -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/jicofo/logging.properties"

############################# /etc/jitsi/jicofo/sip-communicator.properties

org.jitsi.jicofo.ALWAYS_TRUST_MODE_ENABLED = true


############################# /etc/jitsi/jibri/config.json

// NOTE: this is a SAMPLE config file, it will need to be configured with
// values from your environment

// Where recording files should be temporarily stored
// The path to the script which will be run on completed recordings
"finalize_recording_script_path": "/path/to/finalize_recording.sh",
"xmpp_environments": [
        // A friendly name for this environment which can be used
        //  for logging, stats, etc.
        "name": "jibri-option",
        // The hosts of the XMPP servers to connect to as part of
        //  this environment
        "xmpp_server_hosts": [
        // The xmpp domain we'll connect to on the XMPP server
        "xmpp_domain": "z.webzook.net",
        // Jibri will login to the xmpp server as a privileged user
        "control_login": {
            // The domain to use for logging in
            "domain": "auth.z.webzook.net",
            // The credentials for logging in
            "username": "jibri",
            "password": "wlqmfl"
        // Using the control_login information above, Jibri will join
        //  a control muc as a means of announcing its availability
        //  to provide services for a given environment
        "control_muc": {
            "domain": "internal.auth.z.webzook.net",
            "room_name": "JibriBrewery",
            "nickname": "jibri-nickname"
        // All participants in a call join a muc so they can exchange
        //  information.  Jibri can be instructed to join a special muc
        //  with credentials to give it special abilities (e.g. not being
        //  displayed to other users like a normal participant)
        "call_login": {
            "domain": "recorder.z.webzook.net",
            "username": "recorder",
            "password": "wlqmfl"
        // When jibri gets a request to start a service for a room, the room
        //  jid will look like:
        //  roomName@optional.prefixes.subdomain.xmpp_domain
        // We'll build the url for the call by transforming that into:
        //  https://xmpp_domain/subdomain/roomName
        // So if there are any prefixes in the jid (like jitsi meet, which
        //  has its participants join a muc at conference.xmpp_domain) then
        //  list that prefix here so it can be stripped out to generate
        //  the call url correctly
        "room_jid_domain_string_to_strip_from_start": "conference.",
        // The amount of time, in minutes, a service is allowed to continue.
        //  Once a service has been running for this long, it will be
        //  stopped (cleanly).  A value of 0 means an indefinite amount
        //  of time is allowed
        "usage_timeout": "0"


############################# /etc/prosody/prosody.conf.lua

– Prosody Example Configuration File

– Information on configuring Prosody can be found on our
– website at http://prosody.im/doc/configure

– Tip: You can check that the syntax of this file is correct
– when you have finished by running: luac -p prosody.cfg.lua
– If there are any errors, it will let you know what and where
– they are, otherwise it will keep quiet.

– The only thing left to do is rename this file to remove the .dist ending, and fill in the
– blanks. Good luck, and happy Jabbering!

---------- Server-wide settings ----------
– Settings in this section apply to the whole server and are the default settings
– for any virtual hosts

– This is a (by default, empty) list of accounts that are admins
– for the server. Note that you must create the accounts separately
– (see http://prosody.im/doc/creating_accounts for info)
– Example: admins = { "user1@example.com", "user2@example.net" }
admins = { }

– Enable use of libevent for better performance under high load
– For more information see: http://prosody.im/doc/libevent
–use_libevent = true;

– This is the list of modules Prosody will load on startup.
– It looks for mod_modulename.lua in the plugins folder, so make sure that exists too.
– Documentation on modules can be found at: http://prosody.im/doc/modules
modules_enabled = {

    -- Generally required
            "roster"; -- Allow users to have a roster. Recommended ;)
            "saslauth"; -- Authentication for clients and servers. Recommended if you want to log in.
            "tls"; -- Add support for secure TLS on c2s/s2s connections
            "dialback"; -- s2s dialback support
            "disco"; -- Service discovery

    -- Not essential, but recommended
            "private"; -- Private XML storage (for room bookmarks, etc.)
            "vcard"; -- Allow users to set vCards

    -- These are commented by default as they have a performance impact
            --"privacy"; -- Support privacy lists
            --"compression"; -- Stream compression (Debian: requires lua-zlib module to work)

    -- Nice to have
            "version"; -- Replies to server version requests
            "uptime"; -- Report how long server has been running
            "time"; -- Let others know the time here on this server
            "ping"; -- Replies to XMPP pings with pongs
            "pep"; -- Enables users to publish their mood, activity, playing music and more
            "register"; -- Allow users to register on this server using a client and change passwords

    -- Admin interfaces
            "admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands
            --"admin_telnet"; -- Opens telnet console interface on localhost port 5582

    -- HTTP modules
            --"bosh"; -- Enable BOSH clients, aka "Jabber over HTTP"
            --"http_files"; -- Serve static files from a directory over HTTP

    -- Other specific functionality
            "posix"; -- POSIX functionality, sends server to background, enables syslog, etc.
            --"groups"; -- Shared roster support
            --"announce"; -- Send announcement to all online users
            --"welcome"; -- Welcome users who register accounts
            --"watchregistrations"; -- Alert admins of registrations
            --"motd"; -- Send a message to users when they log in
            --"legacyauth"; -- Legacy authentication. Only used by some old clients and bots.


– These modules are auto-loaded, but should you want
– to disable them then uncomment them here:
modules_disabled = {
– “offline”; – Store offline messages
– “c2s”; – Handle client connections
– “s2s”; – Handle server-to-server connections

– Disable account creation by default, for security
– For more information see http://prosody.im/doc/creating_accounts
allow_registration = false;

– Debian:
– send the server to background.

daemonize = true;

– Debian:
– Please, don’t change this option since /var/run/prosody/
– is one of the few directories Prosody is allowed to write to

pidfile = “/var/run/prosody/prosody.pid”;

– These are the SSL/TLS-related settings. If you don’t want
– to use SSL/TLS, you may comment or remove this
ssl = {
key = “/etc/prosody/certs/localhost.key”;
certificate = “/etc/prosody/certs/localhost.crt”;

– Force clients to use encrypted connections? This option will
– prevent clients from authenticating unless they are using encryption.

c2s_require_encryption = false

– Force certificate authentication for server-to-server connections?
– This provides ideal security, but requires servers you communicate
– with to support encryption AND present valid, trusted certificates.
– NOTE: Your version of LuaSec must support certificate verification!
– For more information see http://prosody.im/doc/s2s#security

s2s_secure_auth = false

– Many servers don’t support encryption or have invalid or self-signed
– certificates. You can list domains here that will not be required to
– authenticate using certificates. They will be authenticated using DNS.

–s2s_insecure_domains = { “gmail.com” }

– Even if you leave s2s_secure_auth disabled, you can still require valid
– certificates for some domains by specifying a list here.

–s2s_secure_domains = { “jabber.org” }

– Select the authentication backend to use. The ‘internal’ providers
– use Prosody’s configured data storage to store the authentication data.
– To allow Prosody to offer secure authentication mechanisms to clients, the
– default provider stores passwords in plaintext. If you do not trust your
– server please see http://prosody.im/doc/modules/mod_auth_internal_hashed
– for information about using the hashed backend.

authentication = “internal_plain”

– Select the storage backend to use. By default Prosody uses flat files
– in its configured data directory, but it also supports more backends
– through modules. An “sql” backend is included by default, but requires
– additional dependencies. See http://prosody.im/doc/storage for more info.

–storage = “sql” – Default is “internal” (Debian: “sql” requires one of the
– lua-dbi-sqlite3, lua-dbi-mysql or lua-dbi-postgresql packages to work)

– For the “sql” backend, you can uncomment one of the below to configure:
–sql = { driver = “SQLite3”, database = “prosody.sqlite” } – Default. ‘database’ is the filename.
–sql = { driver = “MySQL”, database = “prosody”, username = “prosody”, password = “secret”, host = “localhost” }
–sql = { driver = “PostgreSQL”, database = “prosody”, username = “prosody”, password = “secret”, host = “localhost” }

– Logging configuration
– For advanced logging see http://prosody.im/doc/logging

– Debian:
– Logs info and higher to /var/log
– Logs errors to syslog also
log = {
– Log files (change ‘info’ to ‘debug’ for debug logs):
info = “/var/log/prosody/prosody.log”;
error = “/var/log/prosody/prosody.err”;
– Syslog:
{ levels = { “error” }; to = “syslog”; };

----------- Virtual hosts -----------
– You need to add a VirtualHost entry for each domain you wish Prosody to serve.
– Settings under each VirtualHost entry apply only to that host.

VirtualHost “recorder.z.webzook.net
enabled = true – Remove this line to enable this host

    modules_enabled = {
    authentication = "internal_plain"
    -- Assign this host a certificate for TLS, otherwise it would use the one
    -- set in the global section (if any).
    -- Note that old-style SSL on port 5223 only supports one certificate, and will always
    -- use the global one.

Component “internal.auth.z.webzook.net” “muc”
modules_enabled = {
storage = “null”
muc_room_cache_size = 1000
------ Components ------
– You can specify components to add hosts that provide special services,
– like multi-user conferences, and transports.
– For more information on components, see http://prosody.im/doc/components

—Set up a MUC (multi-user chat) room server on conference.example.com:
–Component “conference.example.com” “muc”

– Set up a SOCKS5 bytestream proxy for server-proxied file transfers:
–Component “proxy.example.com” “proxy65”

—Set up an external component (default component port is 5347)

– External components allow adding various services, such as gateways/
– transports to other networks like ICQ, MSN and Yahoo. For more info
– see: http://prosody.im/doc/components#adding_an_external_component

–Component “gateway.example.com
– component_secret = “password”

------ Additional config files ------
– For organizational purposes you may prefer to add VirtualHost and
– Component definitions in their own config files. This line includes
– all config files in /etc/prosody/conf.d/

Include “conf.d/*.cfg.lua”


I ran into a similar problem recently. In my case, the XMPP server was shutdown momentarily and it caused Jibri disconnected and attempted to reconnect. Once it was reconnected to XMPP server successfully, but it didn’t re-join the control MUC JibriBrewery. Although Jibri was running, Jicofo did not receive any presences of the Jibri from the control MUC. Therefore, Jicofo didn’t think that there was a Jibri available. I haven’t confirmed this problem with the Jibri community yet, but that is what I observed. As a temporary workaround, try to restart Jibri. As a permanent fix, Jibri should join the control MUC when “jibri” was authenticated.


I vaguely remember this being a bug (not rejoining the MUC) and something we fixed a while back. Were you on the latest Jibri version?


@bbaldino Unfortunately we are not using the latest Jibri (we do realize this out-of-sync issue.) Our environment is based on the 2018-05-01 Jitsi-meet stable release, so we are using the 2018-05-09 snapshot Jibri build. Let me cherry-pick your fix and see if it fixes the problem. Thanks for the update.