If you close an SSH session while FFmpeg is running in the foreground, the job may receive a hangup signal and stop. For a one-off job you want to inspect later, start it in a named tmux session, include -nostdin, detach from tmux, and then close SSH.
After reconnecting to the same Linode, attach to that session to see the terminal again. This protects the job from the SSH connection closing; it does not restart FFmpeg after a crash or reboot, or protect it from a full disk, a failed input, or other errors.
Why closing SSH can stop a foreground job
A foreground command belongs to the terminal session from which you started it. When that SSH connection closes, the shell and its terminal are no longer available. Depending on how the session ends and the process is attached, FFmpeg can receive a hangup signal or otherwise lose the conditions it expected. The practical lesson is simple: do not rely on leaving the SSH window open as your process manager.
A detached terminal multiplexer such as tmux keeps a terminal session on the Linode independently of your current SSH connection. You can disconnect, then return and attach to the same session. Linode Community guidance describes this detach-and-reattach pattern, including alternatives such as GNU Screen: Linode Community's discussion of processes after disconnecting.
There is an important boundary. tmux preserves the session through an SSH disconnect, not through a server reboot or a process failure. If the machine restarts, an ordinary detached terminal session is gone. If FFmpeg exits because its input disappeared, the output path failed, or the command encountered an error, tmux will still let you inspect the final output, but it will not relaunch FFmpeg automatically.
That distinction matters for an always-on YouTube channel. A one-time file conversion can reasonably be run in a tmux window and checked later. A broadcast that must start after a host reboot or be managed with explicit start, stop, and restart behaviour has a different lifecycle. For that case, see the separate guide to launching an FFmpeg YouTube stream automatically after reboot. Do not mistake persistence of a terminal for management of a service.
Check whether tmux is installed
Before planning the workflow, check whether the Linode already has tmux:
tmux -V
If the command prints a version, tmux is available. If the shell reports that the command cannot be found, you will need to install it using the package manager and instructions appropriate to the Linux distribution on that instance. Linux distributions differ, so do not copy a package command intended for another distribution without checking which one the server uses and its current package guidance.
You will need an account that can run the FFmpeg command and read the input and write the output. If FFmpeg itself is missing, install or compile it according to the distribution and the features your job needs; tmux does not provide FFmpeg. Likewise, check that your account can access the input file and output directory before starting a long encode. A path that works from your laptop is not automatically present on the remote server.
If you are new to command-line streaming, keep the job narrow while you test: first confirm that the input is readable, that the chosen FFmpeg build supports the selected codecs, and that the output can be created. A short test can reveal a typo or a permission issue before you leave a long process running unattended. Do not infer that a command has started correctly merely because the tmux session opened.
Start a named tmux session
Connect to the Linode over SSH and create a session with a name that makes sense for the task:
tmux new -s ffmpeg
The shell you see is now inside a tmux session named ffmpeg. Naming it is useful when you have other sessions or return later and need to identify the right task. The session name is local to that server; you must SSH back to the same Linode to attach to it.
Run your command from inside this session, rather than starting it in an ordinary SSH shell and attempting to move it afterwards. Tmux gives FFmpeg a terminal context that remains available when you detach. You can keep the normal FFmpeg output visible while connected, then return to it later.
For a simple test, you can run a command that reads a file and writes an output file. Replace the example paths and options with values appropriate to your actual task:
ffmpeg -nostdin -i /path/to/input -c:v libx264 -c:a aac /path/to/output.mp4
This is an illustration of where the options go, not a universal encoding recommendation. The input might have no audio, require a different codec, or already be in a form you should copy rather than re-encode. The output could be intended for local review rather than YouTube. Choose the command for the media and destination, and confirm the available codecs in the FFmpeg build on the machine.
Run FFmpeg with -nostdin
The -nostdin option tells FFmpeg not to check for terminal input. That is helpful when a job runs in the background of your attention: FFmpeg should not be waiting for keyboard input that you are not there to provide. The FFmpeg FAQ recommends -nostdin for background operation to prevent input checks.
Put the option in the FFmpeg invocation, as in the example above. It addresses FFmpeg's interaction with standard input; it does not detach a process from SSH on its own. That is why the workflow combines -nostdin with tmux. A second approach for noninteractive background work is to redirect standard input from /dev/null, but the tmux method is convenient when you want to come back to the same terminal and inspect what happened.
FFmpeg normally writes diagnostic output to standard error, which is why errors and progress messages appear in the terminal. While using tmux, leave that visible unless you have a reason to redirect it. The FFmpeg command-line documentation describes logging, report files and progress output. If you change the command to send progress records somewhere else, decide deliberately where that output should go; a redirect can hide useful diagnostics if it is not planned.
Do not add -nostdin as a substitute for checking whether the process is healthy. It does not validate the input, guarantee successful encoding, or make a network source reliable. It only prevents FFmpeg from checking terminal input, which is the relevant interaction to remove for this background use.
Detach before closing SSH
Once FFmpeg is running inside the named session, detach from tmux instead of closing the terminal that contains the active command. The default key sequence is Ctrl+B, followed by D: hold Control and press B, release, then press D. Tmux detaches and returns you to the ordinary SSH shell. The FFmpeg process remains in its tmux session.
You can now close SSH. If you want to be cautious, first confirm that the command is still visible in the tmux window and that it has not printed an immediate error. For an encode, you should see FFmpeg's output rather than a shell prompt. For a broadcast, check the logs and the relevant YouTube live status separately; a running process alone does not prove that viewers are receiving the intended picture and sound.
If you accidentally close the SSH connection without detaching, do not assume the job is still running. Reconnect and look for the session before starting another copy, because duplicate encodes or broadcasts may overwrite files or create competing outputs. The command below lists tmux sessions:
tmux ls
If the ffmpeg session is listed, attach to it. If no session is listed, the command may have finished, failed, or the session may have ended. Check the output file, logs, and any error messages you have before deciding what to run next.
Reconnect and attach to the session
SSH back into the same Linode account and attach to the named session:
tmux attach -t ffmpeg
The session should return to the terminal view where FFmpeg is running, or where its last output remains visible if it has already stopped. This is useful both for checking progress and for seeing an error without relying on a log you forgot to save elsewhere.
If tmux says there is no session by that name, list sessions with tmux ls and check the spelling. If there are no sessions, do not treat that as proof that the output is good or bad; inspect the destination file and any logs. A process that completed normally may leave a shell prompt in the session, while a failed process may have printed a diagnostic before exiting.
To leave again, use the same Ctrl+B, then D sequence. Detaching leaves the session in place. Typing exit in the shell inside the session is different: it closes that shell, and if no other panes or windows remain, the tmux session can end. Keep detach and exit distinct in your mental model.
Choose paths and encoding settings for the job
Use absolute paths on the Linode for both input and output where possible. For example, /home/streamer/media/source.mp4 is unambiguous, whereas source.mp4 depends on the current working directory. If the relative path is wrong, FFmpeg may fail immediately even though the file exists elsewhere. You can check a path before running the job with ordinary shell tools such as ls, and make sure the account running FFmpeg has the necessary permissions.
Also consider where the output will go. An encode can consume substantial disk space depending on duration, codec, bitrate and content. Check available space before starting, especially if the instance also stores other media. A full disk can interrupt an otherwise correctly detached process and can leave an incomplete output file. Tmux does not prevent storage exhaustion.
The sample command uses H.264 video and AAC audio, but it is not suitable for every input or output. The right choice depends on the source, whether you need to preserve quality or reduce file size, whether audio exists, and what the destination accepts. Some jobs can use stream copy rather than re-encoding; others need scaling, a different pixel format, or explicit bitrate choices. Test a representative short segment and verify the result before investing time in a full run.
For an always-on YouTube channel, session survival is only one part of the task. You still need to choose content and encoding settings for the intended stream, check YouTube's current requirements, and monitor whether the broadcast remains live. If a cloud host event interrupts the connection, a detached terminal cannot repair it; this guide on handling a YouTube stream disconnect after a cloud VM host migration covers a different failure mode. For repeated FFmpeg stream progress checks, the watchdog script guide is also a separate topic, not something tmux provides.
When a terminal session is not enough
Tmux is a good fit when the task is one-off, you want to see its terminal output again, and a human will check it. It is not a policy for what should happen after a reboot, and it is not a health monitor. If the job must start when the machine boots, or needs a managed start and stop mechanism, use a service manager such as systemd and define its behaviour deliberately. Linode's guide to starting a Linux service at boot explains the service approach.
There are other choices for simpler jobs. GNU Screen can preserve a terminal session in a similar way; its common detach and reattach controls differ from tmux. nohup can be useful for a noninteractive process when you do not need to return to its terminal, provided you redirect output to a known log and take care with standard input. The Linux nohup manual describes its handling of hangup signals and terminal input/output.
| Approach | Best fit | What you regain | Important limit |
|---|---|---|---|
tmux |
One-off work you want to inspect interactively | The terminal session and its visible output | Does not automatically restart FFmpeg after a crash or reboot |
| GNU Screen | Similar terminal persistence if it is the tool you already use | A detached terminal you can reattach to | Does not provide reboot recovery or process supervision |
nohup |
Noninteractive work where a log is enough | A process can ignore a hangup, with output redirected for later review | You do not reattach to the original terminal; manage and inspect the log |
systemd |
A job that needs service controls or startup after reboot | A defined service lifecycle and status/log inspection | Requires a suitable unit and deliberate restart policy; it is not a guarantee that the workload succeeds |
Choose based on the lifecycle, not on which command looks shortest. If you only need to leave a single encode running while you disconnect and later want to see its console, tmux is straightforward. If it must run unattended after a reboot, a service definition is the more appropriate layer. If it is a disposable command and a log is sufficient, nohup may be simpler. None of these removes the need to check the input, disk space, network sources, and FFmpeg errors.
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 tmux restart FFmpeg if it crashes?
No. Tmux keeps a terminal session available after you detach, but it does not automatically relaunch a process that exits. Check the terminal output and logs to find the cause, then decide whether a manual restart or service management is appropriate.
Will FFmpeg survive a Linode reboot in tmux?
No. A reboot ends the ordinary tmux session and the process in it. If the job needs to start at boot, configure a service such as systemd with a deliberate command, user, working directory, and restart policy, then test that setup.
Why use -nostdin if I am using tmux?
It tells FFmpeg not to check for terminal input during background operation. Tmux handles the session's separation from SSH; -nostdin handles FFmpeg's input checks. They solve related but different problems.
Can I use the example codec command as written?
Treat it as an illustration, not a recommendation for every source or destination. Confirm your input paths, available codecs, audio needs, output format, and quality or size requirements, then test a representative segment and inspect the result.