A Linux systemd service can start and supervise an encoder such as FFmpeg, including after a host reboots. It cannot by itself show that YouTube is receiving a usable picture and sound, or that the broadcast is visible to viewers.
The reliable approach is to get a manual encoder run working first, then place that known command under systemd and verify both the local process and the state in YouTube Live Control Room. The commands and unit examples below are starting points: paths, permissions, FFmpeg options and systemd behaviour depend on your distribution and configuration.
Separate process status from broadcast health
There are three separate states to check. First, systemd may report that the FFmpeg process is active. Second, the process may be sending data to YouTube’s ingest server. Third, YouTube may show a healthy preview or live broadcast in Live Control Room. A positive result at one stage does not prove the next one.
For example, a process can remain active while repeatedly failing to read an input file, or it can run while a firewall or network interruption prevents its output reaching YouTube. The service manager is responsible for the process lifecycle; it does not validate the stream key, repair a media file or decide whether the broadcast is visible. Treat systemctl status as a local diagnostic, not as an audience-facing health check.
A restart policy helps with a narrower problem: the encoder process exits. It can ask systemd to start that process again according to the chosen policy. It does not fix incorrect credentials, absent media, an unavailable network or a broadcast that has ended. If the same fault persists, the process may simply fail again.
Keep a short checklist for each state: service active, encoder output reaching YouTube, and preview or live state in Studio. The live streaming checklist for YouTube creators is useful for the broader preparation around a broadcast, but this guide focuses on unattended Linux operation.
Prepare the Linux encoder and media inputs
Before writing a unit file, choose the host and make sure the media can be read there. A home computer must remain powered on and connected; a hosted Linux machine avoids depending on that computer, but brings its own storage, network-transfer, CPU and administration considerations. A Linux VPS for an always-on stream may suit a command-line workflow, but compare its sustained processing capacity, transfer allowance, storage, location and total cost for your actual files and output settings. Do not assume a particular provider or machine size will work without checking the vendor’s current terms and testing your workload.
Install FFmpeg using a trusted source appropriate to your distribution, and check that the executable is available to the account that will run the service. Confirm the input file’s path and permissions. If your programme uses several files, playlists, subtitles or external audio, check each dependency rather than testing only the first video. Use absolute paths: a service does not necessarily start in the directory you expect from an interactive shell.
For prerecorded content, FFmpeg can read and loop media and send encoded output to YouTube’s ingest endpoint. The exact input and output options depend on the file, desired stream and current YouTube requirements. The public Ubuntu continuous-stream example illustrates one implementation, but its command, file paths and choices are specific to that repository. It is a community example, not a controlled test or a universal recipe.
First run the intended encoder command manually as the same unprivileged account you plan to use with systemd. Check that it opens every input, produces the expected audio and video, and reaches a YouTube preview. If it fails here, systemd will not make the media or command work. For a repeating sequence, decide how the files should cycle and test that transition; the guide to looping a video to YouTube Live with VLC covers a different tool and may help clarify the content-looping question.
Create a systemd service for the encoder process
Once the manual run is working, create a service unit to define how systemd starts it. The example below is a skeleton, not a tested drop-in configuration. Replace the account, paths and command with values that fit your machine, and consult the documentation installed for your distribution if a directive behaves differently.
[Unit]
Description=YouTube live encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
Group=stream
WorkingDirectory=/srv/stream
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/stream/programme.mp4 -f flv rtmp://INGEST-URL/STREAM-KEY
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This illustrates a simple service whose main process is FFmpeg. It assumes FFmpeg is at /usr/bin/ffmpeg, the input is readable by stream, and the output URL is correctly constructed. Those assumptions may not hold on your machine. Check the output format and encoder options against the media and YouTube’s current guidance, and use the actual server URL and key shown for your stream rather than copying the placeholder.
A dedicated, unprivileged service account limits what the encoder can access compared with running the process as root. Give it access only to the input files and directories it needs, and ensure it can write any logs or temporary files your command requires. WorkingDirectory can make relative references predictable, but absolute paths in the command and any playlists are easier to audit.
Wants and After express ordering and a dependency relationship with the network-online target; they do not prove that DNS, a route to YouTube or a working internet connection is available. Network readiness can also depend on the distribution’s network manager and its configuration. If startup races with network availability, inspect the logs and the host’s network setup rather than assuming that adding a target guarantees connectivity.
The systemd project documents service startup in relation to boot targets and service behaviour in its systemd documentation. Treat the unit as configuration to review and validate on your own Linux system, not as a cross-distribution guarantee.
Configure restart behaviour and reboot startup
Restart=on-failure asks systemd to restart the service when it exits unsuccessfully, subject to systemd’s restart rules and any configured limits. Restart=always is broader: it also restarts after a clean exit, apart from cases systemd treats specially. Choose based on how the encoder is expected to finish. A continuous loop that exits unexpectedly may call for on-failure; a command designed to end and be relaunched may need another arrangement. Neither setting means that a stream is guaranteed to stay live.
RestartSec sets a delay before an attempted restart in this example. Repeated failures can still reach systemd’s start limits, and the appropriate recovery may be to inspect the underlying error rather than repeatedly launch the same broken command. A restart loop can add noise to the journal and consume resources without restoring service. Check the service’s restart count and logs as well as its current state.
After saving a unit under the appropriate systemd directory, reload systemd’s unit definitions, start the service and inspect its status. If the unit is meant to start with the machine, enable it for the selected boot target. The common commands are:
sudo systemctl daemon-reload
sudo systemctl start youtube-stream.service
sudo systemctl status youtube-stream.service
sudo systemctl enable youtube-stream.service
Enabling a service arranges for it to be started through the configured boot target; it is distinct from starting it immediately. The systemd startup-target documentation explains the relationship between units and startup. Confirm the enabled state on your machine, and after a planned reboot check both the unit and YouTube preview. A successful boot start only confirms a local launch attempt.
A managed cloud workflow can remove the task of keeping your Linux host on and maintaining this process lifecycle: StreamNeo takes an uploaded video and your YouTube stream key to run the broadcast while your computer is off, with monitoring and automatic process restarts if it drops. It is YouTube-only, so it is not a fit if you need to send one encoder output to other platforms or customise a Linux process directly.
Protect and verify stream credentials
Your stream key is a credential that lets an encoder send content to the associated YouTube stream. Keep it out of public repositories, shared scripts, screenshots and support transcripts. Avoid placing it directly in a command line that may be retained in shell history or exposed in process listings. The safest method depends on your system and how your FFmpeg command obtains the output URL; use a restricted configuration or secret-handling approach suitable for your host, and limit read access to the service account and administrators who need it.
The sample command above is deliberately schematic. Do not paste a real key into a unit file and then publish or broadly share that file. Unit files and diagnostic output may be readable by more people than you intend. Review file ownership and permissions, and check that scripts do not print the full URL. If the key is exposed, replace or rotate it using YouTube Studio and update the encoder configuration; restarting the unchanged command will not correct a compromised credential.
In YouTube Studio, create or select the live stream and copy the current server URL and stream key into the encoder configuration. YouTube’s instructions for creating a live stream with an encoder explain the workflow. Verify that you have selected the intended stream and that its settings match the output you plan to send. Do not rely on an old key copied from a different event or channel.
Check logs, network and media availability
Use systemd’s journal to see what the process reports. For example, journalctl -u youtube-stream.service -n 100 --no-pager requests recent entries for that service; add -f when you want to follow new output during a test. Output varies by FFmpeg build and command, so look for the actual error rather than expecting a particular message. Check for missing-file errors, permission problems, invalid options, authentication failures and connection errors. Avoid sharing logs without first removing stream keys and other private details.
If the service is active but the picture does not appear, work through the layers. Verify the input file exists at the configured path and is readable by the service user. Check that the encoder has not stalled or exited, that the URL and key are current, and that the host can reach the ingest service. A local test using the same account and command can help isolate whether the issue is in the unit environment or the command itself. The environment in a systemd service can differ from your shell, including PATH, working directory and available permissions.
Check disk space and the host’s available processing capacity if the encoder cannot keep up, and review the network path if output repeatedly disconnects. These checks identify possible causes; they do not establish that a given host or connection is sufficient. If you change input files or configuration, test the revised command and then confirm the resulting YouTube preview again.
For material where titles, slides or small text need to remain legible, output settings deserve particular attention. The YouTube bitrate guide for text-heavy educational streams discusses that separate trade-off. Whatever settings you choose, do not treat a clean FFmpeg log or an active systemd state as proof that viewers see a healthy broadcast.
Verify the broadcast in YouTube Live Control Room
After starting the encoder, open the corresponding stream in YouTube Studio’s Live Control Room. Wait for YouTube to show an incoming preview, then check that the picture and sound are as intended. If you are using a scheduled stream, YouTube’s workflow includes waiting for preview and going live in Live Control Room. The encoder can be sending data while the event still needs an action in Studio.
Check status again after a service restart, host reboot or network interruption. A process can restart locally without YouTube resuming the broadcast in the way you expect. Confirm the current preview or live state in Studio rather than relying on a previous test, and check the viewer-facing page if you need to establish what the public can see. Keep a human escalation path for cases where the stream is not restored, especially if the content has a time-sensitive schedule.
YouTube Help says that first-time live-stream enablement may take up to 24 hours. Plan setup ahead rather than discovering that delay just before a scheduled launch. Its guidance also says that streams under 12 hours are automatically archived; that archive information is not evidence that a broadcast can run indefinitely, nor does it prescribe a restart schedule. Check YouTube’s current help page for the applicable details.
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
How do I stream to YouTube 24/7 from Linux?
Prepare a media source and an encoder command that you have tested manually, then run that command under a systemd service configured for your host. Use YouTube Studio’s current server URL and stream key, and verify the incoming preview and live state in Live Control Room. An active Linux process alone does not confirm that viewers can see the stream.
Will systemd restart my stream after a reboot?
If you enable the service for the relevant boot target, systemd can attempt to start it when the machine boots. Whether it reaches YouTube depends on the unit, network, media, credentials and stream state, so check both the local service and Live Control Room after reboot. Enabling a unit is not a guarantee of a healthy broadcast.
Where do I get the YouTube stream key?
In YouTube Studio, create or select the stream and use its displayed stream key and server URL in your encoder configuration. Treat the key as a secret, restrict access to it and rotate it in Studio if it is exposed. Do not put it in a public repository or an unredacted log.
How can I tell whether the stream is actually live?
Check systemd and the journal for the local encoder, then check the matching stream in YouTube Live Control Room for preview or live status. For scheduled streams, follow YouTube’s steps to preview and go live. A running FFmpeg process is only one part of that check.