Navigating remote servers via SSH is fundamental for developers, system administrators, and tech enthusiasts alike. However, a common frustration arises when a crucial program terminates abruptly after you log out from your SSH session. This happens because most processes started directly within an SSH session are children of that session and receive a SIGHUP (hang up) signal when the connection closes, leading to their termination. Understanding how to make a program continue to run after log out from SSH is essential for maintaining long-running tasks, ensuring data integrity, and optimizing server uptime. This guide explores several robust methods, from simple commands to advanced session management tools, empowering you to keep your applications operational even after disconnecting.
Understanding the Problem: SSH and SIGHUP
When you establish an SSH connection, a pseudo-terminal is created on the remote server, and your shell (e.g., Bash, Zsh) runs within it. Any program you launch directly from this shell becomes a child process of that shell. The critical mechanism at play here is the SIGHUP signal. Traditionally, this signal was sent to processes when a modem connection was lost, effectively indicating a “hang-up.” In the context of SSH, when your client disconnects, the SSH daemon on the server sends a SIGHUP signal to the shell process and, by default, to all its child processes.
Most programs are designed to terminate gracefully upon receiving a SIGHUP signal. This behavior is generally desirable for interactive tasks, but it poses a significant challenge for long-running scripts, data processing jobs, or server applications that need to operate continuously. Without a mechanism to detach these processes from the terminal or ignore the SIGHUP, they will inevitably shut down as soon as you log out or your network connection drops. This is why ensuring a persistent session is paramount for server management.
To prevent this automatic termination, we need strategies that either allow a process to ignore the SIGHUP signal or to detach it from the controlling terminal entirely, letting it run independently in the background. The following sections will delve into specific tools and techniques to achieve this, moving from simpler, ad-hoc solutions to more comprehensive system-level approaches.
Solution 1: Using nohup for Simple Background Processes
For straightforward tasks that you simply need to run in the background without worrying about re-attaching to them later, the nohup command is an excellent and easy-to-use solution. The name nohup stands for “no hang up,” and its primary function is to run a command such that it is immune to SIGHUP signals. When you preface a command with nohup, it prevents the process from receiving the SIGHUP signal sent by the operating system when the controlling terminal is closed.
Furthermore, nohup redirects the output of the command to a file named nohup.out in the current directory by default, if the output is not already redirected. This ensures that any standard output or error messages from your program are preserved, even after your SSH session ends. To use it, simply type nohup followed by your command and then append an ampersand (&) to push the process into the background immediately, allowing you to continue using your terminal or log out.
nohup your_command_here &
For example, to run a Python script continuously, you might use: nohup python3 my_script.py &. While nohup is incredibly useful for fire-and-forget tasks, it has limitations. You cannot re-attach to the process’s standard input/output, meaning you lose the ability to interact with it or see its real-time output once you’ve logged out. For more interactive or complex scenarios, other tools are more suitable.
- Pros of
nohup:- Extremely simple to use.
- Prevents termination from
SIGHUP. - Automatically redirects output to
nohup.out.
- Cons of
nohup:- No ability to re-attach to the session.
- Limited interaction with the running process.
- Not ideal for interactive applications.
Solution 2: Persistent Sessions with screen or tmux
For users who need more control over their background processes, including the ability to re-attach to a running session, terminal multiplexers like GNU Screen and Tmux are indispensable tools. These utilities allow you to create multiple virtual terminal sessions within a single SSH connection. The key advantage is that these sessions persist even if your SSH connection drops or you intentionally log out. You can then re-attach to them later from a new SSH session, picking up exactly where you left off.
GNU Screen has been a staple in the Unix/Linux world for decades. It’s robust, widely available, and highly configurable. To start a new screen session, simply type screen. Inside the screen session, you can run your commands. To detach from the session without terminating it, press Ctrl+A then D. To list active sessions, use screen -ls, and to re-attach, use screen -r [session_id] or screen -r if only one session exists.
Tmux (Terminal Multiplexer) is a more modern alternative to Question & Answer :
I have a program that takes a lot of time to finish. It is running as root over ssh.
I want it to continue to run after I logout,is this possible and how would I achieve this?
Assuming that you have a program running in the foreground, press Ctrl+Z, then:
[1]+ Stopped myprogram $ disown -h %1 $ bg 1 [1]+ myprogram & $ logout
If there is only one job, then you don’t need to specify the job number. Just use disown -h and bg.
Explanation of the above steps:
You press Ctrl+Z. The system suspends the running program, displays a job number and a “Stopped” message and returns you to a bash prompt.
You type the disown -h %1 command (here, I’ve used a 1, but you’d use the job number that was displayed in the Stopped message) which marks the job so it ignores the SIGHUP signal (it will not be stopped by logging out).
Next, type the bg command using the same job number; this resumes the running of the program in the background and a message is displayed confirming that.
You can now log out and it will continue running..
