A systemd service can restart an FFmpeg encoder when its process exits and start it again after an Oracle Cloud VPS reboots. Neither action proves that YouTube is receiving a usable picture and sound, so you need to check the stream in YouTube Studio as well.
This guide sets up those separate checks: prepare a stable input and YouTube stream, run the encoder under a service, then test both process recovery and viewer-facing output. The examples are a pattern to adapt to your Linux image and FFmpeg command, not a promise of uninterrupted streaming.
What auto-restart can and cannot recover
A service manager supervises a process. If FFmpeg exits with an error, systemd can start it again according to the unit’s restart policy. Enabling the unit at boot asks systemd to start it when the VPS boots. These are two distinct behaviours: restart policy concerns the process during system operation; boot enablement concerns whether the service is brought up after a machine restart.
They cover useful failures, but not every failure that matters to a viewer. FFmpeg might remain alive while the input is frozen, the output has no sound, the network path is poor, or YouTube is rejecting the feed. A restart policy usually responds to process termination; it does not certify the content of the outgoing stream. Likewise, a “running” unit in systemctl status reports service state, not a healthy live picture.
Think of recovery as layers. systemd can handle process exit and boot startup. YouTube Live Control Room can show whether the ingest is arriving and report stream health. A human check or a deliberately designed monitoring layer is needed for problems that neither layer detects, such as a still-running encoder producing the wrong scene. Do not add a watchdog or periodic restart casually: each adds its own failure modes and should be tested against a clearly defined problem.
For a useful comparison of encoder choices and their operational trade-offs, see FFmpeg or OBS for a prerecorded 24/7 stream. This article uses FFmpeg because it fits a headless VPS, but a desktop-based workflow may suit you better if you need frequent visual scene changes or hands-on control.
Prepare the VPS, media and YouTube stream
In the Oracle Cloud console, confirm that your tenancy can create the instance you intend to use, in the region and availability capacity you can access. Check the current compute allowance, storage, network egress and operating-system support against your expected workload. Oracle’s Always Free compute documentation describes account-eligible A1 allowances and region requirements; availability and account eligibility are not guaranteed by this guide. Oracle also documents circumstances in which an Always Free instance may be classified as idle, so check its current idle resource guidance rather than treating a free allocation as a promise of permanent capacity.
Choose a Linux image you can maintain, and make sure you can connect to it and administer services. Install FFmpeg from a source appropriate to that distribution, then verify it is available with ffmpeg -version. Keep the media file and any configuration at stable paths that will exist after reboot; avoid relying on a user’s temporary directory or a mounted location that may not be ready when the service starts.
Prepare a file that loops cleanly and that you have permission to stream. Check its duration, video dimensions, frame rate, audio track and codec before building the service. If the source file is missing, unreadable or has no intended audio, restarting FFmpeg will not repair it. If you are preparing a playlist rather than a single file, the guide to using FFmpeg to prepare playlist videos may help you identify input consistency issues before deployment.
In YouTube Studio, create or select an encoder stream in Live Control Room, then note its ingest server URL and stream key. YouTube Help says, “Stream keys are like your YouTube stream’s password and address.” Treat the key as a secret: do not place it in a public repository, screenshot, shared command history or unprotected log. If it is exposed, reset it in Live Control Room and update the server configuration.
Decide whether YouTube’s Auto-start setting fits the event you are using. That control concerns what YouTube does when it receives encoder data; it is not the same as systemd starting FFmpeg on the VPS. Review the matching Auto-stop and scheduled-event settings in the current interface, since a VPS process can be running while the YouTube event is not in the state you expect. YouTube’s live stream settings help explains the current controls.
For an H.264 stream over RTMP or RTMPS, YouTube’s encoder settings guidance recommends constant bitrate and a two-second keyframe interval, not exceeding four seconds. Select a bitrate for the resolution and frame rate you actually need, and check it against the VPS’s usable network capacity. RTMPS is the encrypted transport option YouTube recommends. Test the chosen settings rather than assuming a command that works on one file or connection will suit every source.
Create an encoder service under systemd
First test the encoder command interactively with a short test stream or a planned private/unlisted test event. A typical FFmpeg command needs to loop the media, map the intended video and audio streams, encode or copy in a YouTube-compatible format, and send output to the ingest URL with the stream key. The precise command depends on the input; do not copy a generic command without checking that its loop, mapping, codec and output options match your file.
Avoid putting the actual stream key directly in a script committed to version control. Store sensitive configuration in a protected file readable only by the service account and administrators, or use another secret-handling approach you understand. Make sure the unit’s user can read the media and configuration but cannot write to places it does not need. Keep credentials out of diagnostics you might later share.
Create a unit file such as /etc/systemd/system/youtube-encoder.service. The following is a skeleton; replace the paths, user and command with values tested on your VPS. It intentionally omits a real key and a complete FFmpeg invocation:
[Unit]
Description=YouTube live encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
WorkingDirectory=/srv/youtube
EnvironmentFile=/etc/youtube-encoder/stream.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/youtube/program.mp4 [your tested output options]
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This is not a ready-to-run command: the bracketed placeholder must be replaced with valid FFmpeg options and the actual ingest configuration must be handled safely. Confirm the FFmpeg binary path with command -v ffmpeg; check your distribution’s systemd and FFmpeg documentation for any version-specific details. The service account must be able to read the input and the environment file. Use restrictive file permissions for secrets, and consider whether your chosen method could expose them through process arguments or logs.
The unit’s network ordering expresses a startup dependency, not a guarantee that an Internet route or YouTube ingest endpoint is reachable indefinitely. A network can become unavailable after startup, and a service manager cannot infer that YouTube has received healthy media merely because the process stays alive. If your VPS needs a mount or another dependency before FFmpeg starts, model that explicitly and test the order after reboot.
Configure restart behaviour and start at boot
Restart=on-failure is one reasonable starting policy for an encoder expected to stay alive: it asks systemd to restart the service after a failure, rather than treating a clean exit as necessarily erroneous. Some operators use Restart=always when the process should be relaunched even after a clean exit. Choose based on the encoder’s intended exit behaviour and consult the systemd documentation for your operating-system release; a finite playlist that exits normally, for example, is different from a loop intended to run continuously.
RestartSec sets a pause before a restart attempt. A short delay may be useful after a process failure, but repeated failure can still produce a restart loop. Inspect the journal and fix the underlying cause rather than assuming repeated attempts will eventually succeed. Do not use an arbitrary periodic restart as a substitute for diagnosing freezes: it can interrupt a healthy stream and will not necessarily correct an invalid key, unsupported input or bad output configuration.
Once the unit file is in place, ask systemd to load it and enable boot startup:
sudo systemctl daemon-reload
sudo systemctl enable youtube-encoder.service
Enabling is not the same as starting. enable arranges for the unit to be pulled in by the relevant boot target; it does not, by itself, mean the encoder has started immediately. Start it separately when you are ready to test. The distinction matters when you check a fresh installation: a unit can be enabled but currently inactive, or active without being enabled for the next reboot.
If you change the unit file, reload systemd before restarting the service so it uses the updated definition. If you change only a configuration file, check whether your arrangement requires a service restart to reread it. Keep a record of the known-good command and configuration path, but do not record the stream key in an unprotected runbook.
Start and inspect the service
Start the unit and inspect its state:
sudo systemctl start youtube-encoder.service
sudo systemctl status youtube-encoder.service
A status of active (running) is a useful process-level check. It does not tell you whether FFmpeg has opened the intended file, mapped the right audio, connected to YouTube or delivered decodable output. Read the recent journal for startup errors and FFmpeg diagnostics:
sudo journalctl -u youtube-encoder.service -n 100 --no-pager
Look for obvious issues such as a missing input path, permission denial, invalid option, authentication rejection or repeated exits. If the service is restarting, diagnose before increasing restart frequency. A loop of failed launches can make logs harder to interpret and leave the audience with no useful feed.
Check that the encoder is using the intended file and that the service account has access. Confirm the expected process and output activity using tools available on your distribution, but do not treat CPU use or an open network connection as a substitute for YouTube-side confirmation. If you need to restart the unit after a configuration change, use sudo systemctl restart youtube-encoder.service, then return to both journal and Live Control Room checks.
For a headless operating pattern and its trade-offs, see running FFmpeg without a desktop environment. Running without a desktop reduces the number of moving parts you operate, but it also removes the visual preview you might otherwise use locally; arrange an independent check of the actual YouTube feed.
Verify YouTube stream health, audio and video
Open the event in YouTube Live Control Room after the encoder starts. Confirm that the preview shows the expected content and that YouTube reports the stream as receiving data with acceptable stream health. The exact labels in Studio may change, so use the current interface and help pages. If the preview does not appear, inspect the key, ingest URL, event selection, encoder logs and network path rather than repeatedly restarting without a reason.
Check picture and sound separately. Watch enough of the preview to confirm that the image changes as intended, the crop and orientation are right, and the loop transitions are not stuck on a blank or error frame. Listen for both channels if relevant, and verify that the intended audio is present at a sensible level without silence, clipping or an unintended track. A green-looking service status cannot tell you whether the selected file has a silent audio stream.
If you cannot monitor continuously, define how you will notice an issue and who will act on it. YouTube Studio’s stream health is useful for ingest and encoding indicators, but it does not establish that every viewer’s device, connection or playback path is working. Have a real person check the public playback from a separate device or network during initial setup and after any material configuration change.
Keep archive expectations separate from live continuity. YouTube says streams under 12 hours are automatically archived; that statement does not establish that a longer 24/7 broadcast will be preserved as one complete video. If retaining the source matters, keep your own source media and consider a separate recording and storage plan, then verify the current YouTube archive guidance before relying on a VOD.
Test process failure and VPS reboot recovery
Test process recovery during a controlled maintenance window, not during an important broadcast. First confirm the current process and YouTube preview are healthy. Then stop the FFmpeg process in a way that simulates its exit, and check whether systemd starts a new process according to the unit’s policy. Watch systemctl status, the journal and Live Control Room together. The process returning is evidence of process supervision, not evidence that the restarted output is healthy.
A practical test is to stop the service deliberately with systemctl stop; note that an intentional service stop is not the same as an unexpected process failure and systemd generally treats an administrator-requested stop differently from a failure for restart purposes. To test the failure policy, use a controlled method appropriate to your setup, then inspect the observed behaviour rather than assuming the policy’s effect. Avoid issuing a broad kill command on a shared VPS, and make sure you can restore the known-good service.
Then schedule a VPS reboot when you can watch recovery. Before reboot, confirm that the unit is enabled, the media and secret configuration survive the restart, and any required storage is available at boot. After reconnecting, inspect unit state and logs, then verify the YouTube preview, stream health, image and audio again. This checks boot enablement plus end-to-end recovery; neither should be inferred from the other.
Write down what each test established. For example: “systemd relaunched FFmpeg after process exit” is a process-level result; “YouTube preview showed the intended picture and sound after reboot” is an end-to-end observation at that time. Neither observation guarantees uninterrupted streaming or future health. Repeat checks after changing the source file, FFmpeg command, key, networking or system packages.
If this VPS is intended for a particular rain or ambience loop, the Linux VPS setup guide for a 24/7 rain stream offers related preparation context. Regardless of content, retain a simple recovery note: unit name, safe restart command, log command, media path and the steps to rotate a compromised key. Exclude secrets from the note.
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 my YouTube stream will stay live?
No. It can restart a process after certain exits and arrange for a service to start at boot, but it cannot guarantee that the feed is accepted or that viewers receive healthy video and audio. Check Live Control Room and the actual playback after recovery.
Is enabling the service enough to start it now?
No. Enabling configures boot startup; starting launches the service in the current session. Use both steps when appropriate, then verify the unit is active and YouTube is receiving the expected feed.
Should I use Restart=always or Restart=on-failure?
Choose according to whether a clean FFmpeg exit should lead to another launch. A loop intended to remain live may need different handling from a finite job; check the systemd behaviour for your release and test the policy before relying on it.
Will a 24/7 stream become one complete YouTube archive?
Do not assume so. YouTube’s stated automatic archive guidance applies to streams under 12 hours, not proof that a longer continuous broadcast is preserved as a single complete VOD. Check current YouTube Help and keep a separate recording plan if retention matters.