If you start FFmpeg in an ordinary SSH terminal, closing that connection can send a hangup signal and stop the process. Run it inside a persistent terminal session such as tmux, detach from that session before leaving, and you can reconnect later to inspect the same FFmpeg output.
That protects the process from an SSH disconnect, not from every failure. The remote host must remain on, FFmpeg must keep running, and the connection to YouTube must remain healthy; tmux does not restart FFmpeg after a reboot or recover a failed stream.
Why an SSH disconnect can interrupt a stream
An SSH terminal is a connection to a shell running on another computer. If you launch FFmpeg directly in that shell, the process is tied to the terminal session. When the connection closes, the shell or operating system may send a hangup signal to processes associated with it. FFmpeg can then exit, and the live broadcast stops.
A persistent terminal multiplexer separates the process from your SSH client. The tmux session continues on the remote host after you detach or lose the connection. The tmux manual describes its sessions as persistent through accidental disconnection, including an SSH timeout. That makes tmux a practical default when you want to leave a stream running and later return to see what FFmpeg reported.
This boundary matters: a detached session is not a health check. A host reboot, a deliberate process stop, an FFmpeg error, an expired or incorrect stream key, or a failed route to YouTube can still interrupt the broadcast. For a broader look at remote-machine trade-offs, see how a cloud desktop can run a 24/7 YouTube stream.
Start a named tmux session
Connect to the remote host over SSH, then create a session with a name you will recognise:
tmux new -s yt
Here, yt is just a label. You could choose a channel name or another short identifier, but avoid putting a stream key, password, or other secret in the session name. Once the command runs, you are inside a tmux session and can use its terminal as usual.
If the shell replies that tmux is not installed, use the package manager for your operating system or ask whoever manages the host to install it. Installation commands differ between operating systems and distributions, so there is no single command that is appropriate for every remote host. GNU Screen is another option if it is available and is covered below.
Before starting the stream, make sure you are on the intended host and YouTube channel. You will need the stream URL and key from YouTube’s Live Control Room, entered into your prepared encoder command. YouTube calls stream keys the password and address for a stream: do not paste an actual key into a public article, shared terminal transcript, or broadly accessible log. If a key is exposed, reset it in Live Control Room and update the encoder. See YouTube’s guidance on creating and managing live streams.
Run the prepared FFmpeg command
Inside the tmux window, run the FFmpeg command you have already prepared and checked for your input, chosen encoding settings, and YouTube ingest details. This article does not provide a universal command: the right input and encoding options depend on your source and output, and no specific example has been validated here. If you need to troubleshoot an audio problem, use the steps in this FFmpeg guide for YouTube streams with no audio.
Wait for FFmpeg to begin reporting output rather than immediately detaching. Check that it has accepted the input and is sending data, and look for an error that indicates it exited or cannot reach the ingest endpoint. A running terminal command is useful evidence that the process started, but it is not proof that viewers can watch the stream.
YouTube’s current encoder guidance covers settings such as RTMPS where available, constant bitrate, and keyframe intervals. Choose settings for your resolution and frame rate using the official YouTube live encoder settings, rather than copying values meant for a different stream. In Live Control Room, check the preview and stream-health messages as well. Test with representative audio and movement before relying on a long broadcast; a still devotional image with music, for example, should be tested with the actual audio and visual pattern you intend to send.
Detach without stopping FFmpeg
When FFmpeg is running inside tmux, detach from the session with the tmux prefix followed by the detach key: press Ctrl-B, release the keys, then press D. You should return to the ordinary shell, while FFmpeg continues in the detached session on the remote host. You can now close SSH without closing the tmux session deliberately.
If the keystrokes appear to do nothing, check that your terminal is still connected to the tmux session and try the sequence again. The prefix is a control sequence, not a command to type into the shell. Do not press the terminal’s close button as a substitute for detach if you can avoid it; detach explicitly first, then disconnect.
After detaching, keep the remote host running. If the host itself shuts down or reboots, the tmux session disappears along with its running processes. Also avoid using kill, exit, or a command that stops FFmpeg until you are ready to end the broadcast. The session protects against losing the SSH terminal; it does not make FFmpeg immune to operator actions or host conditions.
Reconnect and inspect the session
Reconnect to the same remote host through SSH. List the tmux sessions with:
tmux ls
If the named session is listed, return to it with:
tmux attach -t yt
You should see the terminal state and recent FFmpeg output. If the session is present but FFmpeg has exited, tmux cannot bring the process back merely by attaching. Read the last visible messages, determine why it stopped, and only restart the prepared command once you understand whether YouTube still has an active broadcast and whether the input and credentials are valid. Do not start a second encoder blindly against the same live setup.
If there is no session in the list, check that you have connected to the right host and user. A reboot, session termination, or use of a different account can explain why the session is missing. Reattaching is for inspection and control; it is not a remote recovery mechanism for a process or machine that no longer exists.
For a 24/7 playlist, terminal state is only one part of the job. FFmpeg may be running while the incoming picture or audio is wrong, or while YouTube reports a health issue. Use the YouTube live stream setup and health guidance to check the broadcast itself, and keep an eye on the Live Control Room rather than treating a detached terminal as proof of a good stream.
Choose tmux, Screen, or nohup
Tmux is a good default when you want to detach and later reattach to inspect FFmpeg output. GNU Screen offers a similar terminal-session workflow. Start a named Screen session with screen -S yt, run FFmpeg in it, then detach with Ctrl-A, followed by D. After reconnecting, resume with screen -r yt.
Screen’s manual explains that programs in its windows continue independently of the user’s terminal when the Screen session is detached. Its controls differ from tmux, so follow the correct prefix for the tool you started. Do not try to attach a tmux command to a Screen session, or the reverse. The GNU Screen manual documents session behaviour and detaching.
If you do not need to reattach and inspect a terminal, nohup can run a command with hangup signals ignored. GNU Coreutils documents it for this purpose. A typical shell pattern is:
nohup ffmpeg [options] -i [input] [output] >ffmpeg.log 2>&1 < /dev/null &
Replace every placeholder with parts of a valid command for your stream. This pattern has not been validated for a particular input, codec, or YouTube URL. It sends standard output and errors to ffmpeg.log, disconnects standard input from the terminal, and backgrounds the process. See the GNU Coreutils nohup documentation. Unlike tmux or Screen, nohup does not give you the same interactive terminal to reattach to; you inspect the named log instead. Protect that log from broad access, particularly if your command includes a secret.
| Approach | Reattach to inspect terminal output | What it addresses | What it does not address |
|---|---|---|---|
| tmux | Yes, with tmux attach -t yt |
SSH terminal disconnects | Reboot, process failure, or stream health |
| GNU Screen | Yes, with screen -r yt |
SSH terminal disconnects | Reboot, process failure, or stream health |
nohup with redirection |
No interactive reattachment; inspect the log | Hangup from logout or terminal close | Reboot, process failure, or stream health |
| Service manager | Depends on configuration and tools | Can be configured for managed starts or recovery | Not a substitute for checking the live broadcast |
Pick the method based on what you need to do after disconnecting. If you expect to inspect FFmpeg or intervene, use tmux or Screen. If you only need a detached process and have a suitable way to review output, nohup may be enough. In each case, the host and FFmpeg still have to be working.
When a service manager is more appropriate
A terminal multiplexer keeps a process attached to a persistent terminal session. It is not a system service and does not itself arrange to start FFmpeg after a host reboot or restart it after a process failure. If your requirement is that a stream process should be started again after one of those events, investigate a service manager such as systemd, with configuration suited to your operating system and command.
That is a different operating model. A service manager can be configured to manage a process, but the exact restart policy, environment, permissions, secret handling, and logging need to be set deliberately. A guessed unit file can behave differently from what you intend, and an automatic process restart still does not guarantee the YouTube stream is healthy. This guide does not provide a tested systemd configuration, so have an administrator validate one for the host rather than pasting an unverified unit into production.
For a small channel where you mainly need to survive an SSH timeout and check output occasionally, tmux may be simpler to operate. For a stream that must resume after planned maintenance or host reboot, a properly configured supervisor is more relevant, alongside a plan for YouTube’s ingest and stream-health checks. If you are deciding whether the source itself should be a file loop or another setup, this guide to continuous pre-recorded YouTube streams addresses that separate choice.
For a long-running channel where losing the local computer or SSH session is the recurring operational burden, StreamNeo removes the need to keep your own computer running for the broadcast: upload the video, provide the YouTube stream key, and the stream runs without relying on your SSH terminal. You still need to check YouTube’s current requirements and monitor the live stream; no terminal session or streaming setup guarantees that the broadcast remains healthy.
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 keep FFmpeg running after SSH disconnects?
Start the prepared FFmpeg command inside a named tmux session, such as tmux new -s yt, then detach with Ctrl-B, followed by D. The SSH client can disconnect while the tmux session remains on the remote host, provided the host and process remain alive.
How do I keep a process running after closing SSH?
Use a persistent terminal session such as tmux or Screen if you want to reconnect and inspect it. nohup with deliberate input and output redirection is another option for a detached process, but it does not provide the same interactive reattachment.
Will tmux keep my stream running if I disconnect?
It can keep the FFmpeg process from being stopped solely because the SSH terminal disconnected. It cannot guarantee the stream is healthy, prevent a host reboot, or recover FFmpeg after a process failure.
How do I reconnect to my FFmpeg session?
SSH into the same host and user, run tmux ls, then attach with tmux attach -t yt if the session is listed. If FFmpeg exited, inspect its output and diagnose the cause; attaching to the session does not restart it.