How to Use the nohup Command in Linux

Keeping processes running on a Linux system after you log out or close the terminal is a common challenge. The nohup command offers a straightforward solution, ensuring your tasks continue uninterrupted by making them immune to terminal hangup signals (SIGHUP). In this article, we will explore the nohup command, demonstrating its usage, exploring how it interacts with sessions, and comparing it with other tools to effectively manage your long-running background processes.

Nohup, short for no hang up, is a command in Linux systems that keep processes running even after exiting the shell or terminal. Nohup prevents the processes or jobs from receiving the SIGHUP (Signal Hang UP) signal. This is a signal that is sent to a process upon closing or exiting the terminal. In this guide, we take a look at the nohup command and demonstrate how it can be used.

The nohup command syntax is as follows:

1. nohup command arguments

OR

1. nohup options

Let’s see how the command comes into play.

You can begin by checking the version of Nohup using the following syntax:

1. nohup –version

Output:

If you want to keep your processes/jobs running, precede the command with nohup as shown below. The jobs will still continue running in the shell and will not get killed upon exiting the shell or terminal.

For this example, let’s use a simple bash script:

./hello.sh

#!/bin/bash echo “Hello World!”

Now run this script using nohup:

1. nohup ./hello.sh

Output:

From the output above, the output of the command has been saved to nohup.out. To verify this, run:

1. cat nohup.out

Output:

Additionally, you can also redirect the output to a different file:

1. nohup ./hello.sh > output.txt

Once again, to view the file, run:

1. cat output.txt

Output:

To redirect standard error to the same place as standard output, use the > filename 2>&1 attribute:

1. nohup ./hello.sh > myoutput.txt 2>&1

Output:

To start a process in the background use the & symbol at the end of the command. In this example, we are pinging google.com and sending it to the background.

1. nohup ping google.com &

Output:

To check the process when resuming the shell, use the pgrep command:

1. pgrep -a ping

Output:

If you want to stop or kill the running process, use the killcommand followed by the process ID:

1. kill 2565

Output:

Nohup is a basic utility primarily used for running commands that need to persist even after a user logs out. It achieves this by making the command immune to the SIGHUP signal, which is typically sent to processes upon logout. Additionally, nohup redirects the standard output and standard error of the command to a file named nohup.out if they are not already redirected. This tool is incredibly simple to use and has a very low overhead, making it suitable for simple, long-running tasks. However, its simplicity comes at the cost of features; it offers no form of interactivity or session management, meaning once the command is started, you cannot directly interact with it or manage its execution beyond letting it run or killing the process later.

Screen provides a more advanced solution for managing terminal sessions, allowing users to create and manage multiple terminal windows within a single session. One of its key features is the ability to detach from a session and then reattach to it later, even from a different location. This ensures that processes running within screen sessions continue to run even if the user’s terminal connection is interrupted. Screen also provides a degree of session persistence, meaning sessions can often survive network disruptions or disconnections, minimizing the risk of losing progress on long-running tasks. However, the key bindings and window management system in screen can be less intuitive compared to modern alternatives, potentially requiring a steeper learning curve for some users.

Tmux is considered a modern and powerful terminal multiplexer, adopting a client-server model to manage terminal sessions. It organizes work into sessions, which can contain multiple windows, and each window can be further divided into panes. This structure provides granular control over the terminal environment. Tmux offers excellent interactivity, allowing users to easily switch between windows and panes, adjust layouts, and manage sessions efficiently. Its features include highly customizable keybindings, intuitive window and pane management, and strong scripting capabilities, making it a versatile tool for complex workflows. While tmux is generally considered superior in terms of features and usability, it might not be installed by default on older systems, and its initial learning curve can be steeper than nohup, albeit generally more rewarding in the long run.

Scenario 1: SSH session disconnects (network drop, client crash)

When an SSH connection terminates unexpectedly, due to a network interruption or the SSH client crashing, the SSH daemon on the server typically sends a SIGHUP signal to the user’s login shell. This shell, in turn, usually sends the SIGHUP signal to any child processes it has started, causing them to terminate by default. However, if a command was launched using nohup, its behavior changes significantly. The process is configured to ignore the SIGHUP signal. Consequently, despite the session disconnection and the subsequent signal cascade, the process continues to run unaffected on the server. Its output, which would have been lost with the terminal, is safely redirected to nohup.out or any other file specified during its invocation. This resilience against SSH disconnects is a primary and intended use case for the nohup utility.

Scenario 2: Normal user logout (e.g., typing exit or logout)

