If an encoder process exits on a Contabo VPS, you can use systemd to start it again and to launch it when Linux boots. That restores the process, not necessarily the video source, network connection, YouTube ingest, or the same live event.
The practical sequence is to check the VPS and Linux distribution, run the encoder in the foreground under a systemd service, enable that service at boot, and test the failure path. Then check both the service logs and YouTube Live Control Room: an active Linux service alone does not prove that viewers are receiving a healthy stream.
What automatic restart can and cannot do
A service manager watches a process. With an appropriate restart policy, systemd can start the encoder again after it exits, and an enabled service can be launched during system startup. This is useful when FFmpeg or another encoder crashes, or when the VPS reboots and returns to a working state.
It is a narrow recovery mechanism. If the video file has moved, a playlist is unavailable, the stream key has been changed, the network is down, or YouTube is not accepting the connection, restarting the same command may simply produce the same failure again. A repeated retry does not repair its cause.
Nor does a restarted encoder guarantee continuation of the same YouTube live event. YouTube’s settings describe how to connect an encoder and reuse a stream key, but do not promise that every interrupted encoder will resume the existing event. Treat the event state as something to verify in Live Control Room, not as an outcome systemd controls.
It helps to distinguish an encoder restart from a VPS reboot. The former relaunches one process while Linux remains up; the latter interrupts all processes and then starts the operating system again. Contabo describes a control-panel reboot as a server shutdown and restart, and advises using the operating system to reboot when it is accessible. See Contabo’s VPS reboot guidance before using a whole-server reboot as a routine response to an encoder exit.
| Approach | What starts again | Typical reason | Main limitation |
|---|---|---|---|
| systemd restart policy | Encoder process | Encoder exits unexpectedly | Does not fix a missing source, bad key, network fault, or YouTube event state |
| Enable service at boot | Encoder process after Linux starts | VPS has rebooted and is available | Depends on the OS, source files, credentials, and network being ready |
| Reboot the VPS | Operating system and its processes | Server-level recovery is required | Interrupts other workloads and still does not guarantee a healthy broadcast |
For a broader picture of the command and media choices involved, see this guide to running a 24/7 YouTube stream on Linux with FFmpeg. This article focuses on supervising the process, not building a production-ready encoder command for every source.
Check the Linux distribution and resources
Before copying a unit file, confirm what is actually installed. Sign in over SSH and identify the operating system and version with the distribution’s release information, commonly shown by cat /etc/os-release. Also check that systemd is the active service manager; commands in this guide assume a systemd-based Linux installation.
Contabo offers VPS plan families with different shared CPU, memory, storage, and network resources. Do not infer the machine’s capacity from the provider name alone. Check the plan and the guest operating system, then see what is available to the running process with tools such as free -h, df -h, and uptime. A stream that works in a short test can still fail later if the source, output, or other workloads exhaust available resources.
Choose the encoder and test its exact command interactively before making it a service. The command needs to run in the foreground, so systemd can observe when it exits. A script or program that forks into the background and immediately returns may look to systemd like a completed process even though another process continues separately.
YouTube’s encoder setup guidance explains its current supported connection and encoding options and recommends testing the setup and monitoring stream health. Use the current YouTube guidance for codec, resolution, frame rate, keyframe interval, and bitrate choices rather than treating one command line or bitrate as universal. If you are adapting an FFmpeg loop, the FFmpeg RTMP setup walkthrough is relevant for the encoder side; check its command against your own file and current YouTube settings.
In YouTube Studio’s Live Control Room, obtain the server URL and stream key for the event you intend to use. YouTube describes the key as a credential that lets the encoder send a feed, so treat it like a password: do not publish it, paste it into a public support message, or leave it readable by every local user. Use the URL YouTube gives you. Where your encoder supports it, YouTube’s RTMPS guidance explains the secure protocol and the expected endpoint requirements.
Run the encoder under systemd
The following is a starting pattern, not a ready-made universal service. The account name, executable path, source path, and encoder arguments must match your installation. Check the unit syntax and file locations for your distribution before using it. Keep real credentials out of a unit readable by ordinary users.
A common pattern is to keep the secret in a root-owned environment file with restrictive permissions and refer to it from the unit. For example, an administrator might create /etc/stream-encoder.env, restrict access with chmod 600 /etc/stream-encoder.env, and place the stream key there. Do not substitute a real key into a command shown in a public article, a shared script, or a shell command that will be retained in history. Confirm that the service account can read every required file without making the secret world-readable.
Create a unit file such as /etc/systemd/system/youtube-encoder.service with an editor available on your VPS. This skeleton shows the settings that need adapting:
[Unit]
Description=YouTube encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/home/streamer/stream
EnvironmentFile=/etc/stream-encoder.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /home/streamer/stream/loop.mp4 -c:v libx264 -c:a aac -f flv ${YOUTUBE_INGEST_URL}/${YOUTUBE_STREAM_KEY}
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
Replace the example username, working directory, source, executable, and encoding arguments with values verified on your machine. The example command is illustrative; it may need different options for your file, audio, codec, or chosen ingest protocol. Environment-variable expansion in ExecStart and how secrets should be passed can vary with the exact systemd setup, so confirm the method against the installed version’s documentation. If uncertain, use a wrapper script with restrictive ownership and permissions and have the unit execute that script; do not place the key in a publicly readable file.
Wants and After order the service relative to the network-online target, but they cannot ensure that a usable internet route or YouTube connection exists. Similarly, WorkingDirectory helps relative paths resolve as expected, but does not make a missing file available. The unit should start only after you have tested its command as the intended service account and verified that account’s access to the media and configuration.
YouTube’s stream setup instructions explain where to enter the server URL and stream key in an encoder. Stream-key reuse and YouTube’s auto-start or auto-stop controls are distinct from systemd: they do not tell Linux to restart FFmpeg, and systemd does not decide the state of a YouTube event.
Enable the service at boot
After saving the unit, ask systemd to load the updated definition and enable the service for startup. A typical sequence is:
sudo systemctl daemon-reload
sudo systemctl enable youtube-encoder.service
sudo systemctl start youtube-encoder.service
daemon-reload makes systemd read the unit definition. enable arranges for it to be started in the normal boot target; it does not start the service immediately, which is why the separate start command appears here. If the service already exists and you have changed its unit file, reload the definitions and restart the service to apply the changes.
Check the result with sudo systemctl status youtube-encoder.service. Look for the process state, recent messages, and whether systemd has recorded repeated restarts. A successful enable command is not proof that a later boot will have access to the source, network, or key. Those dependencies must work in the actual boot environment.
This is the right point to make sure the service is running as the intended unprivileged account rather than as root simply because the setup was performed with sudo. The account should have only the access it needs to the media, configuration, and log destinations. A service that starts at boot but cannot read its input will repeatedly fail, which is different from a systemd configuration that has not been enabled.
Choose and validate a restart policy
Restart=on-failure asks systemd to restart the service after an unsuccessful exit or certain failures. It is often a sensible starting point for an encoder that should recover from a crash but should stay stopped when an administrator deliberately stops it. Restart=always is broader: it also restarts after a clean process exit, so use it only if a normal exit should also lead to another run. Read the systemd documentation for the installed release and decide what a clean exit means for your command.
RestartSec adds a pause before the next attempt. A modest delay avoids an immediate tight loop if an invalid path or key makes the command exit as soon as it starts. A delay is not a diagnosis, and repeated retries can still fill logs or consume resources. Watch the restart count and logs; if failures repeat, stop treating retries as recovery and investigate the first underlying error.
Do not make the encoder daemonise itself if systemd is expected to supervise it directly. A service that exits while a child continues can defeat the simple process-state model in the example. For scripts that run several commands, ensure the final process remains attached to the service and that failures are returned as non-zero exits where appropriate.
Confirm the policy with an intentional test rather than assuming the file is correct. A controlled stop is not equivalent to a crash: depending on the policy, systemd may correctly leave a manually stopped service stopped. To test on-failure, make the encoder exit unsuccessfully in a test window, then observe whether a new process appears after the configured delay. If your event is live, do not perform the test without understanding the interruption it will cause.
Inspect service logs and YouTube Live Control Room
Use both operating-system and YouTube evidence. systemctl status youtube-encoder.service is a compact view of current state and recent messages. For a longer service history, use:
sudo journalctl -u youtube-encoder.service
To follow new messages as they arrive, add -f; to narrow the view to recent entries, consult journalctl’s time options for your system. Logs may expose command arguments or configuration details, so protect access to them and avoid logging the stream key. If the logs show repeated exits, note the first useful error rather than only the latest retry message.
Then open the correct event in YouTube Live Control Room. Confirm that the preview appears and check YouTube’s stream health messages. YouTube recommends monitoring the stream health indicators; a Linux process marked active only says something about the local service. It does not establish that the feed is arriving correctly, that audio and video are healthy, or that viewers can see it.
If the service runs but the preview does not appear, check the exact ingest URL and protocol, the key, DNS and outbound connectivity, and whether the encoder’s output is accepted. YouTube’s RTMPS page notes protocol and endpoint requirements; using a URL from an unrelated event or a mismatched protocol can prevent connection. Do not change multiple settings at once during diagnosis, or it becomes harder to tell which change mattered.
For problems where the feed reaches YouTube but playback stalls for viewers, process supervision may be unrelated to the fault. Compare this with the separate guidance on buffering a YouTube radio stream on Indian internet connections, which addresses a different layer of the path. For the encoder’s audio/video timing rather than its restart behaviour, see keeping FFmpeg audio and video in sync.
Test failure and recovery behaviour
Test during a planned window with a test event or another arrangement where an interruption is acceptable. First confirm that the service starts normally, the encoder process is present, the expected source plays, and Live Control Room shows an incoming feed. Record the starting state so that you can compare it with what happens after a deliberate exit.
For a controlled failure test, stop the encoder process in a way that produces the failure condition your policy is intended to handle. Watch systemctl status and journalctl for the exit and subsequent start. Then confirm that the new process has opened the source and connected to YouTube. If a normal systemctl stop leaves it stopped, that may be correct policy behaviour rather than a fault; test the configured failure case separately and safely.
If boot recovery matters, test a planned operating-system reboot when you can tolerate the downtime and have access to the VPS if anything goes wrong. After Linux returns, check that the unit is enabled and started, inspect its logs, and check the event in Live Control Room. Reboot testing validates more than an encoder crash, because it also exercises the operating system’s startup path and service dependencies. It still cannot prove future availability.
Keep the result of the test practical: note the unit name, the relevant log message, whether the process restarted, and what YouTube showed. If the service repeatedly retries without producing a feed, stop it while you investigate the source path, key, URL, permissions, and network. A restart policy that loops on a persistent configuration error can make a quiet failure look like recovery.
If your requirement is simply to relaunch one foreground encoder after exit, a systemd service is an appropriate Linux mechanism. If your real requirement is to have a feed survive a failed source, VPS, network, ingest, or event state, this policy alone does not meet it; identify and test each dependency separately.
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 reconnect YouTube after FFmpeg exits?
It can launch FFmpeg again according to the unit’s restart policy, and FFmpeg will attempt the configured connection. Whether YouTube accepts the connection or treats it as part of the same live event must be checked in Live Control Room; a process restart does not guarantee event continuity.
Should I use Restart=always or Restart=on-failure?
Use on-failure when you want a crash or unsuccessful exit to trigger another attempt but a deliberate clean stop to remain stopped. Use always only when even a clean exit should cause another run, and test the behaviour with your actual command and systemd version.
Does enabling the service reboot the Contabo VPS?
No. Enabling a service configures it to start during a later system boot; it does not restart the server. A VPS reboot interrupts all its processes and has broader effects than restarting one encoder service.
Why does systemd say the service is active when YouTube has no picture?
The service state reflects the local process, not the health of the entire broadcast path. Check the encoder logs, source and credentials, and YouTube’s Live Control Room preview and stream health messages.