bigbluebutton-Github/record-and-playback/core/systemd/bbb-rap-archive-worker.service

[Unit]
Description=BigBlueButton recording and playback archive worker
ConditionPathExistsGlob=/var/bigbluebutton/recording/status/recorded/*.done

[Service]
Type=simple
ExecStart=/usr/local/bigbluebutton/core/scripts/rap-archive-worker.rb
WorkingDirectory=/usr/local/bigbluebutton/core/scripts
User=bigbluebutton
Slice=bbb_record_core.slice
record-and-playback: Split rap-worker into separate workers per step. The purpose of this is to ensure that the recording processing with make visible forwards progress, by ensuring that different steps in the recording pipeline don't block each-other. This fixes: - recordings being processed prevent archiving new recordings from running - recordings can't be published until all pending recording processing completes It does allow recording archive, sanity, process, publish steps to run in parallel with each other, but at most one recording will be in each step at a time. (I.e. while one recording is being processed, a different recording can be published). This may potentially increase CPU usage for some users. If you expect this to be a problem, you can set resource controls (see `man systemd.resource-control`) on the bbb_record_core.slice systemd unit. 2017-03-23 04:27:05 +08:00			`[Unit]`
			`Description=BigBlueButton recording and playback archive worker`
			`ConditionPathExistsGlob=/var/bigbluebutton/recording/status/recorded/*.done`

			`[Service]`
			`Type=simple`
			`ExecStart=/usr/local/bigbluebutton/core/scripts/rap-archive-worker.rb`
			`WorkingDirectory=/usr/local/bigbluebutton/core/scripts`
Use the right `bigbluebutton` user for recording directories. 2019-02-09 00:53:57 +08:00			`User=bigbluebutton`
record-and-playback: Split rap-worker into separate workers per step. The purpose of this is to ensure that the recording processing with make visible forwards progress, by ensuring that different steps in the recording pipeline don't block each-other. This fixes: - recordings being processed prevent archiving new recordings from running - recordings can't be published until all pending recording processing completes It does allow recording archive, sanity, process, publish steps to run in parallel with each other, but at most one recording will be in each step at a time. (I.e. while one recording is being processed, a different recording can be published). This may potentially increase CPU usage for some users. If you expect this to be a problem, you can set resource controls (see `man systemd.resource-control`) on the bbb_record_core.slice systemd unit. 2017-03-23 04:27:05 +08:00			`Slice=bbb_record_core.slice`