If SSH closes while FFmpeg is running on your Oracle Cloud instance, the stream can continue if the remote process remains alive. Run FFmpeg inside a tmux session on the instance, detach from that session before leaving, and reconnect later to inspect or reattach.
This protects against losing your terminal connection; it does not protect against a VM stopping, a process crashing, or the stream destination rejecting the connection. The steps below separate those cases and show when tmux is enough and when you need a service manager instead.
What happens when SSH closes
SSH gives you a remote shell: commands you start there run on the instance, but their relationship to the terminal matters. If you start FFmpeg in an ordinary interactive shell and the connection closes, the shell and its child process may receive a hangup or otherwise lose the terminal. Depending on how they were started and the system configuration, FFmpeg may stop. Do not assume an ordinary SSH window is a durable home for a stream.
A tmux session creates a terminal session on the remote instance that can remain after your SSH client disconnects. When FFmpeg runs inside that remote session, losing the local window does not by itself close the tmux session. The tmux manual describes sessions as persistent through accidental SSH disconnection and intentional detaching; see the tmux manual for its behaviour and key bindings.
There are two important qualifications. First, tmux must be running on the Oracle instance, under the user who starts FFmpeg. A tmux session running on your laptop that merely contains an SSH connection does not preserve the remote process after that connection ends. Second, persistence is not supervision: tmux will not recover FFmpeg if it exits, and it cannot keep a stopped or rebooting instance running.
Think of the layers separately. SSH is your connection to the remote shell; tmux holds a remote terminal session; FFmpeg reads media and sends a stream; the instance and its network must remain available. A failure in one layer does not prove the others are healthy. For example, you can reconnect to a tmux session and find that FFmpeg is still running but no longer reaching YouTube.
If you are preparing the FFmpeg command itself, first confirm the input, output URL and stream key format in a workflow such as streaming a podcast playlist with FFmpeg and a static image. This guide focuses on keeping the process available across SSH disconnection, not constructing or validating every possible command.
Install or confirm tmux on the instance
Connect to the Oracle Cloud Compute instance using the usual SSH command for your account and instance. Check that you are on the intended machine and logged in as the user who will own the stream process. Then check whether tmux is already available:
tmux -V
If the shell reports a version, tmux is installed and you can continue. If it reports that the command is not found, install the package using the package manager and repository configuration for the Linux distribution on your instance. Oracle Linux and other distributions can differ in package names and repository setup, so identify the operating system before copying an installation command from a guide for another image. You can inspect common release information with:
cat /etc/os-release
Use the distribution’s current documentation for package installation and any required repository enablement. Avoid running package commands as an unprivileged user if they require administrator rights; use the documented privilege method for your instance. You do not need to expose your stream key or change firewall settings simply to install tmux.
After installation, run tmux -V again. If you already have a process or service setup for FFmpeg, avoid launching a second copy just to test tmux. Two encoders using the same stream key can compete to publish, and a second process can make it harder to tell which output you are seeing.
Start a persistent tmux session
Start tmux from the SSH shell on the Oracle instance, giving the session a memorable name. For this walkthrough the name is ffmpeg-stream:
tmux new-session -s ffmpeg-stream
You should now be looking at a shell inside tmux. The name is a label for finding the session later, not a setting that keeps FFmpeg alive. Pick a name you will recognise if you use tmux for other tasks as well.
The location matters: run this command after logging in to the instance, not in a local terminal before SSH. You can check the host prompt or run a harmless identity check such as hostname before starting if you manage several machines. If you work across multiple Oracle instances, note which instance and Linux user own this session; tmux sessions are associated with a user on a particular machine.
Inside the tmux shell, you can run your normal FFmpeg command. Keep the command available in your notes or a script you control, rather than relying on a scrollback buffer as its only copy. Protect any file or command line that contains a stream key: a key is a credential, and logs, shell history, screenshots and shared support messages can expose it.
If FFmpeg is already running outside tmux, do not expect moving into tmux to adopt that process. Stop it deliberately if appropriate, then launch a single intended process from the tmux pane. Before changing a live channel, consider whether stopping and starting it will interrupt viewers or affect the current broadcast.
Run FFmpeg with -nostdin
Add -nostdin to the FFmpeg invocation when running it as a background task or in a session where you do not want FFmpeg reading console input. For example, the basic shape might be:
ffmpeg -nostdin -i INPUT -f flv OUTPUT_URL
Replace INPUT and OUTPUT_URL with the actual media source and destination syntax required by your setup. This is only a structural example: codec, rate control, video or audio mapping, looping, and output options depend on the source and the requirements of the live destination. Do not paste the placeholders literally.
FFmpeg’s FAQ recommends -nostdin to avoid input checks when running FFmpeg as a background task, and its command documentation explains that standard-input interaction is normally enabled unless standard input is itself used as an input. The flag prevents FFmpeg from expecting console input; it does not create persistence. tmux is what keeps the remote terminal session available after SSH disconnects.
With -nostdin, you should not depend on typing q into FFmpeg as a way to stop it. To stop it cleanly from an interactive setup, reattach to the tmux session and use the method appropriate to the running command. FFmpeg’s console controls and input configuration may differ, so check its output and command documentation. If you need a managed stop and start workflow, a service manager may be more suitable than an interactive pane.
As FFmpeg starts, read the output for errors rather than treating the presence of a tmux prompt as proof that streaming works. A malformed input path, expired stream key, unsupported codec or network issue can prevent a healthy broadcast even while tmux remains open. For YouTube-specific command or key issues, compare the symptoms with this guide to troubleshooting a YouTube stream key in FFmpeg; its Windows context differs, but the distinction between command errors and session persistence is useful.
Detach safely before closing SSH
When FFmpeg is running and its output looks as expected, detach from tmux rather than closing the SSH window first. Press Ctrl-b, release both keys, then press d. The keystrokes are a tmux command: they detach your terminal from the session while leaving that session running on the remote instance.
You should return to the ordinary SSH shell, and tmux will usually print a message indicating the session was detached. You can then close SSH. If the local network drops before you get a chance to detach, tmux is designed to preserve its session through an accidental disconnection, but reconnect and inspect it rather than assuming the stream stayed healthy.
A common mistake is pressing Ctrl-c in the FFmpeg pane or exiting the shell inside tmux. Those actions can stop FFmpeg or close the shell that hosts it. Detach with the tmux key sequence; do not use the shell’s exit command as a substitute. If a key sequence appears not to work, check that you are in a tmux pane and that its prefix has not been customised.
For a 24/7 channel, decide when and how you will check the stream from YouTube or another appropriate monitoring view. A detached session gives you a way back to the terminal, not an alert when the encoder stops. The difference matters for a devotional loop, local news slate or lofi stream: a pane can remain open with an error on screen while viewers receive no usable programme.
Reconnect and inspect with tmux ls
After a later SSH login to the same instance, as the same Linux user, list the available sessions:
tmux ls
If ffmpeg-stream appears, reattach with:
tmux attach-session -t ffmpeg-stream
Inspect the pane. Check whether FFmpeg is still printing progress, whether it has exited, and whether any error message explains a failure. A live tmux session only demonstrates that a terminal session exists. It is not confirmation that YouTube is receiving a healthy stream, so verify the destination separately using the relevant official YouTube live control or monitoring interface.
If tmux ls reports no server or no sessions, check the basics before starting a new encoder. Confirm that you reconnected to the same Oracle instance and the same user that started tmux. A different user has a different tmux server context, and another instance has its own sessions. Also confirm that tmux was started remotely and that the instance has not rebooted or been replaced.
If the session is listed but FFmpeg is absent, look at the pane and determine whether the command exited or the shell is still open. If the session is not listed, do not infer that the stream is still running elsewhere. Check the instance state and, if appropriate, inspect processes and system logs using your normal administrative procedures. Verify the output URL, credentials and route to the destination independently before restarting. A failed process may need a deliberate new launch, but restarting blindly can create duplicate publishers or conceal the underlying fault.
For production use, keep a short operator note with the instance identity, Linux user, session name, command location and safe stop procedure. Do not include a plain-text stream key in a shared runbook. This makes a reconnect less dependent on remembering which terminal was open overnight.
Know when tmux is not enough
tmux is a good fit when you want an interactive terminal you can detach from and later inspect. If you are comfortable managing the process manually and the main risk is losing SSH, the workflow is direct. It is not a process supervisor: an FFmpeg crash, out-of-memory termination, source failure or instance shutdown is outside what a detached tmux session can fix.
For a repeatable unattended stream, a systemd service may be a better fit because it provides service state and configurable restart behaviour. Oracle’s Oracle Linux systemd documentation covers service units, ExecStart and Restart. The restart policy must be chosen deliberately: what happens depends on the exit reason, and a clean administrative stop is not necessarily treated as a failure to restart. A service that starts FFmpeg again still cannot guarantee that the destination accepts the reconnection or that a continuous broadcast resumes without interruption.
Do not paste a generic unit file for an unknown command. The correct unit needs the actual FFmpeg binary path, arguments, environment, working directory, permissions and credential handling for your instance. Test its start, stop, status and log behaviour before relying on it for an unattended channel. If you need to see a live terminal and type into the process, tmux remains the more natural tool; if you need explicit service state and a configured restart policy, investigate systemd.
nohup is another possibility for a simple background job when terminal reattachment is not needed. GNU’s nohup documentation explains hangup handling and input and output behaviour. Redirect output to a known writable log and keep track of the process, but remember that nohup does not offer tmux-style reattachment or a configured service restart policy.
| Approach | Reattach to the live terminal? | Restart behaviour | Best fit |
|---|---|---|---|
| tmux | Yes | No automatic process recovery | Interactive work where SSH loss is the concern |
| systemd | No pane in the tmux sense; inspect service state and logs | Configurable, according to the unit and exit conditions | Repeatable service management |
| nohup | No | No configured service policy by itself | A simple detached job with a log |
Choose based on the failure you need to handle. If only the SSH window may disappear, tmux addresses that session problem. If FFmpeg must be restarted after a process failure, design and test a service policy. If the instance itself is unavailable, neither a detached tmux session nor a command’s hangup handling replaces instance recovery planning.
Oracle Cloud Infrastructure Streaming is a separate managed service for ingesting and consuming event data, not a way to preserve an FFmpeg process on a Compute instance after SSH logout. Oracle describes that product in its OCI Streaming FAQ. For a YouTube channel, the relevant question here is whether your remote FFmpeg process and its path to the live destination remain healthy.
A different operational choice is to avoid maintaining a remote FFmpeg process yourself when your source is a prepared video file. StreamNeo can remove the work of keeping that FFmpeg terminal and SSH session alive by turning an uploaded video into a YouTube live stream; it is not a way to manage an Oracle instance or a general FFmpeg service. For a broader production workflow, see how to make a 24/7 Tamil music YouTube stream with a song-request playlist.
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 keep FFmpeg running if I close my SSH window?
It can, provided FFmpeg was started inside a tmux session on the remote instance and the session and process remain alive. Detach with Ctrl-b, then d, before closing SSH when possible. After an unexpected disconnect, reconnect and inspect rather than assuming the stream is healthy.
Does tmux restart FFmpeg if it crashes?
No. tmux preserves a terminal session through detachment or SSH disconnection; it does not supervise FFmpeg or restart it after a crash. For configured restart behaviour, look at a properly designed service such as systemd, and test what it does for the exit conditions you expect.
What should I check if tmux ls cannot find the session?
Make sure you are on the same instance and logged in as the same Linux user that started the session. Also consider whether the instance rebooted, tmux was started locally rather than remotely, or the session ended. Do not launch another FFmpeg process until you have checked whether an existing stream is still publishing.
Is -nostdin what keeps the session alive?
No. -nostdin disables FFmpeg’s standard-input interaction; tmux provides the session persistence across SSH disconnection. Both can be useful in this workflow, but neither protects against instance failure, a broken media source or a failed connection to the stream destination.