A systemd service can start FFmpeg when your OVHcloud VPS boots and restart the process after a failure. That restores the encoder process, not necessarily the same YouTube live event: check the feed in Live Control Room before assuming the broadcast has resumed.
The practical change is to move FFmpeg out of an interactive SSH session and into a service the operating system supervises. This guide covers the host, command, credentials, service setup and checks after a reboot; it does not treat a successful process restart as proof viewers can see the stream.
Why an SSH-launched FFmpeg stops at reboot
Starting FFmpeg in a terminal proves only that it can run in that session. It does not configure the VPS to launch it again after a reboot. If the host restarts, the process that was sending video to YouTube is gone. A dropped SSH connection can also leave you uncertain about whether a command is still running, and logging out or closing the terminal is not a substitute for a persistent supervisor.
OVHcloud’s systemd service guide demonstrates moving a process into a service, enabling it at boot and setting a restart policy. The example uses another application, not FFmpeg, but the general principle applies: let the guest operating system start and supervise the encoder.
There are two distinct recovery events. First, systemd may start FFmpeg after the VPS boots or after the process exits with a failure. Second, YouTube must accept the encoder feed and make it available through the live event. The first is a local service action; it does not establish that the second happened, that the previous event is still open, or that viewers experienced no interruption.
A boot-enabled service also cannot repair every failure. If the VPS does not boot, networking is unavailable, the stream key is invalid, or the source file cannot be read, starting FFmpeg again will not solve the underlying problem. Treat the service as process recovery, then verify the host and YouTube feed separately.
Check the VPS and your current FFmpeg command
Before editing service files, make a note of the working command and confirm the VPS itself is healthy. In the OVHcloud control panel, check the instance state and recent reboot activity. If normal SSH access does not return, use the provider console or recovery options to determine whether the guest has booted. A service configuration cannot help while the virtual machine is unavailable.
On the guest, confirm where FFmpeg is installed and which Linux account should run it. You can locate the binary with command -v ffmpeg. Check that the account has permission to read the video or playlist, any configuration files, and any directories used for logs. If your command refers to a relative path, record the directory from which it normally works; system services may start with a different working directory.
Write down the full FFmpeg invocation that currently sends the intended content to YouTube, including its input, output protocol, and any encoder settings. Do not replace a working command with a guessed template copied from an unrelated setup. The exact options depend on your source and FFmpeg build. This guide deliberately does not prescribe reconnect flags or claim that a particular option order will make a build reconnect automatically.
If your input is a playlist or looping video, verify that it continues to provide content rather than ending after one file. For a playlist workflow, see the guide to looping an audio playlist with FFmpeg. If the machine has more than one channel to encode, account for each process and its resource use; the considerations differ from a single stream, as explained in running two YouTube streams from one FFmpeg server.
Before relying on a reboot test, make sure you can access the VPS console and know how to stop the service if the command loops or consumes unexpected resources. A planned test is more useful when you have an alternative way to regain access than the SSH connection you are about to interrupt.
Store the YouTube ingest URL and key safely
FFmpeg needs the correct ingest destination and stream key. YouTube’s encoder setup instructions tell you to copy the server URL and stream key from Live Control Room into your encoder. Use the values for the intended event or stream configuration, and check them again if you have reset or changed the key.
Treat the key as a credential. Do not put a real key in a public example, a ticket, a shared shell history, or a log pasted into a forum. A service file may be readable by administrators and, depending on its permissions and configuration, by other local users. Restrict access to the files that contain the key and to the service configuration. Keep a private, recoverable record of which stream configuration it belongs to, without making the secret broadly visible.
There is no single storage arrangement that fits every host. A dedicated environment file can keep the destination separate from the unit definition, but its permissions must be restricted and the service must be configured to read it. Putting the values directly in the command within a unit is simpler to inspect, but can make the key more exposed to people who can read that file or service details. Whichever method you choose, test that the service receives the values after boot and avoid printing them during troubleshooting.
If you rotate the key, update the stored value used by the service as well as any manual encoder configuration. A service can be active and FFmpeg can be running while YouTube rejects an incorrect or stale destination or key. YouTube’s stream settings help explains the available stream settings and key controls; use the current Live Control Room values rather than relying on an old note.
Create a systemd service for FFmpeg
A systemd unit describes what to run, which account runs it, where it runs, how it relates to network startup and what to do if the process exits. Adapt the pattern in OVHcloud’s service guide to your own command; do not copy its example application or assume that its paths fit your VPS.
Create a unit file under /etc/systemd/system/, for example /etc/systemd/system/youtube-ffmpeg.service. Use an editor with administrator privileges. A basic outline looks like this:
[Unit]
Description=FFmpeg YouTube stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/home/streamer/channel
ExecStart=/usr/bin/ffmpeg [your verified arguments]
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
This is a unit structure, not a ready-to-run FFmpeg command. Replace the example account, directory, executable path and placeholder arguments with values you have verified on your VPS. In ExecStart, systemd expects the executable and its arguments as a command line; do not paste shell syntax such as a pipeline or variable expansion and assume a shell will interpret it. If your existing command depends on shell behaviour, consider how to represent that safely and test it before enabling the service.
After=network-online.target expresses startup ordering, but it does not prove that the host has working outbound connectivity or that YouTube is reachable. Network-online behaviour can also depend on the Linux distribution’s network configuration. FFmpeg may start while a connection is unavailable. A restart policy can attempt another process start after failure, but it is not a promise that the network or destination will recover.
User should name a non-root account that has access to the FFmpeg executable, input files and required configuration. This limits the permissions available to the process compared with running it as root. WorkingDirectory matters when your command uses relative paths. Use the absolute path to FFmpeg and absolute paths for inputs where practical so a change in startup context does not silently point the command somewhere else.
Restart=on-failure asks systemd to restart a service when its process exits unsuccessfully. It does not restart a process that is still running but producing no useful feed, and it does not determine whether YouTube has ended an event. RestartSec adds a pause before a retry. Choose a policy and delay with the likely failure in mind; repeated immediate attempts can clutter logs and do not fix a bad path, denied permission or invalid key.
Check the unit syntax and paths before starting it. If you alter a unit or its environment file later, systemd must be told to reload its configuration before the change applies. Keep a copy of the known-good command and unit in a private administrative record so a future edit can be compared with the working version.
Enable and start the service
After saving the unit, ask systemd to reload its unit definitions, then enable the service so it is considered at boot. Start it for the current session and inspect its status before scheduling a reboot. The usual commands are:
sudo systemctl daemon-reload
sudo systemctl enable youtube-ffmpeg.service
sudo systemctl start youtube-ffmpeg.service
sudo systemctl status youtube-ffmpeg.service
Read the status output rather than looking only for the word active. Confirm that the expected unit is loaded, the configured command has started and the process is not repeatedly exiting and restarting. If it fails immediately, stop and investigate before rebooting. Common places to check include the executable path, user permissions, working directory, input path, environment file and FFmpeg’s own error output.
When you are ready to test startup behaviour, arrange a maintenance window if viewers may be affected. A reboot interrupts the running process. If the channel is scheduled around a particular event, confirm the YouTube event state and your recovery plan before initiating it. Reboot using the normal system method, then reconnect after the VPS returns. If the host does not return, investigate the instance before treating it as an FFmpeg failure.
A service being enabled is not the same as a successful stream. Enabling records that systemd should start the unit as the machine enters its normal boot target. It does not validate the command, key, input, outbound path or live event. Each of those needs a separate check.
Check status and logs after reboot
After the VPS is reachable again, check the instance state in the OVHcloud panel and then log in to the guest. On the host, inspect the service with systemctl status youtube-ffmpeg.service. Review its recent journal entries with journalctl -u youtube-ffmpeg.service -b, which limits the view to the current boot. If you need more context, inspect earlier entries as well, taking care not to share logs that expose credentials.
Look for the time the service started, its main process state and repeated restart attempts. An active service can still be unhealthy if FFmpeg has no input or cannot establish a useful output. Read the error messages for file-not-found conditions, permission problems, invalid arguments, authentication failures or network errors. Check process activity and resource use with the tools available on your distribution, but do not treat a process listing as proof YouTube is receiving a feed.
If the unit is inactive, check that it is enabled and that the host reached the expected boot target. If it is in a restart loop, temporarily stop it while correcting the error rather than letting a broken configuration retry indefinitely. After changing a unit file, reload systemd and start the service again. After changing only a credential file, ensure its permissions and the service’s access are correct, then restart the unit so it reads the updated value.
If the VPS is running but the feed does not return, separate the diagnosis into layers: does FFmpeg start, can it read the source, can it reach the outbound network, and does YouTube accept the configured feed? YouTube’s encoder troubleshooting guidance recommends checking encoder health, connectivity and stream settings. Test outbound access in a way appropriate to your system, and verify the key and URL in Live Control Room rather than pasting secrets into a public troubleshooting request.
A service restart is not high availability. If a host or network failure needs coverage beyond process restarts, YouTube discusses a primary and backup encoder approach in its live streaming tips. That adds configuration and operational work, and needs an actual failover test; it is not a substitute for a boot-enabled service on the primary VPS. For a wider look at host planning, the OVHcloud VPS cost guide can help frame the ongoing operating choice.
Confirm the feed in Live Control Room
Once FFmpeg appears to be running, open the relevant event in YouTube Live Control Room. Confirm that an encoder preview or incoming stream appears and inspect the stream health indicators. YouTube recommends previewing the stream and monitoring its health; the preview is a separate check from the local service status. Also check the viewer-facing watch page when appropriate, because a preview alone does not confirm that the intended public viewing experience is available.
If no preview appears, verify the server URL and key against the current settings, then check that the command is using the expected values. Confirm that the encoder can make outbound connections and that the source is still producing audio or video. YouTube’s encoder guidance recommends checking representative content and stream health rather than assuming that a connection alone means the output is correct.
If the preview returns but quality is poor, inspect the encoding settings against YouTube’s current encoder settings guidance. Match resolution and frame rate to the source, and select a bitrate that fits the available outbound upload capacity. YouTube recommends leaving headroom on upload bandwidth; a VPS with insufficient capacity can struggle even when FFmpeg remains active. Avoid copying one bitrate or codec setting into every channel without checking the source and current guidance.
Most importantly, distinguish a returned encoder feed from continuation of the same event. FFmpeg may reconnect to an event that is still accepting an encoder, but the service configuration alone cannot establish that this will happen seamlessly. If the earlier event ended or is no longer accepting input, you may need to start or schedule another event in Live Control Room. Check the event state and viewer page rather than promising that a systemd restart restores uninterrupted playback.
For unattended channels, make the verification part of the operating routine: after planned host maintenance, check the VPS, service, logs and YouTube preview in that order. If you need somebody to notice a later failure, arrange monitoring and an escalation path; systemd can restart a failed process, but it cannot tell you whether a person has confirmed that the audience-facing stream is healthy. When the repeated work of keeping a computer or VPS session alive is itself the problem, StreamNeo can take an uploaded video and run it as a YouTube stream with your computer switched off, removing that specific process-supervision task without changing the need to verify the live event.
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 systemd guarantee that my YouTube stream will be live after reboot?
No. It can start the FFmpeg process and restart it after certain failures, but it cannot guarantee that the VPS has working connectivity, that credentials are valid or that YouTube is accepting the feed. Check the event preview and stream health in Live Control Room.
Will FFmpeg resume the same YouTube live event?
Not necessarily. A restarted encoder process and a continuing YouTube event are separate outcomes, and the event may have ended or stopped accepting input. Check the event state and be prepared to start or schedule another event if needed.
What should I check if systemd says the service is active but there is no preview?
Inspect the service journal for FFmpeg errors, then verify the input file, destination URL, key and outbound connectivity. Confirm the current stream settings in Live Control Room and check encoder health; an active process alone does not prove YouTube is receiving the feed.
Is a systemd restart policy a backup encoder?
No. A restart policy recovers a process on the same host under configured conditions. A backup encoder is a separate resilience arrangement that must be configured and tested, and it does not remove the need to check what viewers see.