If FFmpeg exits during a church sermon stream, a systemd service can start it again after qualifying failures. Set Restart=on-failure and a deliberate RestartSec= delay, then check that YouTube has actually restored the broadcast; a relaunched process is not proof that viewers can see it.
That approach only covers failures systemd can observe at the process level. If FFmpeg remains alive but its output has stopped reaching YouTube, investigate the output and protocol behaviour separately rather than expecting the service restart policy to notice.
Determine whether FFmpeg exited or output failed
Begin with the distinction that decides what to troubleshoot: did the FFmpeg process stop, or is it still running while the stream output is broken? Systemd can act on a process that exits with a qualifying failure. It cannot infer that a live process has stopped sending useful video merely because YouTube’s preview is frozen or absent.
Check the service state and the recent FFmpeg log around the time of the interruption. If systemd reports that the service is inactive or failed, note the exit status and read the first relevant FFmpeg error, not just the final line. If the process remains active, inspect its continuing output and YouTube’s encoder preview. An active state tells you that a process exists; it does not tell you that its input is readable, its output connection is healthy, or the intended event is live.
A few different causes can look alike from a congregation member’s report that “the stream is down”. The input file or capture source may have become unavailable. The network path may have failed. YouTube may reject the publishing connection, or the stream may be reaching an encoder preview without the scheduled event being started. These require different checks. Repeatedly restarting an unchanged command will not correct a bad key, an inaccessible source, or a persistent configuration error.
Keep a short record of the timestamp, service state, first error, and what Live Control Room showed. That makes it easier to distinguish a one-off process exit from a repeatable output fault. If the service is not yet under supervision, first decide where FFmpeg should run and how the stream is meant to repeat; the guide to looping prerecorded videos on YouTube Live explains the playback side of that arrangement.
Run FFmpeg as a systemd service
For a Linux host that uses systemd, run FFmpeg as the foreground main process of a long-running service. The key point is that systemd must supervise the process that actually performs the encoding and publishing. Avoid a shell wrapper that exits after starting FFmpeg in the background: systemd might then supervise the wrapper rather than the encoder, leaving the real process unmanaged.
A unit file has a service description, a start command, restart behaviour, and an installation target. The following is an illustrative shape, not a tested universal command:
[Unit]
Description=Church YouTube sermon stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/bin/ffmpeg [the church’s actual input and encoding options] -f flv [YouTube ingest URL and stream key]
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
Replace the placeholders with the actual input, codecs, options, and YouTube destination used by your setup. Confirm the FFmpeg binary path and the permissions needed by the service account to read the sermon media or capture device. The sample delay is only a starting point for discussion, not a universal setting or a claim that a particular host has been tested. Check your installed systemd version and its documentation if a directive behaves differently than expected.
YouTube’s encoder setup instructions describe using the Live server URL and stream key in an encoder. Treat the stream key as a credential: restrict access to the unit and its configuration, and do not paste it into a public support post or an unprotected log. If the key has been exposed, use YouTube’s current controls to replace it and update the service configuration.
After creating or changing the unit, follow the normal systemd workflow on that host to reload unit definitions, enable the service if it should start at boot, and start it. Then inspect the loaded state rather than assuming that saving the file applied the change. Basic checks include systemctl status <service> and journalctl -u <service> -f; substitute the actual unit name. A service that starts successfully proves only that systemd launched its main process, not that the full publishing path is working.
If you are choosing between a local machine and a managed way to keep a prerecorded devotional stream running, consider the operational trade-offs described in how to start a 24/7 devotional YouTube stream in India. The relevant question here is not which setup is universally best, but whether you can maintain the host, source file, credentials, and checks this service needs.
Set restart-on-failure behaviour and a deliberate delay
Restart=on-failure tells systemd to attempt a restart when the service process fails in qualifying ways, such as a non-zero exit or certain abnormal terminations, timeouts, or watchdog failures. The systemd manual calls this the recommended choice for long-running services when automatic recovery from errors is wanted. It does not mean that every possible output failure triggers a restart. A process that remains alive while a publishing connection is unusable may not have failed from systemd’s point of view.
A deliberate RestartSec= value controls how long systemd waits before trying again. The systemd service manual lists a default of 100 milliseconds when no value is set. That default is not necessarily suitable for a sermon stream. A very short delay can produce rapid repeated attempts when the cause is persistent, while a longer delay means a longer interruption before another attempt. Choose a delay for your expected failure and investigation process rather than copying a value without thought.
The example uses 5s, but that is an illustrative choice, not a measured optimum. If an input file is temporarily unavailable during a planned hand-off, a pause might be useful. If the key is invalid or YouTube continues to reject the connection, waiting a little longer will not repair it. Observe what happens on the actual host and adjust only with a reason.
Systemd also applies start-rate limits. If a service fails too many times within the configured interval, systemd can stop trying until you investigate and reset or otherwise resolve the unit’s state. That is a guard against a tight failure loop, not a substitute for diagnosing the cause. When testing, watch whether the service is restarting, has reached a start limit, or was deliberately stopped. A deliberate systemctl stop should not be undone by the restart policy.
Think of this configuration as a controlled recovery for process failure, not an unattended guarantee. When FFmpeg exits because a transient condition cleared, a fresh process may reconnect and publish again. When the same command immediately encounters the same permanent error, systemd may faithfully repeat the failure. Preserve enough log context to recognise that pattern rather than treating a growing restart count as evidence of recovery.
Check logs and restart behaviour
Follow the service journal during a planned test window, not for the first time in the middle of a service. systemctl status <service> gives a concise current state and recent messages. journalctl -u <service> -f follows the unit’s journal entries as they arrive. For diagnosis, also review earlier entries around the first interruption; the initial FFmpeg message often identifies the cause more clearly than later retry or shutdown messages.
A practical review sequence is:
| Observation | What it points to | Next check |
|---|---|---|
| FFmpeg exits and systemd starts it again | A qualifying process failure may be covered | Read the first error, then verify the new YouTube preview and event |
| FFmpeg exits but no new start appears | Policy, unit state, or rate limiting may be involved | Inspect service status, loaded unit settings, and journal |
| FFmpeg remains active while preview is absent | The failure may be within input/output handling rather than process exit | Identify which connection failed and inspect FFmpeg output |
| FFmpeg is active and preview appears, but viewers see no intended event | Encoder reachability and broadcast state differ | Check the correct scheduled event and viewer endpoint |
These observations guide investigation; none establishes the cause by itself. For example, an absent preview can reflect an incorrect destination as well as a connection fault. Compare timestamps across the journal and YouTube interface so you know whether the service restarted before, during, or after the visible interruption.
Test the restart policy with a controlled failure only when you can do so without disrupting an important service. Confirm that systemd recognises the exit, waits for the configured delay, and starts the main process again. Then confirm the stream in YouTube, not just the new process identifier. Document the command version and any changed settings so that another person responsible for Sunday’s broadcast can understand what was tested.
A service that behaves correctly during a test can still encounter an unrelated persistent fault later. If systemd reports repeated starts, pause before increasing retry frequency or adding more automatic actions. Check whether the source is present, the destination and key are current, the host has network access, and the FFmpeg command still matches the intended stream. For a more general network-drop case on a small Linux host, the Raspberry Pi FFmpeg disconnect guide is relevant, though its specific context may not match your host.
Investigate FIFO or protocol recovery if FFmpeg stays alive
If FFmpeg stays alive while output has failed, first identify the direction and protocol of the connection that is failing. Is FFmpeg no longer reading its input, or is the publishing output to YouTube the problem? Protocol reconnect options are specific to documented protocols and conditions. A reconnect option useful for an input connection does not automatically repair a separate publishing output.
FFmpeg’s protocol documentation describes reconnect-related options for applicable protocols, including reconnection in particular EOF or network-error situations and limits on retries. Read the section for the protocol actually used by the relevant input or output, and confirm the option’s direction and effect before adding it. Do not treat a flag with “reconnect” in its name as a universal switch for every stream failure.
For some output failures, the FFmpeg FIFO muxer documentation provides a separate recovery mechanism. A FIFO can let FFmpeg continue processing while attempting to recover from certain output errors, with configurable retry behaviour. This operates at a different layer from systemd: the muxer may attempt to recover while the FFmpeg process remains alive, whereas systemd’s restart policy responds to qualifying process failures. Suitability depends on the command and failure mode; it cannot repair every permanent error, invalid credential, or network condition.
Choose one change at a time and test it against the failure you are trying to address. Keep the original command and the first observed error, then check whether the process exits, stays active, or recovers its output. If changing a protocol option or adding FIFO behaviour makes the process appear healthy, still check that YouTube receives the expected feed. A healthy process can continue producing locally while the remote broadcast remains unavailable.
Repeated attempts can also obscure a persistent cause. An unavailable source, unsupported or mismatched settings, rejected ingest, or fault in the network path needs diagnosis. YouTube publishes current encoder recommendations for protocols, codecs, bitrate, and keyframe settings on its live encoder settings page. Check the page rather than relying on old copied settings, and compare it with the command you are actually running. Those recommendations are configuration guidance, not a restart remedy.
Verify the broadcast in YouTube Live Control Room
After each restart, confirm the broadcast independently of systemd. Open the relevant event in YouTube Live Control Room and check whether the encoder preview is receiving the stream. For a scheduled stream, verify the event state and use the available Go Live control when required by the workflow. YouTube’s encoder setup instructions describe waiting for the preview and the scheduled-stream workflow; follow the current instructions for your event type.
Then check the viewer-facing endpoint, using the intended public or unlisted event as appropriate. The preview tells you something about ingest; the viewer endpoint tells you whether the congregation can access the broadcast. A fresh FFmpeg process, a successful-looking log line, or a green service state is not a replacement for either check. If preview returns but viewers still cannot see the stream, confirm that you are checking the correct event and its broadcast state before changing encoder settings.
Make verification part of the recovery procedure that someone can carry out during the service. Record which event to open, who can access Live Control Room, where the stream key is stored, and whom to contact if the feed does not return. Do not share the key in that checklist. If the same fault recurs, use the journal and Control Room state together to decide whether the failure is at the process, connection, or broadcast layer.
If maintaining a host and diagnosing a continuing process are not practical for your church, the operating model itself may be the problem. StreamNeo removes the need to leave your own computer running for an uploaded-video broadcast, addressing the specific burden of keeping a local machine awake and supervised; you still need to confirm the YouTube event after a disruption.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Will systemd restart FFmpeg after every YouTube stream error?
No. Restart=on-failure reacts to qualifying service process failures. If FFmpeg remains alive while publishing output is broken, systemd may have nothing to restart; investigate applicable protocol or FIFO recovery and verify the broadcast separately.
Why did FFmpeg restart but the sermon is still offline?
The process may have relaunched without YouTube accepting the output, or the scheduled event may not be live. Check FFmpeg’s first error, the encoder preview, the event state in Live Control Room, and the actual viewer endpoint.
Should I use a very short restart delay?
Not automatically. RestartSec= controls the pause between qualifying failures and a restart, and an overly rapid cycle can repeat a persistent error without helping you diagnose it. Choose a deliberate value for the service and observe its behaviour on the host.
Does an FFmpeg reconnect option fix every dropped connection?
No. Reconnect behaviour depends on the documented protocol, the connection direction, and the failure condition. Check the relevant FFmpeg documentation and test whether the option applies to your input or output; do not assume an input reconnect setting repairs YouTube publishing.