A Linux machine can launch an FFmpeg YouTube stream after every reboot by running FFmpeg as a systemd service and enabling that service for the normal multi-user boot target. Store the stream key separately, wait for the network, and configure recovery for both an exited process and temporary output failures.
You still need to check YouTube Studio after the machine comes back. An active (running) systemd service proves that a process is alive, not that YouTube has accepted the stream or that viewers are receiving healthy audio and video.
Plan the FFmpeg and YouTube workflow
Before creating a service, make the manual stream work from the same Linux account and with the same input file that the service will use. A boot service removes the need to log in and start a command, but it does not correct an FFmpeg command that already fails, a media file that cannot be read, or a YouTube broadcast that has ended.
The pattern below assumes:
- Linux with systemd
- FFmpeg installed at
/usr/bin/ffmpeg - a dedicated account called
stream - a loopable local file under
/srv/stream - a YouTube live stream and stream key already created
- network access to the selected YouTube ingest endpoint
Use your actual account, paths and input. Do not copy an example endpoint, codec setting or bitrate as if it were a permanent YouTube rule. YouTube’s current live-streaming guidance can change by account, region and setup, so check the official YouTube live streaming help before finalising the encoder settings.
A simple workflow is:
- Test FFmpeg in a terminal.
- Put the key in a file readable by the service account but not by ordinary users.
- Put the command in a systemd unit.
- Start it manually through systemd and inspect the journal.
- Enable it for boot.
- Reboot during a planned maintenance window.
- Check both the local service and YouTube Studio.
If your source is a long video or a playlist, decide how it should behave at the end. A looping input is usually more suitable for an always-on channel than a command that exits when one file finishes. The guide to keeping a product demo stream running after a video ends explains the same problem from the content side.
FFmpeg’s output protocol also matters. FFmpeg describes RTMPS as “The Real-Time Messaging Protocol over a secure SSL connection” in its protocol documentation. Use the endpoint and transport specified for the YouTube stream you are configuring, rather than assuming that an old command found in a forum is still appropriate.
Store the stream key in a restricted file
Do not place the stream key directly in a public script, a Git repository, a screenshot or a shell command that you repeatedly paste into a shared terminal. Create a directory for the service configuration and an environment file that only root and the service group can read.
For example, an administrator could create the directory and file with commands such as:
sudo install -d -o root -g stream -m 0750 /etc/stream
sudo install -o root -g stream -m 0640 /dev/null /etc/stream/ffmpeg.env
sudoedit /etc/stream/ffmpeg.env
Put the key in the file without posting a real key in documentation:
YOUTUBE_STREAM_KEY=replace-with-the-real-key
The 0640 mode means that root has full access, members of the stream group can read the file, and other users have no permission. Confirm that the service account belongs to the intended group and that it can read the file. Do not make the file world-readable simply because systemd reports a permission error. Fix the ownership or group instead.
Keep the file limited to values the service needs. If you add paths or options, check how systemd parses environment files and avoid shell syntax that only works in an interactive shell. A value containing unusual characters may need careful handling, and changing a stream key may require a service restart before the new value is used.
An environment file reduces accidental exposure in shell history and configuration repositories, but it is not magic secrecy. A key may still be visible to a process or to an administrator inspecting the running service. Limit administrative access, do not paste journal output containing the key, and rotate the key in YouTube if it has been exposed. YouTube’s official guidance on live encoder settings is the right place to check the current platform-side setup.
Create a systemd service
Create a unit at /etc/systemd/system/ffmpeg-youtube.service. The following is a structure to adapt, not a command to copy without testing:
[Unit]
Description=FFmpeg YouTube loop
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
Group=stream
WorkingDirectory=/srv/stream
EnvironmentFile=/etc/stream/ffmpeg.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/stream/channel.mp4 -c:v libx264 -c:a aac -f flv rtmps://YOUR-INGEST-ENDPOINT/${YOUTUBE_STREAM_KEY}
Restart=always
RestartSec=15
TimeoutStopSec=15
KillSignal=SIGINT
StandardOutput=journal
StandardError=journal
NoNewPrivileges=true
PrivateTmp=true
[Install]
WantedBy=multi-user.target
The input path, encoder choices and ingest URL must match your channel. Test them outside the service first. The example uses a continuously looped file, real-time pacing and an FLV output format commonly used with RTMP-based publishing. It does not establish the current YouTube bitrate, frame-rate, codec or keyframe requirements for your account.
User=stream and Group=stream prevent the command from running as root. Give that account access only to the media and configuration it needs. The working directory makes relative paths predictable, although absolute paths are easier to diagnose in a boot service.
EnvironmentFile loads the key without putting it in the unit text itself. The ${YOUTUBE_STREAM_KEY} expression is expanded for the command by systemd. Because the resulting argument may be observable while FFmpeg is running, continue to treat the host as a trusted administrative environment.
The network ordering lines express a startup relationship, not a guarantee that the internet is usable at that exact moment. A machine can have a network interface up while DNS, routing or the remote ingest service is still unavailable. That distinction is one reason to test recovery after the initial launch.
StandardOutput=journal and StandardError=journal keep FFmpeg’s messages available through journalctl. This is more useful than sending output to a terminal that does not exist after logout. Avoid adding verbose options indefinitely without checking disk and journal retention policies.
Enable launch after reboot
After creating or changing the unit, ask systemd to reload its unit definitions:
sudo systemctl daemon-reload
Start it without rebooting so you can deal with errors while you are present:
sudo systemctl start ffmpeg-youtube.service
sudo systemctl status ffmpeg-youtube.service
If the command starts correctly, enable it for the boot target:
sudo systemctl enable ffmpeg-youtube.service
enable creates the relationship that causes systemd to start the service during the normal multi-user boot sequence. It does not necessarily start the service immediately, which is why start and enable are separate actions. If you want both actions together, use:
sudo systemctl enable --now ffmpeg-youtube.service
Use systemctl is-enabled ffmpeg-youtube.service to check the boot setting and systemctl is-active ffmpeg-youtube.service to check its current process state. These answer different questions. A service can be enabled but currently stopped, or active but not enabled for the next reboot.
Do not test a first boot launch by abruptly cutting power if the machine also stores important files. Once the service works manually, schedule a controlled reboot and note the expected input path, account and YouTube stream before starting. If the host is in a shop, prayer room or office, also consider whether a power cut leaves the router and machine in a usable order.
For smaller devices, resource limits and storage deserve attention. A Raspberry Pi may run a modest loop but can struggle with a demanding encode, heat or an unreliable storage device. The Raspberry Pi 24/7 YouTube loop guide covers those constraints separately; systemd does not remove them.
Will Restart=always reconnect the stream after every failure?
No. Restart=always tells systemd to start the service again when the service process stops. With RestartSec=15, it waits before attempting that start. In the example, this is useful if FFmpeg exits because of a temporary process-level problem or a failed output attempt that causes FFmpeg to terminate.
It does not repair every failure. A bad or revoked key can make every new FFmpeg process fail. A missing input file can produce the same result. An unavailable route, DNS failure, rejected broadcast or YouTube-side interruption can persist while systemd repeatedly launches an otherwise unchanged command.
There are two recovery layers to consider:
| Failure behaviour | What may help | What it cannot establish |
|---|---|---|
| FFmpeg exits | Restart=always with a delay |
That the next process will authenticate or find its input |
| FFmpeg remains alive but output temporarily fails | FFmpeg output recovery options, where supported by the build and endpoint | That YouTube accepted the recovered output |
| Network, key or media condition remains broken | Diagnosis and correction of the underlying condition | That repeated restarts are a cure |
| YouTube broadcast ends or is rejected | Check YouTube Studio and the stream configuration | That a local process can reopen the platform-side state |
FFmpeg documents a FIFO muxer recovery pattern using -f fifo, -fifo_format flv, -drop_pkts_on_overflow 1, -attempt_recovery 1 and -recovery_wait_time 1. The FFmpeg formats documentation shows this pattern for a generic RTMP destination. It is distinct from systemd: the FFmpeg process continues trying to handle an output problem instead of exiting and waiting for systemd to start a new process.
Do not add those options automatically to every command. Validate the syntax with the FFmpeg build you installed and with the selected ingest endpoint. Output recovery can preserve the process while hiding a prolonged publishing problem, and dropped data may affect what viewers eventually see.
Conversely, a process restart may be appropriate when FFmpeg has exited and cannot recover internally. The sensible setting depends on the failure mode. Treat Restart=always as a process supervisor setting, not as a promise that a YouTube channel reconnects after every failure.
If a persistent fault causes rapid restarts, the journal will show the same error repeatedly. A restart delay reduces the speed of that loop but does not solve it. Stop the service, correct the key, input, permissions or network condition, and start it again.
Check systemd status and logs
Start with the concise status view:
sudo systemctl status ffmpeg-youtube.service
Look for the loaded unit, whether it is enabled, the current Active state, the main process ID and recent log lines. Read active (running) as “the service process is currently running”. Do not read it as “YouTube is receiving a valid programme”.
For the complete recent journal:
sudo journalctl -u ffmpeg-youtube.service --since "30 minutes ago"
To follow new messages while testing:
sudo journalctl -u ffmpeg-youtube.service -f
The time range is only an example. Choose a window that covers the reboot or failure you are investigating. If you need the previous boot’s messages, use systemd’s boot filtering and confirm that your distribution retains those logs.
Useful evidence includes whether FFmpeg found the input, whether the file contains the expected audio and video streams, whether the process received a termination signal, and whether the output connection was refused or closed. Preserve the useful error wording before changing several things at once. A restart can make a clear original error harder to locate.
Check permissions separately. The service account must be able to traverse /srv/stream, read the media file and read /etc/stream/ffmpeg.env. A file can be readable while one of its parent directories blocks access. Test as the service account where appropriate, without printing the key:
sudo -u stream test -r /srv/stream/channel.mp4 && echo media-readable
sudo -u stream test -r /etc/stream/ffmpeg.env && echo environment-readable
If the unit fails immediately, inspect the unit text and the expanded status output. A typo in ExecStart, an incorrect FFmpeg path, an invalid environment file or a missing working directory can prevent the process from starting. If it starts and exits, the error is more likely in FFmpeg’s input, output or runtime environment.
Network recovery needs separate observation. Confirm DNS and routing from the host, but do not assume a successful connection to another website proves that the YouTube ingest path is available. If the service cycles, temporarily stop it while investigating rather than allowing a persistent fault to generate an endless stream of identical attempts.
Verify the broadcast in YouTube Studio
After a reboot, check YouTube Studio as well as the Linux host. Open the live control room for the stream and inspect its preview, connection or stream health indicators and recent errors. The exact labels can change, so use the current YouTube Live Control Room help for the interface and workflow.
Use both sides of the check:
systemctl statusconfirms the local service state.journalctlshows what FFmpeg reported.- YouTube Studio shows whether the platform sees and processes the incoming stream.
- The public watch page, when available, confirms what a viewer-facing session receives.
A service can remain active while FFmpeg is unable to publish useful packets, while the key is invalid, while the input has no usable video, or while the platform-side broadcast is no longer available. It is also possible for a short interruption to leave the local process running while the viewer experience is degraded.
If Studio reports that the stream is not receiving data, begin with the journal and key file, then check the input and endpoint. If Studio shows a warning about video, audio or stream health, compare the actual FFmpeg output with YouTube’s current requirements rather than relying on an old preset. The FFmpeg bitrate checklist for YouTube streams can help organise that review, but the official platform guidance remains the authority for current requirements.
A content problem is separate from an infrastructure problem. Copyright claims, eligibility, scheduled-stream settings or a broadcast that has been stopped in Studio will not be fixed by changing RestartSec. Review the current YouTube live streaming eligibility requirements before treating a rejected or unavailable broadcast as a Linux failure.
If maintaining the machine, updates, storage, network and recovery behaviour is more work than you want to own, StreamNeo removes the need to keep your own computer running for this particular YouTube workflow: upload the file once, provide the stream key, and let the hosted stream run while you monitor the result in YouTube. It remains your responsibility to check the channel, media rights and platform status.
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 start FFmpeg before the network is ready?
The unit’s network-online.target relationship asks systemd to start it after the system’s network-online target. That ordering is useful, but it cannot guarantee that DNS, routing or the remote ingest service is ready or healthy. Keep process restart and output recovery settings appropriate for a later connection failure.
Should I use Restart=always or Restart=on-failure?
Restart=always restarts the service whenever its process stops, including some clean exits. Restart=on-failure is narrower and may be preferable when a deliberate clean stop should remain stopped. Neither setting fixes a bad key, missing media or a YouTube-side broadcast problem.
Why is systemd active but YouTube showing no stream?
Systemd reports the state of the local service, while YouTube Studio reports the platform’s view of the broadcast. Check the journal for FFmpeg input and output errors, then check the key, endpoint, encoder settings and broadcast state in Studio.
Can I put the stream key directly in the service file?
You can, but a restricted environment file is easier to protect and replace without mixing the secret into the unit definition. Keep the file owned by root, readable by the service group, and out of repositories, screenshots and shared logs. Rotate the key if it has been exposed.