During a normal user logout, initiated by commands like exit or logout, the login shell begins its termination sequence. As part of this process, the shell typically sends a SIGHUP signal to all of its child processes, including any background jobs. For processes not specially shielded, this SIGHUP signal would lead to their termination. In contrast, a command that was started with nohup will ignore this SIGHUP signal. As a result, even though the user has logged out and the parent shell has terminated, the process persists and continues its execution in the background. Its output and error streams remain directed to nohup.out or the user-defined log file.

Scenario 3: Closing a Terminal emulator window (e.g., xterm, gnome-terminal)

The behavior of nohup when a terminal emulator window is closed depends on where the nohup command was executed. If the command was run on a remote server through an SSH session within that terminal window, closing the window usually terminates the local SSH client. This action triggers the SSH server to send a SIGHUP signal to the remote shell and its children, similar to a direct SSH disconnection. In this case, the process on the remote server will ignore the SIGHUP and continue running. Alternatively, if the nohup command was executed in a local shell directly within the terminal window (not over an SSH connection), closing the terminal emulator typically sends a SIGHUP signal to that local shell, which would then send it to its children. Even in this local scenario, the process ignores the SIGHUP and continues to run. Its parent process ID may change to 1 (init) or another system process responsible for orphaned processes, but the command itself persists.

Scenario 4: System shutdown or reboot

When a system undergoes a controlled shutdown or reboot, the operating system initiates a sequence to terminate all running processes. This typically involves sending a SIGTERM signal first, allowing processes a chance to exit gracefully, followed by a SIGKILL signal if they do not terminate in time. The nohup command does not provide any protection against these system-level termination signals like SIGTERM or SIGKILL. Therefore, any process launched with nohup will be terminated along with all other processes during a system shutdown or reboot. To ensure a process restarts automatically after a reboot, one would need to use more robust mechanisms like systemd services, upstart jobs, or cron’s @reboot functionality, as nohup alone is insufficient for this purpose.

Scenario 5: Process being killed manually

The immunity nohup provides to a process is specifically against the SIGHUP signal. If other signals, such as SIGTERM (the default signal sent by the kill command) or SIGKILL (a non-ignorable signal used by kill -9), are sent directly to the process ID (PID), the process will terminate. Therefore, nohup offers no defense against deliberate manual termination attempts using commands like kill or killall that employ signals other than SIGHUP.

Scenario 6: Running nohup without & (in the foreground)

If nohup is used to launch a command without the trailing ampersand (&), such as nohup ./my_script.sh, the script ./my_script.sh is still configured to ignore the SIGHUP signal, and its standard output and error streams will be redirected to nohup.out if they are connected to a terminal. However, a key difference is that the terminal will remain attached to the nohup command itself, and the shell prompt will not return until ./my_script.sh finishes its execution. If the terminal session is then closed or disconnects while the command is still running, the underlying script (./my_script.sh) will ignore the resulting SIGHUP and continue to run (potentially being reparented to init). While the script survives, this mode of operation is less common because it blocks the terminal. To detach it after starting, one might use Ctrl+Z followed by bg and then disown, although nohup already ensures the critical SIGHUP immunity for the command itself.

Scenario 7: Shell exits due to session limits or timeouts

Some server environments are configured with session limits or idle timeouts (e.g., using the TMOUT variable in bash or through SSH server configurations) that automatically terminate user sessions after a certain period of inactivity. The mechanism for such automatic termination often involves sending a SIGHUP signal to the user’s shell. In such cases, if a command was initiated with nohup, it will continue to run unaffected. The process, by ignoring the SIGHUP signal triggered by the timeout, demonstrates the same resilience as it would during an explicit logout or a network disconnection, ensuring the task’s longevity despite automated session cleanup.

Scenario 8: What if nohup.out cannot be written?

When nohup attempts to redirect standard output and standard error, its default behavior is to try and append to nohup.out in the current working directory. If this action fails, perhaps due to insufficient write permissions, nohup will then attempt to create or append to nohup.out within the user’s home directory ($HOME/nohup.out). If this second attempt also fails, the nohup command itself may exit with an error, failing to launch the target command. Alternatively, the target command might launch, but its output and error streams, unable to be written to the intended file, could effectively be lost (similar to being redirected to /dev/null). In such failure cases, nohup typically prints an error message to its standard error (which would be the terminal if not otherwise redirected), indicating its inability to open the nohup.out file.

While nohup itself rarely fails without indicating an issue, such as being unable to write its output file, commands executed via nohup can terminate unexpectedly, leading to what users perceive as a “silent failure.” This usually occurs not because nohup malfunctioned, but because the launched command itself exited prematurely. Common reasons include the command encountering an immediate internal error, such as a faulty configuration or missing dependency, or if it’s a shell script, an unhandled error within the script (especially with set -e), or an inability to find other commands due to a minimal PATH environment.

