If your Linux server reboots, an FFmpeg command started in a terminal will not resume by itself. Run it as an enabled systemd service so the host starts it at boot, and give systemd a policy for handling an FFmpeg process that exits unexpectedly.
Those steps recover a process; they do not prove YouTube is receiving a healthy stream. A network interruption may leave FFmpeg running, while a reboot stops the process entirely. Treat boot startup, process failure and output recovery as separate problems, then check the result in YouTube Live Control Room.
Separate a host reboot from a network interruption
A server reboot ends the old FFmpeg process. Systemd can start a new one when the machine comes back, provided the service is enabled and its command, media and credentials are available. A restart policy can also tell systemd what to do after a process exits, but it does not replace enabling the service for boot.
A network interruption is different. The machine and FFmpeg process may stay up while the connection to YouTube is disrupted. If FFmpeg remains running, systemd has no process exit to react to. The stream can be stalled or unhealthy even though systemctl reports the service as active.
| Situation | What may help | What it does not establish |
|---|---|---|
| Host reboots | An enabled systemd service starts FFmpeg during boot | That the source, network or YouTube ingest is ready |
| FFmpeg exits with an error | A systemd Restart= policy may start another process |
That a persistent command or key error has been fixed |
| Output connection fails but FFmpeg stays alive | Output-specific recovery, if supported and configured | That systemd will notice a stalled broadcast |
| An HTTP input source drops | HTTP input reconnect options, where appropriate | Recovery of an RTMP or RTMPS output connection |
FFmpeg's FIFO muxer has an attempt_recovery option for some output failures; this is an in-process mechanism, not a reboot setting. Its behaviour depends on how the output is configured and on the FFmpeg version installed. HTTP options such as -reconnect apply to HTTP input, not as generic switches for RTMP output recovery. Check the FFmpeg protocol documentation and FIFO muxer documentation for the relevant options before adapting a command.
For a stream that has to survive both reboots and transient connection problems, consider each layer on its own: a service manager for process lifecycle, encoder or output recovery for the connection, and an operational check for stream health. The choice of latency versus stability settings affects the viewer experience, but does not substitute for process supervision.
Test the FFmpeg command interactively
Before writing a service unit, run the exact FFmpeg command from a shell on the server. Confirm the input opens, the output reaches the intended YouTube destination and the preview appears in Live Control Room. A command that fails in a terminal is not ready to automate; systemd can repeat the failure, not diagnose or repair it.
Use the stream URL and key currently shown in Live Control Room. YouTube recommends RTMPS, its secure extension to RTMP; choose the protocol and destination YouTube provides for your stream. See the official YouTube encoder settings guidance. Do not rely on a URL or key copied from an old note if the current control room settings differ.
Keep the first test simple. For a file source, make sure the file plays and that FFmpeg reaches the expected end or loop behaviour. For a camera or capture device, test that the device is present and accessible under the account you plan to use. For a playlist or upstream feed, confirm that its paths and network access work on the server itself. If the channel uses recorded regional video, the aspect ratio setup for YouTube Live is one part of preparing the media, though this service configuration is specifically for FFmpeg.
Copy the tested command carefully, including codec, frame rate, audio and output options. Avoid treating values from another channel as universal: the appropriate settings depend on the material and the stream configuration. If the source is a long music playlist, verify its ordering and repeat behaviour separately; the service will not prevent the same songs repeating.
Create a systemd service with absolute paths
A system service does not inherit the interactive shell that worked during your test. It may use a different working directory, a smaller environment, another user and different permissions. Use absolute paths for FFmpeg, input files and any configuration files, and specify the account that should run the process.
A basic unit might look like this. Replace the example paths and account with values that exist on your host; do not paste it unchanged and assume it is ready for a broadcast.
[Unit]
Description=YouTube Live FFmpeg stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/srv/stream
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/stream/programme.mp4 -c:v libx264 -c:a aac -f flv rtmps://example.invalid/live/STREAM_KEY
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This is an illustration, not a complete production command or a claim that its placeholder destination will work. Use the actual FFmpeg binary path, current ingest details and encoding options for your source. An ExecStart= line should call FFmpeg directly. If you need a wrapper for preparation or validation, make sure it does not leave systemd supervising a short-lived shell rather than the long-running encoder.
The Wants= and After= relationship asks systemd to bring up the network-online target before this unit. It is an ordering aid, not a guarantee that DNS, the public internet, a mounted media volume or YouTube ingest will already be usable. A sensible delay and retry behaviour may help with late availability, but still verify the stream.
Choose a restart policy and a deliberate delay
For a stream process expected to run continuously, Restart=on-failure is a reasonable starting point. It asks systemd to restart after a non-zero exit and certain abnormal outcomes. Consult the systemd.service manual for the exact semantics and the other available policies.
Restart=always is broader: it can also restart after a process exits successfully. That might suit a command whose successful exit is itself unexpected, but can be wrong for a job intended to finish. Choose based on the actual FFmpeg command and its expected lifetime rather than selecting the broadest setting automatically.
RestartSec= inserts a pause before a restart attempt. A modest delay avoids an immediate, repeated launch cycle when a path is wrong or the key is invalid, and can give a source or network time to return. The example uses a value for illustration, not as a universally correct interval. A unit can also be subject to systemd start-rate limiting; if repeated starts hit that limit, read the journal and correct the underlying failure instead of simply loosening limits.
A restart policy cannot detect every frozen input, silent audio, or output that remains connected but ceases to carry useful video. For those cases, add a separate health check or monitoring process appropriate to your setup. Do not infer broadcast health solely from an active process or a successful service start.
Enable the unit at boot and test the path
Save the unit under an appropriate systemd service filename, such as /etc/systemd/system/youtube-live.service. After changing a unit, tell systemd to reload unit definitions, then enable it and start it. A typical workflow is:
sudo systemctl daemon-reload
sudo systemctl enable --now youtube-live.service
sudo systemctl status youtube-live.service
enable configures startup as part of the host's boot process; --now also starts it immediately. Starting a service without enabling it does not arrange for it to start on the next reboot. Conversely, enabling only answers the boot question, not whether the current start succeeded.
Use a staging machine or a planned maintenance window to test a reboot where practical. Before rebooting, confirm the service starts and the stream preview is healthy. After boot, check that systemd loaded the unit, FFmpeg has the intended arguments, media is available and the control room sees the feed. Do not claim a reboot test has passed unless you actually performed one on the relevant host and configuration.
If you already run FFmpeg under a different supervisor or inside a container, avoid arranging two independent managers to restart the same encoder. Decide which layer owns the process and test its boot behaviour. Readers comparing hosting approaches can also review cloud services for a 24/7 YouTube stream; this article's configuration assumes you manage a Linux host.
Provide the service environment and media access
Run the service as a dedicated, least-privilege account where practical. That account needs permission to execute FFmpeg and read the source media, but should not gain broad access to unrelated files simply because the interactive administrator account could read them. Check parent-directory permissions as well as the file itself.
For a camera, capture card or other device, confirm the device exists after reboot and that the service account belongs to the required device-access group. Device names and availability can change across boots. For network storage, verify it is mounted before FFmpeg starts and that the service account can read it. A configured mount point that is empty at boot can otherwise look like a valid path while the intended media is absent.
Set WorkingDirectory= explicitly if any part of the command depends on relative paths, though absolute paths are safer. Set only the environment variables the command needs. A separate environment file can hold non-secret configuration, with permissions restricted to the appropriate account. Do not assume variables set in .bashrc, .profile or an SSH session will be present to a system service.
If startup races with a late mount or upstream source, fix the dependency or add suitable waiting and retry behaviour for that specific source. network-online.target does not wait for YouTube to accept a connection, and a restart delay is not a substitute for a missing mount or a bad URL. Test under the actual service account, not only as root.
Protect the key and inspect logs
Treat the stream key as a credential. Avoid embedding it in a world-readable unit file, a public repository, screenshots or an ordinary log. A service definition may be readable by more people than you expect. Use a restricted credential or environment-file mechanism appropriate to the host, check file ownership and permissions, and avoid printing the full command with the secret into shared diagnostics.
If the key has been exposed, replace or refresh it through YouTube's current Live Control Room workflow and update the service's protected configuration. YouTube's live streaming troubleshooting guidance covers encoder startup and stream issues. A stale or invalid key is a configuration fault, not something a restart loop can solve.
Inspect status and recent logs with commands such as:
sudo systemctl status youtube-live.service
sudo journalctl -u youtube-live.service -b --no-pager
Look for the actual exit status and first meaningful FFmpeg error. Check, in order, whether the unit loaded, the executable exists, the service user can read the input, environment values are present, and the output URL and key are current. Then look at the preview and stream-health indicators in Live Control Room. If FFmpeg is active but the preview is absent or unhealthy, investigate the output connection or media rather than assuming a systemd restart is needed.
A cloud-hosted broadcast can remove the need to keep a personal computer running and simplify recovery from a local machine reboot. In that specific situation, StreamNeo removes the repeated work of maintaining a local FFmpeg process and restarting it after your own computer switches off. It is a YouTube-only path, so it is not a replacement for a Linux service when you specifically need to supervise an encoder you manage yourself.
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
Does Restart=on-failure start FFmpeg after a server reboot?
It handles qualifying failures of the service process, but boot startup is configured separately by enabling the unit. Use both the boot enablement workflow and an intentional restart policy, then verify the stream after a real reboot where practical.
Will systemd reconnect a running FFmpeg process after an internet interruption?
Not simply because the connection was interrupted. If FFmpeg remains alive, systemd may see no exit to act on; use output recovery that fits the actual protocol and check whether the feed recovers in Live Control Room. HTTP input reconnect options are not generic RTMP output recovery options.
Why does the service work in a terminal but fail at boot?
System services commonly have a different user, environment, working directory and access to mounted files or devices. Use absolute paths, define the required environment, verify permissions as the service account and read the unit journal for the first failure.
Does an active service mean YouTube is receiving a healthy stream?
No. It means systemd considers the service process active, not that the input is producing valid media or YouTube is receiving it correctly. Check FFmpeg output and YouTube's live preview and stream-health indicators.