systemd can restart an FFmpeg process after it exits or fails, which helps an Ubuntu host recover from some interruptions without someone logging in to relaunch it. It cannot, by itself, tell you that viewers are receiving a healthy picture and sound.
The useful setup is therefore two-part: supervise FFmpeg as a foreground process, and separately choose how to handle failures that FFmpeg or systemd cannot observe. The right command depends on your source and destination; “kids’ livestream” describes the audience, not the ingest protocol or the content format.
What systemd can and cannot recover
A systemd service keeps track of a process it starts. If FFmpeg exits with an error, is terminated abnormally, or reaches an applicable timeout, a restart policy can ask systemd to launch it again. For a long-running service, the Ubuntu Jammy systemd.service manual calls Restart=on-failure the recommended choice for attempting recovery from errors.
That is process recovery, not stream verification. If FFmpeg stays alive but stops receiving useful frames, or continues running while the destination rejects its output, systemd may see no process failure to act on. A service marked active is not proof that a viewer can watch the stream.
There are several distinct failure points: your media or camera, the network path between the source and host, FFmpeg’s input connection, the publishing connection, and the receiving platform. A setting that addresses one point does not necessarily repair the others. For example, systemd can restart FFmpeg after it exits, but it does not understand every protocol’s reconnect behaviour.
| Recovery choice | What it may address | Important limitation |
|---|---|---|
| FFmpeg protocol reconnect | Certain connection failures for a supported protocol, when the relevant options are configured | Options and behaviour vary by protocol and build; it may not detect a publishing failure |
systemd Restart=on-failure |
An observed process failure or applicable timeout | It may not act when FFmpeg remains alive but the stream is stalled |
| Startup network ordering | Waiting for the network manager’s configured online condition during service startup | It does not monitor connectivity continuously |
| Health-check design | A specifically defined live-but-unhealthy condition | You must choose a meaningful signal and decide what action follows |
Use the mechanism that matches the failure you are trying to address. Avoid treating a systemd restart policy as a general “reconnect the livestream” switch.
Prepare the Ubuntu host and media
Start by checking what is installed rather than copying flags from a guide written for a different release. Run ffmpeg -version and systemd --version, and consult local FFmpeg help or documentation for the input and output protocols you actually use. The online FFmpeg command-line documentation is regenerated for the newest revision, while the Ubuntu Jammy service manual cited above documents its own systemd series. Differences between installed versions can matter.
Decide what will feed the stream. A local file, network URL, capture device and RTSP camera are different inputs. Likewise, the receiving platform’s current ingest instructions determine the required endpoint, stream key, codecs and settings. Check those instructions before building a command; do not infer the destination or encoding requirements from the fact that the channel is for children.
For a file that should repeat, FFmpeg documents -stream_loop -1 for infinite looping. It is an input option, so its position in the command matters, and it does not reconnect a live camera or repair a dropped publishing connection. A file loop also cannot compensate for an unavailable host or destination.
Check that the service account can read the media and any required configuration, and that the executable path is correct. A unit running as streamer will not automatically inherit your interactive shell’s permissions, mounted folders, environment variables or current directory. Test access with the account and paths you plan to use before relying on unattended operation.
Keep stream keys and source credentials out of published examples, shell history and broadly readable files. A stream key is a publishing secret: someone who obtains it may be able to publish to the channel. Use a restricted service account and choose a credential-handling approach appropriate to your host. Do not copy generic sandbox or hardening directives without checking that they still permit FFmpeg to access the files, devices and network it needs.
If you are deciding whether the workload belongs on a small Ubuntu host, the AWS Lightsail 24/7 FFmpeg stream discussion is relevant to that separate hosting decision. It does not change what systemd can detect once FFmpeg is running.
Build a command for the actual input and output
Keep the command simple enough to inspect. FFmpeg reads an input, processes it and writes an output; many command-line options apply to the next input or output, so order is significant. Put input-specific options before the corresponding -i, and output-specific options where they apply to the output. The FFmpeg CLI reference explains this ordering model.
A deliberately schematic pattern is:
/usr/bin/ffmpeg [INPUT_OPTIONS] -i [INPUT] [PROCESSING_OPTIONS] [OUTPUT_OPTIONS] [OUTPUT]
Every square-bracket placeholder must be replaced with a value suitable for your source and destination. The pattern is not a ready-to-run command: it leaves out codecs, resolution, audio handling, ingest URL and credentials because those depend on the actual stream. Do not put a real key into a public script or example. Confirm the destination’s current ingest requirements before choosing output options.
If the input is HTTP, FFmpeg’s HTTP protocol documentation describes reconnect-related options, including reconnecting on disconnect or network errors and limits for retries and delays. Those are HTTP-specific controls, not universal flags. Do not add them to an RTSP, device or other input merely because the word “reconnect” appears in an example. Consult the FFmpeg protocol documentation for the protocol you are using and verify option support in your installed build.
For an RTSP source, FFmpeg documents transport choices including UDP, TCP interleaving and HTTP or HTTPS tunnelling. Which one is suitable depends on the camera, firewall and network path. Choose based on compatibility with the actual source and test it; there is no single transport choice that can be assumed to work everywhere.
A protocol reconnect can help when a connection failure is one the protocol implementation recognises and the configured retry behaviour covers it. It does not guarantee that FFmpeg will notice every problem farther downstream. If a command returns an error and exits, systemd can then respond according to its policy. If FFmpeg remains running without useful output, a restart policy alone may have nothing to respond to.
For more on one common publishing symptom, see the guide to unsupported audio over RTMP and FFmpeg. Treat it as an output-format troubleshooting topic, not as a substitute for checking whether the process is still alive and whether viewers can see the result.
Write a systemd service unit
Create a service file such as /etc/systemd/system/ffmpeg-livestream.service. The following is a template, not a tested configuration. Replace the placeholders and adapt the command to your source, destination, installed FFmpeg version, file permissions and credential handling.
# /etc/systemd/system/ffmpeg-livestream.service
[Unit]
Description=FFmpeg livestream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
ExecStart=/usr/bin/ffmpeg [options appropriate to this source and destination] -i [INPUT] [OUTPUT_OPTIONS] [OUTPUT]
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
Type=simple keeps FFmpeg in the foreground as the service’s main process, where systemd can observe its exit status. Do not wrap the command in a script that backgrounds FFmpeg and exits immediately; systemd would then track the wrapper rather than the actual encoder. If a wrapper is genuinely needed for setup, it must remain in the foreground and handle child-process signals and exit status deliberately.
Restart=on-failure asks systemd to restart after an observed failure. RestartSec=5s is an illustrative delay, not a value validated for every workload. Choose a pause that fits the source and destination, and avoid a rapid launch loop when a persistent configuration error makes every start fail.
Repeated attempts are also subject to systemd start-rate limiting, configured through settings such as StartLimitIntervalSec= and StartLimitBurst=. If launches exceed the applicable limit, automatic attempts can stop until the limit permits another start or an administrator intervenes. Check the local service manual for the defaults and placement relevant to your installed version rather than assuming retries will continue indefinitely.
The Wants= and After= lines express startup ordering against network-online.target. The systemd documentation on network-online explains that this target reflects the network manager’s readiness definition. It does not promise that connectivity will remain available after startup, so later network failures need protocol reconnect behaviour, a process exit that systemd can observe, or a separately designed health check.
Enable and start the service
Once the unit file and command are ready, ask systemd to reload unit definitions, then enable and start the service:
sudo systemctl daemon-reload
sudo systemctl enable --now ffmpeg-livestream.service
enable makes the service eligible to start at boot; --now also starts it immediately. These commands do not validate that the output reaches the platform or that viewers can see it. Before relying on unattended operation, confirm the executable path, media path, account permissions and credential access on this host. Check the unit and command for syntax and option-order mistakes.
If the service does not start, do not repeatedly retry without reading the failure reason. A wrong path, inaccessible file, unsupported option, missing device permission or invalid destination can produce the same broad outcome—a process that exits—while requiring different fixes. A start-rate limit may eventually suppress further automatic starts, so diagnose the first useful error rather than treating repeated launches as progress.
The service account should have only the access it needs, but that access must include the relevant media and any capture device or network endpoint. A restrictive setting that blocks FFmpeg’s necessary access is not useful hardening. Validate changes on the specific host and keep any secret-bearing configuration readable only by the intended account and administrators.
If the source is a finite video, distinguish looping the content from keeping the process alive. A loop can replay the file while FFmpeg runs; it does not recreate a missing file or restore a failed publishing connection. For a broader discussion of restart behaviour on another setup, the Raspberry Pi guide to restarting a YouTube live stream after reboot may help you think through boot-time service behaviour, but its platform and host details are not a substitute for checking this Ubuntu unit.
Inspect service status and logs
Use systemctl status ffmpeg-livestream.service to see whether systemd considers the service active and to inspect recent service messages. An active status means the tracked process is running according to systemd’s view; it does not confirm that frames or audio are reaching viewers.
For a live view of recent journal entries, run:
journalctl -u ffmpeg-livestream.service -f
FFmpeg’s messages can help distinguish an input read error, output connection failure, permission problem or codec issue. Review what the process reports alongside systemd’s state. A journal line showing a process start is not evidence of a successful broadcast, and a quiet log is not by itself a health signal.
When troubleshooting, note whether FFmpeg exited, was restarted, or remained active throughout. If it exited, the exit status and nearby messages can guide you towards a command, permissions or endpoint problem. If it remained active while the viewer-facing stream froze, focus on whether the input is producing frames, whether FFmpeg’s output is progressing, and whether the receiving platform is accepting it. Those are different questions from whether systemd is supervising the process.
Do not treat repeated restarts as a fix when each run fails for the same reason. Correct the underlying error, then start the service deliberately and observe both the host-side process and the destination-side result. Protect logs and unit files if they can reveal source locations or credentials; avoid placing secrets directly in a command line that may be visible to other local users or captured in logs.
Test recovery and viewer health
Plan a controlled recovery check before leaving the channel unattended. The important distinction is between asking systemd to recover from a process failure and verifying an end-to-end broadcast. A suitable process-level check is to establish what happens when the tracked FFmpeg process exits, then inspect whether systemd attempts a restart and whether its rate limits permit it. Do this only when interrupting the broadcast is acceptable, and do not infer viewer health from the restart alone.
For viewer health, inspect the receiving platform’s live status and view the stream from a separate device or connection. Check that the picture changes as expected and that audio is present where intended. A local process can be active while the source is frozen, the output is rejected or viewers cannot reach the broadcast. The exact signals available depend on your platform and workflow, so use its current official guidance rather than assuming one generic health check applies.
A stronger automated design needs a defined unhealthy condition and a response. For example, you might monitor whether useful frames continue to arrive or whether a destination-side signal shows publishing has stopped. The check must distinguish a genuine failure from a quiet but valid scene, and its action must be safe to repeat. A watchdog or external health monitor can itself fail or misread the situation; it is not a guarantee of continuous uptime.
For a children’s channel, operational continuity and editorial oversight are separate concerns. Confirm that the content, audio, moderation and destination settings are appropriate for your audience and platform. The title alone does not establish the source material, platform policy obligations or jurisdiction, so consult the receiving platform’s current official information and your own applicable requirements.
Power resilience is also separate from software recovery. A suitably sized UPS may help during some power interruptions, but it cannot prevent a source failure, network outage, FFmpeg error or platform-side problem. Whether it provides useful time depends on the measured load and battery condition; do not assume it makes a stream continuous.
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 reconnect my stream after an internet outage?
Not necessarily. It can restart FFmpeg when the process exits or fails in a way systemd recognises, but it does not restore network connectivity itself. FFmpeg reconnect options are protocol-specific, and neither a restart nor a reconnect proves that viewers are receiving the stream.
Should I use FFmpeg reconnect options or Restart=on-failure?
They address different situations. FFmpeg’s reconnect behaviour applies to supported protocol failures and configured retry limits; systemd responds to observed process failures. Use the relevant protocol documentation for the input or output in question, and account for systemd’s start-rate limiting.
Does network-online.target keep the network connected?
No. It can order startup around the network manager’s configured online condition, but it does not continuously monitor or restore connectivity. You need a separate strategy for failures that happen after the service starts.
If systemd says the service is active, is the YouTube stream healthy?
Not by itself. “Active” describes the process systemd tracks, not whether useful frames reach the destination or viewers can watch them. Check logs and the receiving platform, then verify the broadcast from a separate viewer connection.