Comparing Nohup, Disown And Backgrounding For Long-Running Ssh Processes

Keeping Remote Processes Running After SSH Session Ends

When working on remote servers over SSH, initiating long-running processes can be problematic. By default, when the SSH session disconnects, the remote shell also exits, killing any child processes started in that session. Methods like nohup, disown, and backgrounding allow processes to continue running after the SSH session ends.

The Problem: SSH Sessions Break Long-Running Processes

SSH provides a secure way to access remote shell environments. But SSH sessions and remote shells have a temporary lifetime. When the SSH client disconnects, the remote shell is terminated as a child process, and any processes started in that shell are also killed by the system.

For example, if you SSH to a remote server and run a data processing script expected to run for hours, by default the script would be terminated upon SSH session closing. This can lead to incomplete results or other undesired behavior for long-running processes.

nohup – Ignoring the HUP Signal for Continued Execution

The nohup command tells a process to ignore hangup signals so that it keeps running even after the parent process exits. The HUP or hangup signal is sent by systems to processes when their parent shell exits. By having the process ignore HUP signals, the system will no longer kill it if the parent shell quits.

For example, running a process like:

nohup my_script.sh &

Would allow my_script.sh to keep running in the background after disconnecting the SSH session that started it. nohup tells the process to ignore the HUP signal, allowing it to be orphaned and continue executing after the parent SSH shell exits.

Advantages

• Simple invocation using just nohup before the command
• Works for any process to daemonize it from a shell session
• Output still visible using nohup.out file

Disadvantages

• Can only start one process immune to hangup signal
• Must redirect stdout/stderr to capture output
• Some systems may require special init setup

disown – Removing a Process from the Shell’s Job List

The disown builtin command in Bash and other shells removes jobs from the shell’s active job list. This allows processes to continue running even though the shell thinks the job has terminated.

By disowning running background jobs, the processes will no longer be sent SIGHUP and killed automatically if the shell exits. This is another method to “daemonize” processes and detach them from the controlling terminal.

For example, starting a background job, then disowning it:

my_script.sh &
disown %1

This removes my_script.sh from the shell’s job list, allowing it to run independently even after shell exit.

Advantages

• Works on an existing running background job
• Can disown multiple jobs easily
• No need to redirect output to capture

Disadvantages

• Only available on systems with disown builtin
• Job must first be started in background
• Stopped jobs cannot be disowned

Backgrounding – Putting a Process in the Background

Backgrounding is a feature of most shells that allows commands to run in a subshell environment without blocking the terminal. Background processes run independently but remain tied to the shell’s job control system.

Starting a process in the background is useful for tasks that will take a long time but don’t need constant interaction. For SSH sessions, backgrounding long-running jobs allows them to keep processing even if the session disconnects.

Backgrounding can be accomplished by appending an & symbol or running the bg command:

my_script.sh &

Or:

my_script.sh
Ctrl + Z
bg

In both cases, my_script.sh is started in a subshell that is controlled by the job control system but runs independently of the terminal.

Advantages

• Works on most POSIX systems
• Jobs remain under shell’s control
• Can foreground jobs back to terminal

Disadvantages

• Background jobs still receive HUP signal on shell exit
• Stopping terminal session kills background jobs
• No auto-restart if process crashes

When to Use Each Method

There are certain situations where nohup, disown, or backgrounding are preferred depending on the requirements:

nohup for Simple Daemonization

nohup provides the simplest way to fully daemonize a process for cases where:

• Only one simple program/script needs to run detached
• Don’t want or need interaction with the process
• Process output should be captured in nohup.out

disown for Interactive Sessions

disown shines when running multiple utilities that require a terminal:

• Detaching interactive programs like top, vi, etc.
• Can selectively disown background jobs
• Terminal program remains running and usable

Backgrounding for On-Demand Backgrounding

Backgrounding is ideal for one-off background jobs where:

• Need to quickly background process from terminal
• Job should pause with terminal and resume in background
• Background process needs occasional monitoring

Usage Examples

nohup myprocess &

This starts myprocess detached from the terminal completely so it keeps running forever:

$ nohup myscript.sh &
$ exit
$ ssh user@host 'ps aux | grep [m]yscript'
user 298511 0.0 0.0 4242 3124 ? Ss 03:23 0:00 ./myscript.sh

myprocess & disown

First start the job in the background, then disown it from job control:

$ myscript.sh &
$ disown %1
$ exit
$ ssh user@host 'ps aux | grep [m]yscript'  
user 298512 0.0 0.0 4242 3124 ? Ss 03:25 0:00 ./myscript.sh

ctrl-z; bg

Suspend and background to hop between foreground and background:

$ myscript.sh
Ctrl+Z
$ bg
$ fg
$ bg

Checking On Background Processes

There are a few ways to check on the status of background processes:

jobs

List background jobs running on current shell session:

$ jobs
[1]+ Running myscript.sh &

ps

Cross-platform tool to see active processes:

$ ps aux | grep myscript
user 298511 0.0 0.0 4242 3124 ? Ss 03:23 0:00 /path/myscript.sh

pstree

Tree view of all processes on system:

$ pstree
  ├─sshd─sshd──bash──pstree
  └─systemd─smbd
       ├─myscript.sh   

Considerations for Remote Environments

When running detached processes on remote servers, there are additional factors to consider:

Avoiding Unintentional Exits

• Processes may be killed if system is power cycled
• Use init systems or supervisord to restart
• Monitor for crashes with health checks

Monitoring and Restarting

• Check live status with top/htop
• Inspect logs for errors
• Control process restarts with init or monit