If FFmpeg exits on a Linux machine that uses systemd, a service with Restart=on-failure can start it again after qualifying failures. That can restore the sending process, but it does not prove that YouTube is live or that viewers heard an uninterrupted stream.
The useful first step is to identify what stopped: the FFmpeg process, an input or output connection, or the audio while the process still appears active. Each calls for a different recovery layer. The examples below are templates to adapt and test, not a guarantee for every host or stream.
What automatic FFmpeg recovery can and cannot do
A process supervisor watches whether a process is running and responds to certain exit conditions. On a Linux host managed by systemd, Restart=on-failure is a practical baseline for restarting FFmpeg after eligible failures. The delay before the next attempt is configurable, which helps avoid an immediate restart loop.
That is process recovery, not broadcast verification. FFmpeg can restart successfully yet fail to connect to the destination, send audio that is silent, or send a stream that YouTube has not accepted as a live broadcast. A restart can also leave viewers with a gap or a reconnect. Do not describe the result as uninterrupted service simply because systemd reports the process active.
Separate four common symptoms before changing configuration:
| What you observe | Likely layer to investigate | First response |
|---|---|---|
| FFmpeg exits and its service becomes inactive | Process supervision | Inspect its exit status and logs; configure systemd restart behaviour if appropriate |
| FFmpeg stays active after an input disconnect | Input protocol | Check whether that input protocol and FFmpeg build support reconnection options |
| FFmpeg stays active but output fails | Output protocol or muxing | Inspect FFmpeg errors and consider supported output recovery behaviour |
| Service remains active but audio stops or freezes | Stream health | Add a destination-specific health check; a process restart rule alone may not see the fault |
If the stream uses an input protocol with documented reconnect options, those options may help while FFmpeg remains alive and handles the connection. They do not restart an FFmpeg process that has already exited. The FFmpeg protocol documentation describes options for particular protocols, not a universal reconnect switch.
For an output problem, the FIFO muxer has recovery controls, but they have trade-offs. Its queue behaviour can affect whether encoding blocks or packets are dropped when the output is struggling. Decide whether losing some audio is acceptable before using a setting that allows processing to continue by dropping queued packets. The FFmpeg manual documents the FIFO muxer and its options.
Run FFmpeg as a systemd service
A service gives systemd a process to supervise, a defined command to start, and a place to record logs. This approach applies to Linux systems that use systemd; it is not a generic instruction for Windows, macOS, containers without a systemd manager, or every VPS image. Check what your host actually runs before copying a unit file.
Here is an illustrative unit for a local audio file sent to a destination you supply:
[Unit]
Description=FFmpeg sleep sounds stream
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=stream
WorkingDirectory=/srv/sounds
ExecStart=/usr/bin/ffmpeg -nostdin -stream_loop -1 -re -i /srv/sounds/sleep-sounds.mp3 -c:a copy -f <your-output-format> <your-output-url>
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
Treat this as a sketch, not a tested configuration. Replace the user, file path, working directory, output format, and destination with values that match your installation. The example assumes a local file and an output that accepts the selected format and codec; it does not validate a particular file/container pairing or destination. Confirm that your installed FFmpeg build supports the input and output formats you intend to use.
The After and Wants lines express a relationship with the network-online target, but they do not make a remote destination reachable or guarantee that the network is ready in the way your stream needs. Similarly, Type=simple tells systemd to supervise the foreground process started by ExecStart; do not add shell backgrounding such as &, which can undermine the supervisor's ability to track the intended process.
Protect credentials. A YouTube stream key embedded directly in a unit can be exposed to users who can read that file or inspect process details, depending on permissions and the surrounding setup. Use an appropriately protected configuration mechanism, restrict access, and avoid pasting keys into public logs or support posts. See the practical guidance on keeping a YouTube stream key secure on a VPS before deciding how to store it.
After saving a unit under the appropriate systemd service directory, an administrator typically reloads unit definitions, enables the service if it should start at boot, and starts it. The exact commands and access requirements vary by distribution and policy. Before enabling unattended operation, start it under supervision once and check that the command works with the selected account, file permissions, and destination.
Set Restart=on-failure
In the service section, Restart=on-failure asks systemd to restart the service after failures that qualify under its rules. These include a non-zero exit status, certain abnormal signals, and configured timeout or watchdog failures. Consult the systemd service documentation for the current details and any distribution-specific behaviour.
This is not the same as restarting after every stop. A clean exit or an intentional stop by an operator should remain controllable; otherwise, stopping a service could simply cause it to come back. That distinction matters when you need to change a file, rotate a key, or deliberately take a channel offline. Choose a restart policy that matches your operational intent rather than changing to Restart=always just because it sounds more complete.
The policy acts on how the service process ends, not on the meaning of FFmpeg's output. If FFmpeg exits cleanly after a command or reaches an end condition, on-failure may not restart it. If it stays alive while sending no useful audio, there may be no process exit for systemd to act on. Read the service result and FFmpeg log around an incident before treating the restart directive as the fix.
For a YouTube output that reports a broken pipe, examine the actual failure and destination behaviour as well as the exit policy. A systemd restart can help after FFmpeg exits, while a connection failure that FFmpeg is still handling may need a different response. The broken-pipe troubleshooting guide is a useful companion when that is the error in your logs.
Choose a deliberate RestartSec= delay
RestartSec= sets the wait before systemd attempts a restart under the configured policy. A short pause gives the process time to exit fully and can prevent rapid repeated attempts when a destination or network is temporarily unavailable. The systemd documentation defines the setting as the time to sleep before restarting a service.
The 5s value in the example is only an illustrative choice, not a benchmark or universal recommendation. Choose a delay with your failure mode in mind. If the destination is briefly unavailable, immediate retries may produce a stream of failed connections and noisy logs. A longer pause can reduce that churn, but viewers may wait longer before a new FFmpeg process attempts to connect.
A restart delay is not a substitute for a retry strategy or a health check. It only governs the wait after a qualifying service failure; it does not reconnect every input, repair credentials, correct an invalid output URL, or detect silent audio. Repeated restarts with the same error are evidence to investigate the underlying cause, not a reason to keep shortening the delay.
Use the logs to see whether the delay is helping or merely spacing out the same failure. If FFmpeg repeatedly exits because a file is missing or a key is wrong, fix that cause first. If the service exits during a temporary network loss, inspect whether the failure is at the input, output, or process layer and consider protocol-specific recovery where supported.
Use -nostdin for unattended operation
FFmpeg can check standard input for commands in interactive use. When it runs in the background under a service manager, there is no useful terminal interaction to rely on. The -nostdin option disables those input checks, which is appropriate for unattended operation. FFmpeg's FAQ specifically discusses using it when running FFmpeg as a background task.
Put the option in the FFmpeg command, as in the unit example. It changes how FFmpeg handles standard input; it does not restart the process, reconnect a failed destination, or prevent every hang. It is one small part of making a command suitable for a service, not a general-purpose reliability flag.
For a local sleep-sounds file that should repeat, -stream_loop -1 tells FFmpeg to loop it indefinitely. Place that input option before the corresponding -i, as shown. -re reads at the input's native rate and can be useful to pace a file as a live stream. Neither setting supervises a crash, and looping a file does not confirm that audio is reaching YouTube.
Check the behaviour with your actual media. A copied audio stream may be unsuitable if the selected output expects a different codec or container, and the example does not establish that every MP3, file, or output combination will work. Test the command in the foreground first, then run it as the service's account so that file access and environment differences are visible before leaving it unattended.
Understand qualifying exits, signals, and timeouts
The word “failure” has a defined operational meaning here, not simply “the audience could not hear the stream”. Systemd can act when the tracked process exits in a qualifying way, is terminated by a qualifying signal, or runs into a configured timeout or watchdog failure. The exact result depends on the unit settings and how the process ended. Check the service status and logs rather than inferring a cause from the fact that the stream stopped.
A deliberate stop is different from a crash. If an administrator stops a service to change settings, the configured on-failure policy is intended not to make that clean, requested stop behave like an unexpected failure. This lets you retain operational control. After changing a unit, reload its definition and restart it deliberately; do not interpret the resulting manual stop as proof that recovery is broken.
A timeout is useful only if a relevant timeout has actually been configured and the service manager can observe the condition. Do not add watchdog settings without understanding what signal or health condition they monitor. Likewise, a process can be alive and unresponsive in a way that does not produce an exit. A watchdog or separate monitor may be necessary for that case, but its checks and thresholds depend on the deployment.
Signal handling also needs context. A process may receive a signal from an operator, the service manager during shutdown, or another system condition. Do not assume all signals should cause an automatic restart; some are part of an intentional stop. Consult systemd's current restart rules and review the recorded result for your service before changing policy.
If the audio comes from a live network input rather than a local file, determine which protocol is in use before adding reconnect flags. FFmpeg's HTTP reconnect settings, for example, apply to HTTP input and have distinct meanings; they are not valid universal fixes for every source. When an input is involved, keep the distinction between a protocol retry inside FFmpeg and a process restart by systemd clear.
Check recovery and YouTube stream status
A service showing as active tells you that systemd considers the service process running. It does not establish that YouTube has received the expected audio or that the live broadcast is healthy. Check both sides after a restart: the host's service status and logs, and the live status shown in YouTube's own control room or current official help material.
For each test, note what the service did and what YouTube showed. A useful controlled test is to stop the service intentionally, confirm that it stays stopped, then start it again and verify the output. Separately, test a qualifying failure in a safe window and observe whether systemd retries after the configured delay. Do not create a failure test during an important broadcast if viewers would be affected.
After a real incident, compare timestamps in the service journal with FFmpeg's messages and the destination's status. If FFmpeg restarted but YouTube still reports no incoming stream, investigate the output URL, key, format, network route, and current broadcast state. If YouTube receives a signal but the audio is silent or frozen, a process-exit rule is not enough; establish a health check that detects lack of useful progress and decide what action it should take.
Avoid claiming a universal check command or threshold. The right measurement depends on the destination and whether you can inspect audio levels, output progress, or another meaningful signal. Make the check specific enough to avoid restarting a healthy but quiet sleep-sounds recording. A gentle passage or intentional silence can look like a fault to a crude audio-level monitor.
If a stream is becoming more complex than a single supervised command, first document the source, destination, credentials handling, expected audio, and recovery behaviour. The guide to streaming a devotional playlist as a YouTube live loop can help you think through the loop itself; it does not replace service monitoring. For a file-based sleep channel, also decide whether replacing or editing the source should require an intentional service restart.
For some operators, maintaining a Linux host, service unit, protected key handling, and health checks is the desired level of control. If the recurring pain is keeping a computer on and manually bringing a file-based stream back after a process drop, StreamNeo can remove that particular computer-side task by running an uploaded file as a YouTube live stream while your computer is off. It remains important to check YouTube's live status and to understand what the service does and does not monitor.
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 Restart=on-failure bring FFmpeg back after every crash?
No. It applies to qualifying failure conditions, not every possible stop or failure. A clean, intentional stop is treated differently, and a process that stays alive while audio has stopped may not trigger a restart at all.
Does a successful restart mean YouTube is live again?
No. The service manager can confirm that its process is running, but that is not confirmation that YouTube is receiving the stream or presenting it as live. Check the host logs and YouTube's current status after recovery.
Should I use RestartSec=5s?
The 5s in the sample is illustrative, not a universal recommendation. Pick a delay that suits the failure you are addressing, then watch whether retries are useful or simply repeating the same error.
What should I do if FFmpeg stays active but the stream is silent?
Treat that as a stream-health problem rather than a process-exit problem. Identify a meaningful progress or output check for your destination, and avoid a threshold that mistakes naturally quiet audio for a fault.