If your encoder is running on a Linode server, start it inside a detached tmux session before closing SSH. The encoder can then continue after your laptop disconnects, and you can reconnect later with tmux attach.
That only protects the process from an SSH disconnect. It does not guarantee that YouTube continues receiving the stream, and it does not protect against a Linode host, network path, encoder, or YouTube problem. For recovery after a server reboot, use a systemd service enabled at boot.
Confirm where the encoder is running
Start by identifying the process that is actually sending video to YouTube. You may be using FFmpeg, OBS, an RTMP relay, or another encoder. The important question is not where you opened the SSH window, but where that encoder process is running.
There are three separate layers:
- Your SSH client and terminal window.
- The encoding or relay process on the Linode.
- YouTube’s incoming stream and broadcast state.
If the encoder is running on your own computer, disconnecting from Linode will not keep that local encoder alive. If the encoder is running on the Linode, the SSH connection is only the way you control it. A persistent terminal session can keep the server-side process attached to a live shell after your SSH client closes.
This distinction matters for a 24/7 channel. A devotional video loop, a local news playlist, or an ambience stream may appear to be running in the terminal, but the terminal is not the stream. The process producing and sending the media is the stream-producing part. The shell is only its interactive container.
Before changing anything, connect to the Linode and check how the process was started. If it is already inside tmux or screen, use that existing session rather than starting a second encoder. Linode’s guidance covers both approaches in its persistent terminal session documentation.
If you are still deciding between a self-managed VPS and another operating arrangement, the trade-offs are explained in YouTube 24/7 streaming service vs running OBS on a VPS. The choice affects who must inspect the process when something stops, but it does not change the need to separate SSH persistence from YouTube delivery.
Start the Linode process inside tmux
SSH into the Linode as you normally do, then start a new tmux session:
tmux new -s youtube-live
You should now be inside a terminal managed by tmux. Start the encoder or relay in this session, using the command and configuration appropriate to your setup. For example, a command might read from a local media file or playlist and publish to YouTube, but the exact command depends on your encoder, input format, audio settings, and loop method.
Do not detach immediately after launching the command. First check that the process is active and that YouTube shows the expected incoming picture and audio. This catches errors such as a missing input file, a failed codec, an invalid stream key, or a process that exits as soon as it starts.
You can use another SSH window to inspect the server if needed, but avoid launching a second copy of the same encoder. Two processes may compete for CPU, memory, the input file, or the same publishing destination. A second process can make an otherwise simple failure harder to diagnose.
When the stream is visibly reaching YouTube, detach from tmux by pressing:
Ctrl+B, then D
Press and release Ctrl+B as the tmux prefix, then press D. You should return to the ordinary SSH shell with a message indicating that the session was detached. The encoder should remain inside the tmux session on the Linode.
At that point you can close SSH. The important action is detaching, not leaving the terminal open overnight. Keeping an SSH window open does not make the stream more reliable, and it leaves the process dependent on that interactive connection.
A detached tmux session is useful when the immediate failure is “I logged out and the process stopped”. It is not a complete service-management system. It does not decide whether an encoder that has exited should be restarted, and it does not recreate the session after a server reboot.
Detach from and reconnect to the session
To see the sessions currently available after logging in again, run:
tmux ls
If the session is listed as youtube-live, reconnect with:
tmux attach -t youtube-live
You should see the terminal in which the encoder was started. From there you can inspect its output, look for error messages, or stop it deliberately. To leave it running while returning to the SSH shell, use Ctrl+B, then D again.
If you do not remember the session name, tmux attach may attach to the available session when there is only one. Naming sessions is still preferable because it makes a server with several workloads easier to understand. A session name such as youtube-live also reduces the chance of attaching to an unrelated maintenance shell.
If tmux ls reports that there are no sessions, do not assume YouTube is at fault. The session may have ended because the encoder exited, the server rebooted, or someone deliberately killed the session. Check whether the process is running and read its logs or terminal output before starting another copy.
The same principle applies if an established setup uses screen. A process already running in screen should normally be managed through that session. Moving a running process from an ordinary shell into a persistent session is not a simple attach operation, so plan the change during a maintenance window if the stream is important.
For a small channel, this workflow is often enough: start the process in tmux, verify YouTube receives it, detach, and reconnect when you need to inspect it. It addresses an operator problem without adding a service definition. It does not address every failure that can occur during a long broadcast.
Use systemd for recovery after a reboot
A server reboot destroys the running tmux session. This is the point at which tmux and systemd solve different problems.
tmux keeps a process associated with a server-side terminal after the SSH client disconnects. systemd can define the encoder as a service and start it when the operating system boots. If the stream must return after planned maintenance or an unexpected reboot, a boot-enabled service is more suitable than relying on a manually created terminal session.
A service definition normally specifies the user that should run the encoder, its working directory, the command to execute, and the boot target at which it should start. A simplified unit might look like this:
[Unit]
Description=YouTube live encoder
After=network-online.target
Wants=network-online.target
[Service]
User=streamer
WorkingDirectory=/home/streamer/live
ExecStart=/home/streamer/bin/start-stream.sh
[Install]
WantedBy=multi-user.target
Treat this as a structure to adapt, not a command to paste unchanged. Replace the user, directory, and script path with values that exist on your Linode. Keep the publishing credential out of places where other users can read it, and make sure the service user can read the media and execute the encoder.
After creating the unit, reload the service definitions and enable it at boot. The exact service name depends on the filename you chose. A typical sequence is:
sudo systemctl daemon-reload
sudo systemctl enable youtube-live.service
sudo systemctl start youtube-live.service
sudo systemctl status youtube-live.service
Check the service status and then check YouTube separately. A service can report that its command started while the encoder is failing to open a file, rejecting the stream key, or losing its connection to YouTube. Service startup is not proof that the broadcast is visible to viewers.
You can also inspect the service journal when the command exits or produces an error:
journalctl -u youtube-live.service
Test the boot path before depending on it overnight. First confirm that the command works under the same user and working directory as the service. Then test the service itself. If appropriate for your maintenance plan, arrange a controlled reboot and verify both that the service starts and that YouTube receives media again.
A service may also be configured with restart behaviour, but automatic process restarts should be introduced carefully. If the encoder exits because its input is missing or its credentials are invalid, repeatedly launching it can create a noisy failure rather than a recovery. Read the logs first and choose a policy that matches the actual cause.
Check YouTube’s RTMPS address and stream key
Once the local process is persistent, check where it is publishing. YouTube’s live setup uses an RTMPS stream URL and a stream key provided through Live Control Room. The encoder must use the correct fields for the selected broadcast. You can review the current requirements in YouTube’s live encoder settings help.
Do not treat the stream key as an ordinary label. It is a publishing credential. Avoid placing it in screenshots, public scripts, support posts, or shell history where it does not need to remain. If you believe it has been exposed, review the controls in YouTube Studio and replace or reset it according to the current official guidance.
A correct-looking process can still publish nothing if the URL is wrong, the key belongs to another setup, or the broadcast is not configured as expected. Copy the values from the relevant Live Control Room settings rather than relying on an old command saved months ago.
This is also where protocol terminology matters. RTMPS is the encrypted publishing connection used by the encoder in the YouTube setup. It is different from the SSH connection you use to administer the Linode. Disconnecting SSH does not intentionally close a correctly detached RTMPS publishing process, while an RTMPS failure can stop delivery even when SSH and tmux remain available.
For a broader explanation of protocol choices, see RTMP vs RTMPS vs SRT for always-on streams. For this troubleshooting task, however, start with the exact URL and key currently shown by YouTube rather than changing protocols without a reason.
Diagnose bitrate and connection instability
Suppose you reconnect to tmux and find the encoder process still running, but YouTube has stopped receiving a usable picture. That is evidence that terminal persistence is working. It does not mean the publishing path is healthy.
Inspect the encoder’s output for connection errors, reconnection messages, failed writes, input stalls, and dropped frames. Then check whether the server can maintain its outbound connection. A process can remain alive while its network socket is unusable, or it can keep retrying without producing a stable broadcast.
Bitrate is part of this diagnosis. If the selected video and audio bitrate exceeds what the outbound connection can sustain, media may be delayed, dropped, or disconnected. OBS describes a degraded connection indicator and rising dropped frames as signs worth investigating in its official troubleshooting guidance. Linode’s streaming documentation also discusses how an excessive streaming rate can contribute to disconnections.
Do not respond to every drop by increasing bitrate. Compare the configured bitrate with the available connection, then reduce unnecessary load if the link cannot sustain the current output. A lower, stable bitrate is more useful for an always-on channel than a higher setting that repeatedly loses contact with YouTube.
Check the encoder and input as well. A looping video may stop reading because the file path is wrong after a reboot, the mounted storage is unavailable, or the process has run out of memory. Audio can fail independently of video. A stream that appears connected but has silence may need an audio-specific check; the audio settings guide for 24/7 streams covers that separate part of the setup.
Use a simple sequence when investigating:
| What you observe | Most useful next check |
|---|---|
| SSH disconnects and the process ends | Confirm it was started inside tmux or screen |
tmux session is present but YouTube receives nothing |
Check encoder output, RTMPS URL, stream key, and publishing state |
| Process exits after a reboot | Check whether a systemd service exists and is enabled |
| Process remains alive but frames drop | Inspect outbound connection health and bitrate |
| Service starts but the stream is absent | Run the command as the service user and inspect its journal |
Keep each observation tied to one layer. This prevents you from rebuilding the Linode when the stream key is wrong, or changing YouTube settings when the encoder simply stopped after a reboot.
Know what tmux and systemd cannot protect against
Neither tmux nor systemd guarantees an uninterrupted YouTube livestream. They handle particular local process-management problems, not every dependency in the broadcast chain.
tmux does not protect against a Linode host failure, an operating system crash, an unavailable input file, an encoder fault, exhausted memory, or an outbound network outage. It also does not make a disconnected stream reconnect successfully to YouTube. It only keeps the terminal session and its attached process available after the SSH client goes away.
systemd adds boot-time service management, but it cannot make a failed command succeed. If the host is unavailable, the service cannot run. If the network is not ready, the service may start before it can publish. If the encoder has a configuration error, starting it at boot simply reproduces that error.
A separately hosted RTMP relay is an architectural alternative when you need one server to receive a stream and push it onwards to YouTube. Linode’s RTMP server guide describes that kind of arrangement. It adds configuration and operational responsibility, so it is not necessary merely because you want to disconnect SSH.
If your main problem is that a personal computer must remain switched on, a cloud-based workflow can remove that particular dependency. StreamNeo removes the need to keep the local computer running by letting you upload the video, provide the YouTube stream key, and have the channel run from the cloud with monitoring and automatic process recovery. It remains your responsibility to check the content, YouTube settings, and the result shown to viewers.
Choose the protection that matches the failure
Use tmux when the failure you are solving is the SSH connection. It is quick to introduce, easy to inspect, and useful when you want to reconnect to the same live terminal. It is a good fit for a hands-on operator who checks the stream and occasionally changes the command.
Use systemd when the process should be treated as a service and should start after a Linode reboot. It is a better fit for a channel that must not depend on someone remembering to create a session manually after maintenance. It also gives you a consistent place to inspect status and logs.
You can use both during a transition, but understand which one owns the process. If systemd launches the encoder, do not also launch a second copy inside tmux. You can inspect service logs from SSH without placing the service itself inside an interactive terminal.
Before leaving the setup unattended, write down the following:
- The Linode user that runs the encoder.
- The input file or playlist location.
- The command or startup script.
- The YouTube RTMPS URL and where the stream key is stored.
- The
tmuxsession name, if you use one. - The
systemdunit name, if you use one. - The commands for checking status and reading logs.
Then perform the checks in order. Start the encoder and confirm YouTube receives it. Detach from SSH and confirm the process remains available. If using systemd, test service start and a controlled reboot separately. Finally, check what happens when the outbound connection becomes unstable, using the encoder logs and YouTube’s status indicators rather than assuming that a running process means a healthy broadcast.
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 tmux keep my YouTube livestream running after I close SSH?
It can keep the encoder process running after the SSH client disconnects, provided the encoder was started inside the detached tmux session. It cannot protect the stream from a host failure, encoder error, network problem, or YouTube ingest issue.
Should I use tmux or systemd?
Use tmux for an interactive process that you want to inspect and reconnect to after SSH disconnects. Use systemd when the encoder should start as a service after a server reboot. Neither is a guarantee that YouTube will continue receiving media.
Why is the process running but YouTube shows no stream?
Check the encoder logs, the RTMPS URL, the stream key, the selected broadcast, and the outbound connection. Also inspect bitrate and dropped frames, because a live process can remain present while its connection to YouTube is unstable.
Does systemd restart the stream after every failure?
Only if you configure suitable service behaviour, and even then a restart does not fix an invalid command, missing input, unavailable host, or bad publishing credential. Test the service under the same user and paths it will use at boot, then verify YouTube separately.