To keep an encoder process running on Ubuntu after boot or a failure, run it in the foreground as a systemd service and configure a retry delay. That can restart the local process; it cannot confirm that YouTube has accepted the stream or that the intended event is live.
The reliable pattern is to check the media and Live Control Room details first, test the encoder command by hand, and then let systemd supervise that same command. You will also need to plan for YouTube event and archive behaviour separately: a continuously running service is not the same thing as one YouTube event that runs indefinitely.
Check the media, encoder and YouTube details
Before writing a service file, establish that the pieces work together. A unit file can make a command start at boot, but it cannot repair a missing input file, an unsupported FFmpeg option or the wrong stream key. Test the whole path in the foreground before adding automatic retries, so the first error is visible rather than repeated after every restart.
Confirm the absolute path to the media and make sure the Linux account that will run the service can read it. Check that the file plays and that its video and audio tracks are the ones you intend to broadcast. For a playlist or loop, validate the transitions and confirm that playback continues as intended; a process that remains alive while showing a frozen frame is not a successful channel. If you are building a programme from a sequence of clips, the article on making FFmpeg switch between video playlists covers the separate media-logic problem.
Check which FFmpeg build is installed and verify that it includes the encoders and muxing options your command needs. Paths vary between systems, so find the executable on your host rather than assuming that /usr/bin/ffmpeg is correct. Keep the command’s input and output settings tied to the actual file: a template copied without checking can fail on a different media format or package build.
In YouTube Live Control Room, confirm which event and stream you mean to use. Copy the ingest URL and key from the intended stream configuration, and select the RTMPS URL. YouTube’s live-stream encoder setup guidance explains how to find the URL and key and configure an encoder. The key is sensitive: YouTube describes it as the stream’s “password and address”. Do not put a real key in a public script, a shared support ticket or a command pasted into a shell whose history is readable by others. If you think it has been exposed, reset it in YouTube and update the local configuration.
Choose video and audio settings from YouTube’s current recommended live encoder settings, then check that your host can encode the material and that your upload connection can carry it. The recommended bitrate depends on codec, resolution and frame rate; it is not a measurement of your server’s upload capacity. For example, YouTube lists H.264 1080p at 30 frames per second at a recommended 10 Mbps, and H.264 720p at 30 frames per second at 6 Mbps. Treat these as YouTube guidance for those combinations, not as a universal setting or a guarantee that your connection can sustain them.
For a practical comparison, compare the actual settings you plan to use:
| Example video configuration | YouTube-listed recommended bitrate | What to check on your side |
|---|---|---|
| H.264, 1080p, 30 fps | 10 Mbps | Whether upload capacity remains adequate while other host traffic is active |
| H.264, 720p, 30 fps | 6 Mbps | Whether the lower resolution suits the material and remains legible to viewers |
These figures are recommendations in YouTube Help; consult the current table before publishing or changing a configuration. A bitrate does not account for every network condition, and the right resolution is not necessarily the highest one the machine can encode. For devotional audio with a still image, for example, a modest video configuration may be more suitable than a high-resolution encode that consumes host capacity without helping the viewer.
Test the encoder in the foreground
Run the exact encoder command as the intended service user before putting it in a unit. This lets you see whether the file opens, the encode starts, the key and destination are accepted, and YouTube receives a preview. Stop the test cleanly when you have confirmed it; avoid running a manual encoder and the system service against the same event at once.
A generic FFmpeg command should be treated as a template, not as a universal working recipe. Input options depend on the media and how it should repeat; encoding options depend on the FFmpeg build and the YouTube settings you selected. A deliberately incomplete service example appears below, but the actual command must be assembled and tested on the target Ubuntu system. Do not assume that a particular reconnect flag, codec option or loop behaviour works for every build and input.
Check the service account’s permissions while testing. If the eventual service will run as stream, test access to the media and configuration as that account, not only as your administrator account. Also check the working directory: relative paths that work in an interactive shell can fail when systemd starts the process from a different location.
Keep credentials separate from the command where practical. A root-controlled environment file or another restricted configuration mechanism helps keep the key out of a broadly readable unit file. Set permissions so only the appropriate administrator and service account can access the credential. Inspect logs after the test to ensure the key has not appeared in output; environment files reduce accidental exposure but do not make it impossible for an application or diagnostic command to disclose a secret.
For a long-running channel, media behaviour deserves a separate test from connectivity. Confirm that the input really loops or advances through its programme rather than reaching the end and exiting. If your channel relies on avoiding repeated items, plan that at the playlist level; preventing duplicate episodes in a story playlist is a different issue from restarting a failed FFmpeg process.
Put the foreground process under systemd
A system service should run the encoder as its main foreground process. Do not background FFmpeg with &, wrap it in a shell that exits immediately, or configure systemd to supervise a short-lived launcher while the actual encoder escapes. If systemd tracks the wrong process, status and restart behaviour become harder to interpret.
A unit can express the general arrangement like this:
# /etc/systemd/system/youtube-stream.service
[Unit]
Description=YouTube Live encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
WorkingDirectory=/srv/stream
EnvironmentFile=/etc/youtube-stream/credentials
ExecStart=/usr/bin/ffmpeg <input-and-encoding-options> -f flv <RTMPS-URL-with-protected-key>
Restart=on-failure
RestartSec=10s
[Install]
WantedBy=multi-user.target
Every value in angle brackets is a placeholder. Replace it with a tested command suited to the installed encoder, chosen media and stream details; never paste a real key into an example intended for publication. Check that the account exists, the paths are correct, the environment file is readable by the service, and the destination is the RTMPS address for the intended YouTube stream. Unit syntax and available options should also be checked against the Ubuntu and systemd release on the host.
Type=simple tells systemd to treat the process it launches as the service process. User avoids running the encoder as root when a dedicated account is suitable. WorkingDirectory makes relative paths predictable, though absolute paths in commands are usually easier to audit. Wants and After express a relationship to the network-online target; they do not prove that the host has working internet access or that YouTube is reachable. Network readiness can depend on the machine’s network configuration.
Restart=on-failure asks systemd to restart the service after qualifying failures. RestartSec adds a pause before a restart attempt. Neither setting makes a bad key valid, restores a damaged file or fixes an unavailable network. In particular, do not use a restart loop as a substitute for checking why the encoder exits.
For a continuous yoga or meditation presentation, the host is only one part of the operating choice. A self-managed Ubuntu machine gives you control over the encoder and service, but you remain responsible for updates, permissions, monitoring and recovery. If you are weighing that against renting a virtual machine, the low-cost VPS considerations for a continuous yoga nidra stream can help frame the host decision. This article focuses on supervising an encoder on Ubuntu, not on promising a particular host’s availability.
Enable the service at boot and start it
Save the unit under /etc/systemd/system/youtube-stream.service, adjusting the name consistently if you choose a different unit name. After editing a unit, tell systemd to reload its unit definitions, then enable and start the service:
sudo systemctl daemon-reload
sudo systemctl enable --now youtube-stream.service
systemctl status youtube-stream.service
Enabling the unit arranges for it to start through the selected boot target; --now also starts it immediately. Check the status output for whether the service is active and whether the process has exited or is restarting. A status of active is evidence about the local unit, not proof that YouTube is receiving usable video or that the correct event is live.
If startup fails, do not repeatedly edit and restart without reading the error. Check the unit name, executable path, permissions, working directory, environment file and FFmpeg output. Run sudo systemctl cat youtube-stream.service to inspect the unit systemd has loaded, and compare it with the command you tested. After any unit-file change, run daemon-reload again before restarting the service.
You can also check that boot enablement is in place with systemctl is-enabled youtube-stream.service. For a controlled test, reboot only when you can monitor the host and the YouTube event, then check both sides afterwards. A successful boot start shows that the local service can launch under that boot sequence; it does not establish that every future network, media or YouTube event condition will be healthy.
Set a retry delay and inspect logs
A brief pause between attempts is useful because an immediate loop can generate a stream of repeated failures without giving you time to diagnose them. RestartSec=10s in the example is an illustration, not a universally correct delay. Choose a delay that fits how quickly you need to notice a dropped process and how you will handle a persistent fault; the cited systemd documentation defines the setting but does not prescribe one ideal value.
The relevant systemd behaviour is documented in the systemd.service manual. Restart=on-failure covers process failures, while intentional stops made by an operator are not the same thing as an unexpected failure. Automatic restart attempts are also subject to systemd start-rate limits. A service that fails repeatedly can reach those limits rather than retrying forever, so inspect the result instead of assuming every failure will be followed by a successful restart.
Use status and the journal together:
systemctl status youtube-stream.service
journalctl -u youtube-stream.service -n 100 --no-pager
Status gives a compact view of the current state and recent exit information. The journal helps identify whether FFmpeg could open an input, connect to the destination, or encountered an option or permission problem. If the output is too sparse, adjust diagnostics carefully and ensure that the key is not printed. Logs should help explain failure without becoming another place where credentials are exposed.
When you see repeated restarts, separate transient and persistent causes. A brief connection loss may clear on retry; a wrong stream key, invalid media path or unsupported option will generally fail again until corrected. Check the underlying cause, correct it, and then restart deliberately. If systemd reports a start-limit condition, understand why the attempts accumulated and follow the systemd documentation for the host’s configured limits rather than increasing them blindly.
For operational checks, think in layers: is the unit enabled, is its process active, is the input progressing, does the host have outbound connectivity, and does YouTube show the expected incoming preview? These are distinct observations. If you want a separate guide to recovery behaviour for a different host environment, the article on automatically restarting a YouTube live stream on a DigitalOcean droplet addresses that platform rather than substituting for checks on your Ubuntu machine.
Check RTMPS and YouTube stream health
Once the local service is active, open Live Control Room and inspect the intended stream. Confirm that the preview appears and that YouTube reports an incoming encoder connection in the expected event. Check that the image and audio are actually usable; an incoming signal can still have the wrong content, silence, a frozen frame or settings that YouTube flags.
YouTube recommends RTMPS, an encrypted version of RTMP. The control room can show an RTMP address by default, so make sure the encoder destination is the RTMPS URL when that is what you intend to use. Do not assume that changing the scheme or address manually is harmless: copy the URL shown for the selected stream. The RTMPS switching guide explains the address change as a separate configuration task.
Compare the received video with the settings you chose: codec, resolution, frame rate, bitrate and keyframe interval. YouTube’s encoder guidance includes supported formats and recommendations, including a recommended two-second keyframe interval that should not exceed four seconds. The recommendation is not a guarantee that the particular build, file or network will behave as intended; verify the actual preview and warnings in YouTube. If YouTube reports a connection or stream problem, check the key, URL, encoder output and internet path rather than treating an active systemd unit as the final health signal.
A useful recovery test is to observe what happens when the encoder exits under controlled conditions, then verify separately that systemd restarts the process and YouTube receives the renewed connection. Avoid disrupting a real audience-facing event just to test a theory. A restart can restore the local process while the YouTube event remains in a different state, so make sure the event is still the one you expect and that Live Control Room reflects the recovered ingest.
If this work is taking too much attention from checking files, stream keys and event state, StreamNeo can remove the need to keep a personal Ubuntu encoder machine running: upload the video, provide the YouTube stream key, and the broadcast runs with your computer off. It does not remove the need to check YouTube’s event state, content rights or current streaming settings.
Plan event boundaries and archive expectations
Plan the broadcast as two connected but separate systems. Your systemd service can supervise a local encoder process; YouTube controls the event and the handling of its archive. YouTube states that encoder streams under 12 hours are automatically archived. That statement is about archive behaviour for streams within that duration, not a promise that one event can stay live indefinitely, and not an instruction for systemd to create a new event afterwards.
Decide whether your channel needs a single scheduled event, repeated events, or a viewer-facing presentation that returns to a new event when a session ends. Then inspect the current Live Control Room settings for scheduling, auto-start, auto-stop and intended archive behaviour. YouTube’s live-stream settings documentation describes encoder-controlled auto-start and auto-stop options when enabled. Verify how those settings interact with your actual event before depending on them; the service unit does not make that decision for you.
If a planned session ends, you need a deliberate handoff. Decide who or what will create or select the next event, how the correct stream key and URL will be used, and who will verify that viewers have reached the intended live page. A simple FFmpeg restart within the same event should not be confused with a new scheduled event or with a completed archive. Test the transition in a way that does not risk an important broadcast.
Archive expectations affect the source file and channel workflow as well. Check that the media is appropriate for the audience and that the account’s rights and YouTube settings allow the intended use. The fact that a stream can be received or archived does not settle rights questions. For channels built around licensed devotional music, review the context in using a music label’s written permission on a nonstop stream and confirm the current requirements with the relevant rights holder and official YouTube guidance.
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 keep the YouTube stream live if FFmpeg stops?
Systemd can be configured to restart a failed local process, subject to its restart rules and start-rate limits. It cannot ensure that the restarted process has a valid input, can reach YouTube or reconnects to the intended live event, so check both systemd and Live Control Room.
Does an active service mean viewers can see the stream?
No. An active status describes the local service process, not the end-to-end broadcast. Check the input, encoder output, YouTube preview and event state before treating the channel as healthy.
Can one YouTube event stay live indefinitely?
Do not plan on that assumption. YouTube says encoder streams under 12 hours are automatically archived, but this does not establish an indefinitely live event; check current event settings and plan a session boundary or handoff.
Should I put the stream key directly in the unit file?
Avoid placing a real key in a unit file that other users or support systems can read. Use a restricted configuration mechanism, protect its permissions, and check that logs do not disclose the key; reset it in YouTube if it is exposed.