A Linux update can stop an FFmpeg process, and a reboot ends the process outright. To start it again unattended, run your working command as a systemd service, enable that service at boot, and inspect its journal and YouTube stream status after recovery.
Systemd can restart FFmpeg after eligible process failures and start it after a reboot, but neither setting repairs a bad command, invalid ingest details, or a network problem. Plan for a gap while the host restarts, then verify that the broadcast actually reconnects.
Why an update can interrupt FFmpeg
An FFmpeg command started in a terminal belongs to that process and its session. Closing the session, losing the SSH connection in some setups, or rebooting the host can end the process. If an update installs changes that require a reboot, the live encoding process stops while the machine shuts down.
Ubuntu’s unattended-upgrades can be configured to reboot when an update requires it; its documentation describes the available automatic-update settings. That behaviour is configurable and specific to the system’s setup. If you run Debian, Fedora, or another distribution, check the update documentation for that release rather than assuming Ubuntu’s configuration applies. See Ubuntu’s automatic updates guidance.
A reboot and a process exit are different events. Enabling a unit at boot tells systemd to start it when the host reaches the relevant boot target. A Restart= policy tells systemd what to do when the managed process exits under particular conditions. You generally need both for this use case.
Neither setting preserves the previous live session. Viewers may see an interruption during maintenance, and a service that starts again may still fail to publish. The input file must be available, the command must be valid, network access must work, and YouTube must accept the ingest connection.
If you are deciding where to run an always-on channel, the considerations in choosing streaming server hardware can help you assess the host. This guide focuses on supervising FFmpeg on a Linux server you already administer.
Capture the FFmpeg command that already works
Start with the exact command that currently produces a healthy stream. Record the executable, input path, looping or playlist options, codec and audio settings, output options, and YouTube ingest address. Do not change codecs or latency settings just because you are moving the command into systemd; first establish that the same command works in its current environment.
If you use a shell script, capture the script’s full path and check its permissions and working-directory assumptions. A command that works from your home directory may rely on a relative media path, a shell alias, or an environment variable that is absent when systemd launches it. Use absolute paths where practical and explicitly define any needed environment or working directory in the unit.
Treat the stream key as a secret. Do not paste it into a public example, screenshot, issue report, or article. Avoid putting it in a command line that could be exposed through process listings or logs. Store sensitive configuration with permissions restricted to the account and administrators who need it, and make sure the service can read it. Test that arrangement before relying on it after a reboot.
Use the current ingest details for your own stream rather than copying an example endpoint. YouTube’s LiveStreams reference describes the ingestion information associated with a live stream, including primary and, where available, backup addresses. Confirm which address and stream name belong in your chosen command and protocol.
If you are looping a file, confirm that the service account can read it and that it will remain at the same path. For a playlist, check every referenced file and any relative paths. A successful start does not prove that the media will continue to be available later, so include a simple file and permission check in your maintenance notes.
Create a systemd service unit
Create a service unit for the long-running FFmpeg process. The exact file location and user account depend on your distribution and administrative practice; a common administrator-managed unit is stored under /etc/systemd/system/. Choose a descriptive name, such as youtube-live.service, and use that name consistently in the commands that follow.
A simplified unit might look like this:
[Unit]
Description=YouTube live FFmpeg stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/home/streamer
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/media/channel.mp4 -c:v libx264 -c:a aac -f flv REPLACE_WITH_YOUR_INGEST_URL
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This is a structural example, not a ready-to-run command. Replace the user, paths, FFmpeg options, and output configuration with the values from your working setup. The example’s output placeholder is deliberately not a real YouTube address or stream key. Do not copy the example codecs or looping options unless they match your own command.
Use the path returned by command -v ffmpeg (or otherwise verify the executable path) rather than relying on an interactive shell’s PATH. Systemd does not necessarily run the same shell startup files as your login session. If you use a wrapper script, point ExecStart= at the script’s absolute path and ensure it is executable and has an appropriate interpreter line.
Keep ExecStart= as one command with explicit arguments. Systemd does not interpret it as a normal interactive shell command, so shell features such as pipes, redirects, and variable expansion do not behave as they would at a prompt. If you genuinely need shell logic, put it in a carefully reviewed script and have systemd run that script.
The Wants= and After= lines express a request for network-online handling and ordering, but they do not prove that a route to YouTube is usable at the instant FFmpeg starts. A DNS, routing, firewall, or remote service problem can still make the initial connection fail. The restart policy may cause another attempt, but you should verify the resulting behaviour rather than treating ordering as a network-health guarantee.
For a configuration that plays a prerecorded file around the clock, distinguish the media loop from service supervision: the FFmpeg options make the file repeat, while systemd manages the process lifecycle. The practical issues are related but not interchangeable; see how prerecorded video can run continuously on YouTube Live.
Set restart behaviour and delay
For a long-running service, Restart=on-failure is a reasonable starting point. It asks systemd to restart the process after qualifying unsuccessful exits, rather than restarting after every normal exit. Systemd documents restart policies and their effect in its service reference; see the systemd.service manual.
Set RestartSec= to a measured delay between a failure and the next attempt. The sample uses ten seconds, but that is an example value, not a universal recommendation. A short pause avoids an immediate retry loop; the right delay depends on your failure modes and how quickly you want to retry. Repeated failures still need investigation, not just a longer series of restarts.
Systemd applies start-rate limits. If the process fails repeatedly in a short period, systemd may stop scheduling further starts until the condition is addressed or the failure state is reset. That limit is a safeguard, not evidence that the stream settings are correct. Check the journal for the actual error before clearing a failed state or repeatedly restarting the unit.
An intentional systemctl stop is different from an unexpected crash. A manual stop is not normally reversed by the restart policy, which is useful when you need the broadcast to remain stopped for maintenance. Once you have intentionally stopped the service, start it explicitly when you are ready.
There is a trade-off in choosing the policy. Restart=always can bring back a process that exits normally, which may not be what you want if FFmpeg was meant to finish. on-failure is less likely to undo an intentional or normal completion, but it still cannot know whether YouTube has accepted the feed. Choose policy and delay for the process behaviour you actually intend.
Enable the service at boot
After saving the unit, tell systemd to reload its unit files, then enable and start the service. For the example name, the commands are:
sudo systemctl daemon-reload
sudo systemctl enable --now youtube-live.service
daemon-reload makes systemd read the changed unit definition. enable arranges for the service to start during boot; --now also starts it at once. Boot enablement is the part that addresses a host restart. The Restart= setting addresses eligible exits while the host is running. One does not substitute for the other.
Check the unit’s state after starting it:
sudo systemctl status youtube-live.service
Look for whether the service is active and whether FFmpeg remains running. A momentary active result is not enough to prove a healthy broadcast: FFmpeg can launch and then fail, or the ingest may not be accepted. Also check the live control room or stream status in YouTube and confirm that the expected video and audio are arriving.
If you need to change the command, edit the unit and run daemon-reload again before restarting the service. Keep a copy of the last known-good command and unit configuration in a private administrative record, with secrets excluded or protected. That makes rollback easier if a maintenance change introduces a syntax or path error.
For a channel that depends on a Linux machine and continuous power, the Raspberry Pi power considerations for 24/7 FFmpeg streaming in India address a different failure point. A battery or power arrangement will not replace boot enablement, but considering host power alongside service supervision can help you map the ways a stream can stop.
Test recovery after a reboot
Do not wait for an unattended update to be the first test. Arrange a maintenance window when a temporary stream interruption is acceptable, tell anyone who relies on the broadcast, and make sure you have access to the host console or another recovery route. A reboot stops the existing FFmpeg process, so there will be a gap even if the service starts successfully afterwards.
Before rebooting, confirm that the unit is enabled, that it starts normally, that the input file is readable by its configured user, and that the stream is healthy in YouTube. Then reboot the host using your normal administrative procedure. After it returns, check that the machine is reachable, inspect the service state, and verify the stream in YouTube rather than assuming that a running process means a working ingest.
A concise check sequence after the host is back is:
sudo systemctl is-enabled youtube-live.service
sudo systemctl status youtube-live.service
sudo journalctl -u youtube-live.service -b --no-pager
The -b journal filter limits the view to messages from the current boot. If the service is inactive, failed, or repeatedly restarting, the journal is the next diagnostic step. If it is active, confirm YouTube’s stream health and that the expected content is playing. A service can be active while a stream is stalled or otherwise unhealthy.
Test on the target distribution and host, since unit behaviour and update configuration can differ. Do not infer from a successful manual restart that an automatic reboot path has been tested. Record what you observed, including any gap, relevant errors, and the recovery steps, so a future update is less likely to become an unplanned experiment.
If you are troubleshooting frames or media transitions rather than boot recovery, the case of an OBS stream dropping frames when a playlist advances may help separate an encoder or playlist issue from a host restart.
Inspect the journal and diagnose persistent failures
Use journalctl to see what the service and FFmpeg reported. For example:
sudo journalctl -u youtube-live.service -b --no-pager
sudo journalctl -u youtube-live.service -b -n 100 --no-pager
The first command shows this boot’s service messages; the second narrows the output to a recent portion. You can also follow new messages while starting the service with sudo journalctl -fu youtube-live.service. Journal contents may expose paths, configuration, or other sensitive details, so review them before sharing screenshots or logs. Never publish a stream key.
Read the first useful error, not just the final restart notice. An ExecStart failure can mean the executable path is wrong, the unit syntax is invalid, or the configured user cannot access the program or media. An FFmpeg input error points you towards the file path, permissions, or media format. A connection error points towards the output URL, credentials, DNS, firewall, network route, or YouTube’s ingest endpoint. These are clues to investigate, not a diagnosis by themselves.
For RTMPS, YouTube describes RTMPS as RTMP carried over TLS. The connection needs the correct YouTube endpoint and application path, port 443, and the right hostname for TLS SNI. A mistyped hostname, port, or TLS configuration can result in connection errors or timeouts. YouTube calls RTMPS “a good choice for most ordinary user content, especially if it requires low latency,” but that does not mean switching to RTMPS will repair a broken command. Check the current YouTube RTMPS ingestion guide and confirm that your command uses the current details for your own stream.
Do not change ingest protocols as a guess. YouTube’s ingestion protocol comparison compares protocol characteristics, codecs, and latency trade-offs. A protocol choice should fit your codec and latency requirements. If you change it, update the relevant FFmpeg output settings and test the revised command deliberately.
When systemd reports that start requests were repeated too quickly or the unit hit its start limit, first find and fix the underlying failure. Then, if the unit remains marked failed, an administrator can clear that state with systemctl reset-failed youtube-live.service and start it again. Clearing state without fixing the error merely permits the same failure cycle to resume.
A service restart policy is a recovery mechanism for process exits, not a monitor that validates the ingest settings or the audience’s playback. If you need a simpler way to keep a file-based YouTube broadcast running without leaving your own computer on, StreamNeo removes the job of supervising this FFmpeg process on your Linux host; it does not make a faulty source file or YouTube configuration valid.
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 stream live through a server reboot?
No. A reboot ends the running FFmpeg process, so viewers can experience a gap. If the unit is enabled and the command can run, systemd can start the process after boot, but you still need to verify the ingest and stream status.
Is Restart=on-failure enough on its own?
No. It can ask systemd to restart FFmpeg after qualifying failures, but it does not enable the service to start on a host boot. Enable the unit separately, and use the journal to diagnose repeated failures or start-rate limits.
Why is the service active when YouTube does not show a healthy stream?
A running process is not proof that YouTube is receiving and accepting the broadcast. Check FFmpeg’s journal output, the current ingest address and stream name, credentials, network connectivity, and YouTube’s stream status.
Should I use RTMPS after an update?
An update by itself is not a reason to change protocols. Check YouTube’s current protocol guidance and your stream’s codec and latency needs; if you do change the output, test the command and verify the result rather than assuming the protocol change fixes an unrelated failure.