Jibri Fatal Crash If No Recording Directory

Developers
#1

I a not sure where to report, but I found this interesting bug. My directory for recording did not exist on my server. And I get this error message:

2022-07-30 10:21:15.870 INFO: [46] [session_id=hedbtpxkambhiulg] FileRecordingJibriService.<init>#134: Writing recording to /srv/recordings/hedbtpxkambhiulg, finalize script path /srv/finalize_recording.sh
2022-07-30 10:21:15.876 FINE: [46] JibriStatsDClient.incrementCounter#38: Incrementing statsd counter: start:recording
2022-07-30 10:21:15.876 INFO: [46] JibriStatusManager$$special$$inlined$observable$1.afterChange#72: Busy status has changed: IDLE -> BUSY
2022-07-30 10:21:15.877 FINE: [46] WebhookClient$updateStatus$1.invokeSuspend#107: Updating 0 subscribers of status
2022-07-30 10:21:15.877 INFO: [46] XmppApi.updatePresence#203: Jibri reports its status is now JibriStatus(busyStatus=BUSY, health=OverallHealth(healthStatus=HEALTHY, details={})), publishing presence to connections
2022-07-30 10:21:15.879 INFO: [46] XmppApi.handleStartJibriIq#275: Sending 'pending' response to start IQ
2022-07-30 10:21:15.884 SEVERE: [55] [session_id=hedbtpxkambhiulg] FileUtilsKt.createIfDoesNotExist#28: Error creating directory
java.nio.file.AccessDeniedException: /srv/recordings
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
	at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:389)
	at java.base/java.nio.file.Files.createDirectory(Files.java:690)
	at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:797)
	at java.base/java.nio.file.Files.createDirectories(Files.java:783)
	at org.jitsi.jibri.util.FileUtilsKt.createIfDoesNotExist(FileUtils.kt:26)
	at org.jitsi.jibri.service.impl.FileRecordingJibriService.start(FileRecordingJibriService.kt:153)
	at org.jitsi.jibri.JibriManager$startService$3.run(JibriManager.kt:239)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

So the fix is easy - just make the directory and the problem is solved. The concern part is after Jibri crashes, it does not restart and is not longer available. I have to manually restart the Jibri service to make available again.

#2

I don’t think these are bugs, because in config.jibri /srv/finalize_recording.sh and /srv/recordings they are examples of path you have to create them and you give it the permission on the folder and the file, you can even change the name and the path, it’s normal when you change something you have to restart jibri to apply the new configuration

1 Like
#3

Right, I agree that you woul dhave to restart to change the configuration. Thats not the issue. To better illustrate, they says I poll for the number of available jibris:

{“jibri_detector”:{“count”:2,“available”:2}}

So I have two available and 2 total. Now I start the recording and it crashes. When I poll again:

{“jibri_detector”:{“count”:1,“available”:1}}

After that error, the jibri instance in gone until I manually restart it.

#4

Sorry, I didn’t think you had a multiple jibri I thought it was a single instance

#5

It’s not a bug. If the service is down (crashed), there is nothing to poll. It is at that stage inactive and not registering, so it can’t be detected. jibri_detector polls active and healthy Jibri instances.

#6

I see your perspective. From my POV, I do both live streaming and recording. Should the instance “crash” because recording failed due to unable to create a directly while livestreaming will still work?

#7

A missing directory triggers a fatal error. A fatal error crashes and immobilizes the service. When the service is immobilized (inactive), it can’t be polled. A manual restart is needed.