If SSH disconnects while FFmpeg is running on a remote Linux server, the stream may continue only if the process is not tied to the terminal session that ended. For an immediate fix, run FFmpeg inside a tmux session created on the server, then detach; for reboot recovery and restarting after a process exits, use systemd.
Neither tool proves that YouTube is receiving a healthy broadcast. Treat terminal and service status as clues about your server, then check the live preview and stream health in YouTube Studio.
Why an SSH drop can interrupt the stream
SSH gives you a remote terminal. If you start FFmpeg directly in that terminal, its input and output may be connected to the terminal session. When the connection ends, the shell or operating system can signal the process to stop. What happens depends on how it was launched and the server’s session handling, so a command that continued once is not a reliable unattended setup.
A mobile connection changing networks, a home router restarting, or a laptop sleeping can all end your SSH session without meaning that the server itself has failed. Conversely, keeping SSH open does not prevent FFmpeg from exiting or the connection to YouTube from breaking. The session, process and broadcast are separate things to check.
This distinction matters for an Indian music channel that is expected to run through the night. A devotional playlist might be playing locally on the server while YouTube has stopped receiving the encoder feed. You need a way to keep the process independent of your interactive terminal, a supervisor for process failures, and a separate check of YouTube’s side.
If your current stream uses FFmpeg, identify the exact command and the account that runs it before changing anything. A useful first step is understanding whether FFmpeg is copying compatible streams or re-encoding them; the trade-off is explained in copy mode versus re-encoding. Process management will not correct an unsuitable media file or encoding configuration.
Keep the immediate process in remote tmux
For an existing server and a one-off rescue, tmux lets you keep a terminal session on the remote host after SSH disconnects. The important detail is where you start tmux: SSH into the server first, and create the session there. Starting tmux on your laptop does not protect a command that runs in a remote shell outside that remote tmux session.
On the server, create a named session:
tmux new -s music-stream
Run your normal FFmpeg command inside that session. Naming it for its purpose makes it easier to identify later, especially if you have more than one stream or use the host for other work. Do not paste a stream key into a shared terminal recording or leave it visible in a screenshot.
When FFmpeg has started and you have checked that the command is behaving as expected, detach from tmux with Ctrl+b, followed by d. This leaves the tmux session on the server while returning you to the ordinary shell. You can then close SSH. The tmux session guide offers more context on running a YouTube loop from a Linux VPS.
Tmux is useful because it preserves the remote terminal and its foreground process across an ordinary SSH disconnection. It is not a service supervisor. If FFmpeg crashes, the server reboots, the input disappears, or the stream connection fails independently, tmux does not diagnose or repair that failure. It is a practical bridge, not a complete unattended operating plan.
Detach and reattach to the same server session
After reconnecting by SSH, use the same host and account that created the session. List sessions to see whether the named one is still present:
tmux list-sessions
If you see music-stream, reattach with:
tmux attach -t music-stream
You return to the terminal view and can inspect what FFmpeg printed. If the session is missing, first check the hostname and Linux user: sessions belong to the user and host that created them. Also consider whether the server was rebooted or an account policy ended the session. Starting a new session immediately can obscure the evidence about what happened to the original command.
A visible FFmpeg process or an attached tmux window is not the final health check. Look for recent output and errors, but do not assume that an old line saying the stream connected means it is still delivering. In YouTube Studio, check the current live preview and stream-health indicator. If the preview has frozen or Studio reports an issue, investigate the feed even when tmux remains intact.
For a short test or initial setup, this manual reconnect path is often enough. For a stream you expect to return after maintenance or recover when FFmpeg exits while nobody is watching the terminal, tmux alone leaves too much to remember. That is where a system service is more suitable.
Use systemd for reboot and process recovery
On a Linux server that uses systemd, a service unit can start FFmpeg at boot and ask systemd to restart it if the process exits. It can also provide a consistent place to inspect status and logs. This is more suitable than leaving an interactive terminal open for a channel intended to run without supervision.
A service should define, rather than assume, the user account, working directory, command, and environment it needs. The account must be able to read the media file and any configuration it uses. Store the stream key in a protected environment file with limited access, rather than putting it in shell history, a public repository, or a unit file that is broadly readable. Keep a copy of the unit and document how it is updated; a typo in a service definition can stop a stream just as readily as a typo in a command.
A unit commonly includes a restart policy and a short restart delay. The policy tells systemd what to do after an exit; the delay avoids an immediate, rapid retry loop. Enable the service for startup at boot, then start it and inspect its status. The exact unit differs with your Linux distribution, FFmpeg path, file location, and how the stream key is supplied, so adapt a tested pattern rather than copying one blindly. StreamNeo’s systemd service walkthrough is one reference for the unit structure and its limits.
Use systemctl status to check the unit and journalctl -u <service-name> to inspect its logs. A status of “active (running)” says that systemd sees a process running. It does not say that the input is being read correctly, that YouTube accepts the feed, or that viewers see moving video and hear audio. Confirm those separately in Studio.
Before relying on a service, test it in a planned maintenance window. Stop and start it using systemd, check that the expected command runs, and review the logs. If practical, arrange a reboot test when the channel can tolerate interruption, then confirm that the service starts and the YouTube broadcast is healthy again. Do not test a reboot unexpectedly during an important live period.
Make FFmpeg suitable for background use
A background process should not need keyboard input from an SSH terminal. FFmpeg documents -nostdin for disabling interaction with standard input in background operation; on Linux or macOS, redirecting standard input from /dev/null is another way to ensure the process is not waiting on your terminal. Put the option in the FFmpeg invocation, before the relevant input and output options, and verify the command still behaves as intended.
For example, the structural idea is:
ffmpeg -nostdin [your input and encoding options] [your YouTube output]
This is a pattern, not a complete command. The source file, audio and video codecs, output format and YouTube settings determine the options you need. FFmpeg’s official FAQ explains background operation and terminal-related suspension. Avoid copying an old bitrate or resolution from an unrelated guide as if it were universal; check YouTube’s current live encoder settings for the requirements that apply to your broadcast.
Set logging so that a later check can answer what happened. With a systemd service, standard output and error can be collected in the journal; keep enough recent output to see the first meaningful failure. With tmux, terminal output remains visible only while the session is available, so a service log is generally easier to review after an unattended interruption. Avoid logging secrets: command lines and environment details may be visible to other users with sufficient permissions.
If you stream a local loop file, verify its path and read permissions as the service user, not just as your personal SSH account. A command can work in your own shell and fail under systemd because the service uses another user or working directory. The same principle applies to hardware encoders and other inputs: check that the service account can access what FFmpeg needs.
Verify the broadcast in YouTube Studio
Check YouTube Studio after starting or restarting the encoder. Confirm that the live preview is moving, audio is present, and Studio reports a healthy incoming stream. If you have scheduled the broadcast, also confirm the correct event is active. A process can be running while sending no usable frames, sending the wrong input, or writing to a key that does not correspond to the expected broadcast.
Keep the checks distinct: tmux answers whether a remote terminal session exists; systemd answers whether its managed process is running or has exited; FFmpeg logs help explain its local work; Studio shows whether YouTube is receiving the broadcast as expected. None replaces the others. This is especially important after a restart, because the service may start successfully while the external stream still needs attention.
Where possible, have someone check the public watch page as well as Studio. A preview in your control room is useful, but viewers’ experience also depends on the published broadcast and their connection. Do not infer that a stream is healthy solely from a green-looking server terminal or a process listing.
For channels with several video segments, make sure the file or playlist itself is designed to continue as expected. Guidance on streaming multiple videos continuously can help separate a loop or playlist problem from an SSH or process problem.
Troubleshoot the remaining failure points
If the tmux session disappears, confirm you reconnected to the same machine and account. Then check whether the host restarted and whether FFmpeg exited before the session ended. If a systemd service is failing repeatedly, inspect the first relevant error in the journal rather than only the latest restart message. Repeated restarts are a symptom to investigate, not evidence that recovery is working.
Common causes include a wrong, revoked or mismatched stream key; an input path that no longer exists; file permissions; a missing encoder or unavailable device; incompatible output settings; and a network route problem. A corrected key or permission may restore operation, while a persistent network failure will simply cause another failed attempt. Fix the underlying condition, restart deliberately, then check Studio again.
A service cannot recover from every external event. It cannot make an inaccessible file readable, restore a failed internet connection, prevent loss of power, repair a bad encoding command, or force YouTube to continue a broadcast it has ended. A UPS may help a self-hosted machine through a brief power interruption, but it does not maintain the internet connection or guarantee YouTube recovery. Size one for the equipment and useful runtime you actually need.
If running the host itself is the burden, consider whether a managed option fits better than maintaining a Linux service. StreamNeo turns an uploaded video into a YouTube live stream that can continue with your own computer switched off, which removes the specific chore of keeping your personal machine on for the loop. It remains a YouTube-only commercial service, not a fix for every channel or a guarantee that a broadcast will be healthy; review its terms and verify the stream in Studio. For a locally hosted alternative, the trade-offs in keeping a computer on versus other options may help you decide.
For a self-managed stream, write down a small recovery procedure: check the Studio preview, inspect service status, read the first useful log error, correct the cause, restart the service, and verify Studio again. Keep the stream key private and record how to rotate it if it is exposed. A clear procedure is more useful overnight than a restart policy that silently repeats the same failure.
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 my FFmpeg stream stop if SSH disconnects?
It may, if FFmpeg was launched in a terminal session that ends with SSH. Running it inside a tmux session created on the remote server lets that terminal session survive an ordinary disconnect, but it does not protect against a server reboot, process crash or a failed YouTube connection.
Should I use tmux or systemd for a 24/7 stream?
Use tmux for a quick rescue or an interactive session you want to revisit. Use systemd when you need a process to start at boot, restart after an exit and leave logs to inspect; neither option confirms that viewers are receiving a healthy stream.
How do I restart FFmpeg automatically after it exits?
Run it as a systemd service with an appropriate restart policy and delay, and inspect the journal when it restarts. If the cause is a bad key, missing input or network failure, the process may keep failing until you fix that condition.
How can I tell whether viewers are receiving the stream?
Check the live preview and stream-health information in YouTube Studio after launch or recovery. An active tmux session, an FFmpeg process, or a systemd “active (running)” state describes your server-side process, not the viewer-side broadcast.