If FFmpeg runs your YouTube live channel, systemd can relaunch it after the process exits with a failure. Use Restart=on-failure with a deliberate delay, but treat it as process supervision: it cannot repair a wrong stream key, rejected ingest, persistent network failure, or incompatible encoding.
FFmpeg also has recovery mechanisms for some input and output interruptions. They work at different layers from systemd, so first identify what failed, then choose the mechanism that covers it and test the result before relying on it overnight.
How systemd restart policies apply to FFmpeg
A systemd service watches a process. When FFmpeg exits, systemd checks the unit's restart policy and, if the exit qualifies, waits for RestartSec= before starting it again. That is useful when FFmpeg has crashed or exited unexpectedly, but it is not the same as keeping the original process alive or making a failed connection succeed.
For a long-running service, systemd's service manual recommends Restart=on-failure as a way to attempt recovery from errors. With this setting, a non-zero exit or certain abnormal terminations can trigger a restart. A clean exit is not generally treated as a failure, which is usually appropriate for a channel expected to keep running. Restart=always also restarts after a clean exit, except when systemd itself stops the unit or it reaches a configured start limit. That may be useful for a process whose clean exit is still unexpected, but it can also restart a deliberately stopped or completed job in ways you did not intend.
The distinction matters for a file-based channel. If your FFmpeg command is meant to stream a finite video once and exit successfully, on-failure will not loop that video. The command needs to implement the intended playlist or loop behaviour in the first place. A restart policy is not a substitute for checking whether FFmpeg has reached the end of its input. For playlist timing and a different class of scheduling issue, see this guide to troubleshooting a playlist rotation that starts late.
Think in terms of three outcomes. FFmpeg exits and systemd launches a replacement; FFmpeg stays running but loses an input or output connection; or YouTube receives a connection but rejects or cannot use the stream. Only the first outcome is directly addressed by restarting the service. The second may need an FFmpeg protocol or muxer recovery feature, depending on the protocol and failure. The third calls for correcting the underlying cause.
You can inspect service state and logs with commands such as systemctl status ffmpeg-live.service and journalctl -u ffmpeg-live.service. Replace the example unit name with yours. The service log can show process exits and restart attempts; FFmpeg's own error output often tells you whether the failure involved opening an input, connecting to the destination, or writing the stream.
Check the command and the stream output
Before adding retries, verify that the command works as a foreground process under the same user and with the same files, environment, and destination settings that the service will use. A command that works in your interactive shell may fail as a service because the service has a different working directory, permissions, environment, or access to a mounted file. Keep the command simple enough that you can run it by hand and understand its output.
For a YouTube destination, check that the address and stream key are current and correctly paired. Treat the key as a credential: avoid placing it in a public script, a broadly readable unit file, a screenshot, or support logs. Use a protected configuration method appropriate to your system and permissions. A restart loop with an invalid or revoked key can repeat the same authentication error indefinitely; it does not make the credential valid.
Check that the source file or live input is available and readable, and confirm that FFmpeg is producing the video and audio streams you expect. If the machine cannot encode the selected format in real time, relaunching FFmpeg will not remove that workload. This is a separate problem from process supervision; the low-end PC encoder-overload troubleshooting guide covers the symptoms of an overloaded encoder.
YouTube recommends RTMPS for live ingest. Its current encoder guidance also specifies CBR and a recommended two-second keyframe frequency, which must not exceed four seconds. Video codec, resolution, frame rate and bitrate need to match the current guidance for your target output; do not copy a bitrate from a different resolution or frame rate and assume it applies. Check the YouTube encoder settings guidance when setting or reviewing those values.
The destination should be an actual YouTube ingest URL for your stream, not the illustrative address used in documentation. If FFmpeg reports that it cannot write to the destination, note the exact error and compare it with the status shown in YouTube Studio. An active process in systemd only establishes that a process is running; it does not prove that viewers can see a healthy live stream.
Configure a measured restart policy
A schematic unit might look like this:
[Unit]
Description=FFmpeg YouTube stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/bin/ffmpeg -re -i /path/to/input -c:v libx264 -c:a aac -f flv rtmps://example.invalid/live/STREAM_KEY
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
This is a starting shape, not a tested drop-in file. Replace the executable, input, encoding options and destination with values suitable for your system and channel. The example.invalid destination cannot connect. Check the installed FFmpeg build and systemd version, and validate option placement against their documentation. In particular, FFmpeg options can apply to the next input or output, so their position in the command matters.
RestartSec=5 illustrates a measured pause, not a universal setting. A short delay reduces the time before recovery from a one-off process failure, but a very rapid retry can produce repeated connection attempts without giving you much time to diagnose the error. A longer delay gives you a quieter retry pattern and can be more sensible when a dependency needs time to return. Choose a delay that fits the failure you expect; no delay can make an invalid key, incompatible encoder settings, or a persistent outage work.
Wants=network-online.target and After=network-online.target express a startup ordering relationship on systems that provide the relevant network-online service. They do not prove that the YouTube destination is reachable or that the network will remain available. If a service starts before a connection is usable, or a link drops later, inspect the network and FFmpeg logs rather than assuming the ordering directives have repaired it.
Once you edit a unit, reload systemd's unit definitions and start or restart the service using the appropriate systemctl commands for your distribution. Check its status and logs afterwards. Do not leave a real key in a sample unit copied into a public help request. If you are estimating whether to keep a local machine on around the clock, this 24/7 stream cost guide discusses the broader operating costs rather than just restart behaviour.
Account for systemd start-rate limiting
Systemd limits repeated service starts so that a broken unit does not start forever in a tight loop. The unit's start-rate settings include StartLimitIntervalSec= and StartLimitBurst=; their defaults and exact behaviour should be checked against the systemd version on your machine. When the service exceeds the permitted starts in the configured interval, it can be held in a failed state instead of continuing to retry.
This is often mistaken for a restart policy that has stopped working. Look at systemctl status and the journal for messages about start requests being repeated too quickly or the start limit being hit. Also inspect the earlier FFmpeg failure: the rate-limit message tells you why another start was withheld, not why FFmpeg began failing in the first place.
Do not respond by setting an unlimited burst or making retries extremely frequent as a general fix. That can obscure a repeated authentication or configuration error and produce a stream that alternates between short connections and long offline periods. First correct any deterministic error, such as a missing file, an invalid destination, or a command-line option error. Then decide whether the existing rate limit and delay allow a sensible number of attempts while a temporary condition clears.
The right settings depend on your service's purpose and systemd version. If you alter the start limit, understand the interval and burst together: they describe how many starts are allowed within a period, rather than changing what constitutes an FFmpeg failure. After a limit is reached, an operator may need to correct the fault and explicitly start the unit again. Confirm the unit has entered its expected state rather than assuming systemd will continue retrying without end.
When FFmpeg protocol reconnect options help
FFmpeg protocol reconnect flags apply to supported input protocols. They can be useful when an input connection drops but the FFmpeg process can remain alive and retry it. They are not interchangeable toggles: reconnect, reconnect_on_network_error, reconnect_streamed, and reconnect_at_eof address different conditions. The protocol documentation describes their scope and related retry limits; consult the FFmpeg protocol options for the input protocol you actually use.
For example, a network input may end because of a temporary disconnect, a connection error, or an end-of-file condition. Whether a flag can recover depends on the protocol and what that source does after interruption. An EOF retry may make sense for a live or endless input, whereas treating the end of an ordinary file as a disconnection could create an unintended loop. Read the protocol-specific documentation and test the precise command rather than adding every reconnect option you find in a copied example.
These flags do not mean that an outgoing YouTube RTMP or RTMPS publisher will necessarily reconnect. Input reconnect is about FFmpeg reading from a source. The YouTube destination is an output, and output recovery must be handled separately. If FFmpeg exits when a connection fails, systemd may launch a new process; if it remains running but output writes fail, a process-level restart policy may not engage at all.
A useful way to narrow the problem is to compare logs from both ends. If the input read fails, investigate the input's availability and supported reconnect behaviour. If input continues but output writing fails, look at the output mechanism and YouTube Studio status. If FFmpeg has exited, systemd can supervise a replacement. This separation prevents adding an input option to a destination-side failure.
When FIFO muxer recovery is appropriate
FFmpeg's FIFO muxer offers a different approach for certain output interruptions. It can queue packets between the encoding/output path and the destination, and its recovery options can attempt to reopen an output after a failure. Options such as attempt_recovery and recovery_wait_time are associated with this output-side behaviour. Exact support and syntax can vary with the installed FFmpeg version, so verify against current documentation and test locally.
The project's documented example uses a generic RTMP destination and demonstrates FIFO wrapping an FLV output. That is evidence for a general output recovery technique, not a YouTube-specific guarantee. Do not assume that a generic example has been validated for every YouTube ingest failure, or that FIFO will make a rejected stream acceptable. See the FFmpeg FIFO muxer material and check the options available in your installed build before adapting an example.
FIFO recovery differs from systemd supervision in the failure layer it addresses. It may retry output from within an FFmpeg process that has not exited, while systemd can start FFmpeg again after the process has failed. That distinction matters for logs: a FIFO retry may be visible in FFmpeg output without a systemd restart, while an exit followed by a new PID indicates process supervision took place.
Recovery in place is not always preferable. A queue can only buffer what the process can continue to produce, and any interruption or accumulated delay has consequences for a live broadcast. A process restart can also begin with a fresh connection but may create a visible break. In either case, persistent network failure or invalid credentials need diagnosis, not more retries. Choose FIFO only when you understand the output behaviour and have confirmed that its options suit your build and destination.
Test failures and verify recovery in YouTube Studio
Test the service before a scheduled broadcast. YouTube's official guidance explicitly says, “Make sure to test before you start your live stream.” Start with a normal run and confirm that the stream reaches YouTube. Then examine FFmpeg's output, the unit's status, and the live dashboard in YouTube Studio. A healthy process alone is not enough evidence that the ingest is working.
Use a controlled test to learn which layer responds. For process supervision, stop or terminate a test instance in a way that produces a failure and confirm that systemd waits for the configured delay before trying again. Do this on a test channel or at a time when a brief interruption is acceptable, not during an important devotional, news, or study broadcast. For input or output recovery, test the relevant condition separately and inspect whether FFmpeg remains alive, retries, and resumes useful output.
After each test, check the journal for both the original failure and the recovery attempt. Record whether the service was restarted, whether FFmpeg reconnected in place, and whether Studio received the stream again. If the service repeatedly cycles but the stream stays offline, stop treating another restart as the answer. Check the current stream key and ingest status, source availability, network path, protocol support, and encoding settings.
YouTube's ingest guidance can change, and its encoder table varies by output resolution and frame rate. Recheck it before altering codec, bitrate, or keyframe configuration. A setting that solves an encoder mismatch may have nothing to do with systemd; conversely, a correct encoder configuration cannot make a process manager recover a lost process unless the unit is configured to do so.
For a channel that depends on a local computer staying on and a person noticing failures, process supervision only addresses one part of the operating burden. If you have a finished video and want the broadcast to run without keeping your computer on, StreamNeo removes that particular need to leave your own machine running, while the YouTube channel and its stream settings remain yours to manage.
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
Should I use Restart=always or Restart=on-failure?
For a long-running FFmpeg service, Restart=on-failure is a clear default when you want recovery after abnormal exits but not after a clean stop. Restart=always also restarts after a clean exit, which may suit a process that should never finish but can be surprising for a finite job or deliberate exit. Check how the unit is stopped and how your command exits before choosing.
Does a restart policy make YouTube reconnect automatically?
It makes systemd attempt to start FFmpeg again after a qualifying process exit, subject to the delay and start-rate limit. It does not guarantee that YouTube accepts the new connection, and it cannot fix a wrong key, rejected ingest, persistent network failure, or incompatible encoding. Confirm recovery in FFmpeg logs and YouTube Studio.
Will FFmpeg's reconnect option recover an outgoing YouTube connection?
The protocol reconnect flags discussed here concern supported inputs and their individual failure conditions. Do not assume an input reconnect option recovers an outgoing RTMP or RTMPS publisher. For output interruption, investigate output-side recovery such as FIFO where appropriate, or diagnose why the connection is failing.
Why did systemd stop trying to restart FFmpeg?
The unit may have hit systemd's start-rate limit after repeated failures. Check systemctl status and the journal for rate-limit messages, then inspect the preceding FFmpeg error to find the cause of the failed starts. Adjusting the interval or burst without correcting a persistent fault can simply produce another retry loop.