If your SSH connection to an Amazon EC2 Linux instance ends, an encoder running in the ordinary foreground may end with the terminal session. Start it inside GNU screen instead: the command stays in a terminal session you can detach from and reattach to later.
That is session persistence, not automatic process supervision. Screen does not restart an encoder that crashes or bring it back after an instance reboot, so you still need to check the encoder and YouTube stream health.
What an SSH disconnect does—and does not—mean
SSH gives you a remote terminal on the EC2 instance. When you start a command in that terminal, its relationship to the terminal matters. A foreground command started in a regular SSH shell is not the same as a command running inside a persistent terminal session. If the network drops or the SSH client closes, you may lose the terminal and the foreground process may be interrupted along with it.
GNU screen provides a terminal session that remains available on the instance after your SSH client disconnects. You can later connect as the same Linux user and return to that session. AWS documents screen for continuing a long-running command through an interrupted network connection and reconnecting to it afterwards. This makes it useful for an encoder that must keep running while you close your laptop or your connection changes.
The distinction is easy to miss: screen preserves the session, but it does not supervise the application. If the encoder exits, screen can leave you with a session in which the command has ended; it will not relaunch that command. Nor does screen by itself arrange for a session to start again after a host reboot. Treat it as protection against a particular interruption—SSH going away—not as a guarantee that a 24/7 broadcast will never stop.
If you are investigating a stream that has already stopped, first separate the symptom from its possible causes. Was only the SSH window closed, or did the instance reboot? Is the encoder still present? Does it report an input, authentication or network error? This guide focuses on keeping the command independent of SSH and on reconnecting to inspect it. For other continuity problems, the article on keeping an Indian music stream running after power loss addresses a different failure point; screen alone does not solve power loss or reboot recovery.
Start a GNU screen session
Connect to the EC2 instance using your normal SSH method and the Linux account that will run the encoder. On the host, confirm that the encoder is installed, that its input file or other source is available to that account, and that you know where its output and logs will go. The exact installation command depends on the Linux distribution and package source, so do not assume a command written for one EC2 image applies to another.
Start screen before launching the encoder. A common interaction is to type screen in the shell. Depending on the image, GNU screen may need to be installed first, and the package name or installation steps vary. If the command is not found, check the operating system's package instructions or your administrator's guidance rather than pasting an unverified install command into a production host.
Once screen opens, you are working in a shell inside its session. Run a simple, non-production command first if you are unfamiliar with the interaction, then confirm you can detach and reconnect before relying on it for a scheduled broadcast. This small rehearsal helps distinguish mistakes in screen navigation from a problem with the encoder itself.
Screen sessions belong to the user who created them. If you open a second SSH connection as a different Linux account, that account's session listing will not ordinarily show the first user's session. Return using the same account, or deliberately use the appropriate administrative procedure if account access has changed. Avoid running the encoder under an unexpected account: file permissions, environment variables and access to media may differ.
Run the encoder inside it
With the screen session open, start the encoder from the shell inside that session. Use the command and arguments appropriate to your encoder, media and operating system; there is no universal EC2 command line for all YouTube broadcasts. Check that the input path is correct, that the process starts, and that you can see its output before detaching.
YouTube's workflow requires the server URL and stream key from Live Control Room to be entered into the encoder. Keep the stream key private: do not post it in a public script, screenshot, issue tracker or log you share. YouTube's encoder setup instructions describe entering the stream details and starting the encoder to send content. If a key is exposed, use YouTube's current controls to address it rather than treating it as ordinary configuration text.
The terminal session does not make an invalid encoder configuration valid. A wrong stream key, unsupported settings, unavailable media input, or poor upload path can still prevent a healthy broadcast. YouTube's live encoder settings guidance recommends RTMP or RTMPS, constant bitrate encoding and a two-second keyframe interval, with four seconds as the stated maximum. Its recommended bitrate depends on codec, resolution and frame rate; those figures are recommendations, not a measurement of what your EC2 instance can upload reliably.
For example, a devotional channel sending H.264 at 1080p and 30 frames per second should compare its encoder configuration with YouTube's recommendation for that mode, then test from the actual instance and network. The stream can still suffer if available upload capacity is inadequate or variable. For a separate ingest-path issue, see the guide to using a backup YouTube ingest server. Changing ingest destination and preserving an SSH session are different interventions.
Detach without stopping the command
When the encoder is running in screen, you can detach from the session rather than terminate it. The common screen shortcut is Ctrl-A, followed by D (press the Control key and A together, release, then press D). You should return to the ordinary SSH shell and see a detach message. The encoder remains in the screen session on the instance.
You can now close SSH or let the connection end. AWS's EC2 Linux documentation describes screen as a way to keep a long-running command available through a network interruption and reconnect later. The important point is that you detached from screen; you did not use the shell's ordinary exit command to end the encoder, and you did not send a stop signal to the process.
If you accidentally close the SSH terminal while still attached, the result may differ from an intentional detach, especially if screen was not actually running. Practise the sequence before relying on it, and verify the session appears after reconnecting. Keep a note of the Linux user and any session name you use. A predictable routine is more useful at 2 am than relying on memory about which account opened which terminal.
This also explains why changing SSH keepalive settings is not an equivalent fix. A keepalive can help with some idle-connection disconnects; it does not give the encoder a persistent terminal independent of SSH. If your goal is specifically that the command stays available after the client disappears, use a server-side session and confirm it is detached. AWS's SSH troubleshooting guidance discusses connection issues, but access settings and encoder lifecycle remain separate concerns.
Reconnect and inspect the session
When you need to check the stream, SSH back to the same EC2 instance as the same Linux user that created the session. List available screen sessions with screen -ls. If the expected session is shown, reattach with screen -r; if there is more than one, use the session identifier shown in the list as part of the reattach command. The exact display includes a process identifier and often a name, so read the output rather than guessing.
If the session list is empty, check the instance, account and session state before concluding the encoder has failed. You may have connected to a different host or used a different user. If screen reports an attached session because another terminal is still connected, inspect the message and decide whether to resume that session or detach the other client; do not start another encoder blindly, because two encoders using the same channel can produce confusing results.
Once reattached, inspect the encoder's visible output and process status. A live-looking terminal is not proof that YouTube is receiving a healthy signal. Check the Live Control Room preview, stream health and messages. YouTube recommends testing before an event and monitoring stream health while it is under way. A practical test should use representative movement and audio: a static image may not reveal the same encoding or input issues as the real programme.
For a bhajan loop, for instance, confirm the source is continuing, the encoder is still producing output, and the Live Control Room reports a usable incoming stream. If the encoder is gone, investigate its exit message, input file, permissions, logs and network path. If YouTube reports a problem while the process remains alive, inspect the ingest settings and signal quality rather than assuming the SSH disconnect caused it. The article on YouTube stream keys for a continuous lofi broadcast covers key handling in that workflow.
Know what screen cannot recover
Screen does not provide automatic encoder restart. If the encoder crashes or exits because its input disappears, the session may remain, but the command is finished. You need to diagnose the reason and decide how to relaunch it. Likewise, screen does not recover an instance after reboot: a reboot ends the old in-memory session, and this workflow does not configure anything to start again at boot.
It also does not repair a full disk, a failing media source, an expired or incorrect stream key, a YouTube ingest problem, or an instance's loss of network access. These failures can stop the broadcast even if the screen session itself was correctly detached. Keep enough operational checks around the session to notice when the encoder is no longer doing useful work.
| Situation | What screen contributes | What you still need to do |
|---|---|---|
| SSH client closes after screen is detached | Retains the terminal session on the instance for later attachment | Reconnect as the same user and inspect the command |
| Encoder exits on an error | The session may remain available, but screen does not restart the encoder | Read output or logs, fix the cause, and decide whether to relaunch |
| EC2 instance reboots | Screen does not restore the previous session | Plan and test a separate boot/startup approach if reboot recovery is required |
| YouTube reports unhealthy ingest | Preserves the terminal, not stream quality or ingest delivery | Check encoder settings, input, bandwidth and Live Control Room messages |
If you need an always-on setup that survives more than a dropped SSH connection, define the failure you are trying to handle and test that recovery path separately. Process supervision and startup after reboot are operating-system tasks with their own configuration and failure modes; this article does not provide a universal service-unit recipe. Do not assume a terminal multiplexer supplies those behaviours.
A different operating model may suit you better if you do not want to maintain an EC2 host, SSH access and an encoder process. StreamNeo removes the need to leave your own computer or SSH terminal in charge by taking an uploaded video and running it as a YouTube live stream, but it is YouTube-only and does not replace diagnosing an existing EC2 encoder.
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 EC2 encoder keep running if I close SSH?
If the encoder is running inside a GNU screen session and you detach from that session, closing SSH does not close the screen terminal. Reconnect to the same instance as the same Linux user and reattach to inspect it. This does not ensure the encoder itself is still healthy.
How do I return to the screen session?
SSH back into the instance with the account that created the session, list sessions with screen -ls, then use screen -r to reattach. If several sessions are listed, use the identifier shown by screen. A different user may not see the session you expect.
Does screen restart the encoder after a crash or reboot?
No. Screen is for retaining a terminal session through an SSH interruption; it is not encoder supervision or reboot recovery. If the process exits or the instance restarts, diagnose the cause and configure and test a separate recovery method if you require one.
Should I use SSH keepalives instead?
Keepalives can help with some idle SSH disconnects, but they keep the connection alive rather than separating the encoder from the SSH terminal. For a command that must continue when SSH ends, use a persistent session such as screen and verify that it is detached. You still need to monitor the actual YouTube stream.