The environment in which nohup executes a command can be significantly different and more restricted than a user’s interactive shell, leading to failures if the command relies on specific environment variables or paths not available. Furthermore, a command might run for a period and then terminate due to resource exhaustion, like running out of memory (triggering the OOM killer) or disk space, or it might exit if it unexpectedly requires interactive input, which nohup redirects from /dev/null. Permissions issues encountered by the command during its operation, distinct from nohup’s initial permissions, can also cause it to stop.

In these “silent failure” scenarios, nohup has successfully detached the process to ignore hangup signals; the subsequent failure is internal to the command. The “silence” is often from the user’s perspective after disconnecting, as error messages from the command itself are typically redirected to nohup.out (or the user-specified output file). Therefore, the first step in diagnosing such issues is to meticulously check this output file and relevant system logs, which often contain the reasons for the command’s unexpected termination.

Effective logging with nohup goes beyond its default nohup.out file, ensuring your background processes are traceable and debuggable.

• While nohup defaults to nohup.out (or $HOME/nohup.out), you can redirect the output for better control.

  • Separate Streams: For clear error tracking, send stdout and stderr to distinct files: nohup ./my_cmd > app.log 2> app.err &
  • Combined Stream: To keep all output in one place with a custom name: nohup ./my_cmd > combined.log 2>&1 &

• Use descriptive filenames, possibly incorporating timestamps (e.g., app_$(date +%F).log), to easily identify logs. Store these files in designated log directories (e.g., /var/log/my_app/ or a project logs/ folder) and ensure the process has necessary write permissions.

• The most critical practice is to ensure your application (./my_cmd) generates well-structured, timestamped logs with appropriate detail and log levels (INFO, DEBUG, ERROR). nohup merely captures this output; the quality of the logs originates from your application.

• nohup does not rotate logs. For long-running processes, prevent excessive disk usage by implementing log rotation. This can be done either by the application itself or using external tools like logrotate for the files nohup writes to.

• Review your logs periodically using tools like tail -f (for live monitoring), less, and grep to check for errors and ensure the application is behaving as expected.

By focusing on how your application logs and how nohup captures that output, you can maintain an effective logging strategy.

1. What does nohup do in Linux?

nohup (which stands for “no hang up”) is a Linux command that allows a process to continue running even after you log out or your terminal session is closed. It achieves this by making the command ignore the SIGHUP (hangup) signal, which is normally sent to processes when their controlling terminal disconnects.

2. Do I need & with nohup?

While nohup makes your command immune to the SIGHUP signal, it doesn’t automatically run the command in the background.

• If you run nohup your_command, your terminal will still be attached to it, and you won’t get your prompt back until the command finishes. However, if your terminal session then closes, your_command will continue to run.
• Using nohup your_command & is the common practice. The & symbol tells the shell to run the command in the background, freeing up your terminal immediately.

So, you don’t strictly need & for nohup to provide SIGHUP immunity, but you almost always want to use it to regain control of your terminal.

3. Where does the output of a nohup command go?

By default, nohup redirects the standard output (stdout) and standard error (stderr) of the command to a file:

• It first tries to write to a file named nohup.out in the current working directory.
• If it cannot create nohup.out there (e.g., due to permissions), it will try to create and use $HOME/nohup.out (a nohup.out file in your home directory).
• You can, and often should, redirect the output to a specific file of your choice, for example:

1. nohup ./my_script.sh > my_output.log 2> my_errors.log &

Or to combine both into one file:

1. nohup ./my_script.sh > all_my_output.log 2>&1 &

4. What’s the difference between nohup and tmux?

nohup and tmux serve different primary purposes for managing processes, though both can keep things running after you disconnect.

The key difference is that nohup is primarily for running a single, usually non-interactive command in the background and ensuring it continues after you log out, with its output typically redirected to a file (like nohup.out). It’s a “fire-and-forget” tool with no persistent session to re-enter.

tmux, on the other hand, is a terminal multiplexer that creates persistent, fully interactive sessions. These sessions can contain multiple windows and panes, allowing you to run many commands and applications, see their live output, and interact with them. You can detach from a tmux session (leaving everything running) and reattach later.

In summary, nohup is an indispensable Linux utility for ensuring your critical commands persist beyond the life of a terminal session. By adeptly ignoring SIGHUP signals and providing mechanisms for output redirection, it offers a simple yet robust method to run background processes reliably, bringing stability and continuity to your essential long-running tasks.

Ready to delve deeper into the world of Linux commands and process management? Expand your knowledge and enhance your command-line skills with these handpicked tutorials: