Nohup Command on Linux with Examples

Linux system administrators and power users often run tasks that must persist beyond their current terminal session—such as lengthy data backups, software builds, or downloads. Losing these crucial processes after an accidental logout, network interruption, or SSH disconnect can be both frustrating and wasteful. The Linux nohup command, short for “no hang up,” is a lifesaver in such scenarios. This in-depth guide explains the nohup command, offering practical nohup examples, syntax, troubleshooting, and advanced usage. System administrators, developers, and anyone managing Linux servers will discover how to keep jobs running efficiently, with step-by-step instructions and best practices.

What Is the Nohup Command?

Definition and Etymology

The nohup command stands for “no hang up.” It is a standard POSIX utility originating from early Unix environments, designed to protect running processes from the SIGHUP (hang up) signal sent to terminal sessions when users log out or lose connection. By detaching a command from its controlling terminal, nohup allows the process to remain active until completion regardless of user login state.

The SIGHUP Signal

The SIGHUP signal (signal number 1) is sent by the kernel when a user’s controlling terminal unexpectedly disconnects—due to logout, SSH drop, or network timeout. Without intervention, all child processes tied to the session would receive SIGHUP and be terminated. This can disrupt upgrades, migrations, or any command that must not be interrupted.

How Nohup Works

Nohup intercepts the SIGHUP signal (and often SIGQUIT), ignoring it for the targeted process. In practical terms, it re-parents the process, shielding it from hangups. Output is rerouted to a file (default: nohup.out), allowing tasks to continue running independently in the background. Nohup is primarily used in combination with background execution (&), ensuring the specified process persists past the active shell.

Nohup Command Syntax and Options

Basic Syntax

The nohup syntax is simple and effective:

nohup command [arguments] &

• command: The application, script, or shell command you wish to run.
• [arguments]: Options or parameters for the target command.
• &: An optional operator to put the command in the background for immediate terminal reuse.

For example:

nohup ./backup.sh &

Options

While nohup has few options, they’re essential for version checking and help documentation:

• --help : Display the help manual for nohup usage.
• --version : Show the version information.
• -p pid : (rarely used) Modify an existing process to ignore SIGHUP (not widely available across all platforms).
• & : Not part of nohup, but critical for running the target command in the background.

Installing and Checking Nohup

Availability Across Distributions

Nohup ships by default with all major Linux distributions and Unix-like operating systems, including Ubuntu, Debian, CentOS, and Red Hat Enterprise Linux. There’s no need for separate package installation. It is part of the GNU core utilities on most systems.

Version Verification

To verify if nohup is installed and check its version, use:

nohup --version

If the command is missing, a typical troubleshooting step is to check if coreutils is present, as nohup is a standard component. If needed, install it using your package manager:

sudo apt-get install coreutils    # Debian/Ubuntu
sudo yum install coreutils        # CentOS/RHEL

Basic Nohup Usage Examples

Running Simple Commands

By prefixing any command with nohup, you shield it from SIGHUP. For instance, to execute a Bash script no matter if the terminal disconnects:

nohup bash example.sh

This runs example.sh and by default appends both output and error streams to nohup.out in the current directory. View results by:

cat nohup.out

Custom Output Redirection

Output redirection is essential for monitoring the progress and errors of background jobs. Redirect command output and errors to specific files for better log management:

nohup ./myscript.sh > output.log 2>&1 &

• > output.log: Standard output goes to output.log
• 2>&1: Standard error is redirected to standard output
• &: Runs the command in the background

This is a robust pattern for production scripts executed remotely or unattended.

Background Process Execution

To keep the terminal available for other tasks while running long jobs:

nohup ./longtask.sh &

After starting, the shell will display a job ID and a process ID, such as:

[1] 15234
nohup: appending output to 'nohup.out'

This indicates the job and PID—useful for further process management.

Advanced Nohup Examples

Long-Running Downloads

When downloading a large file from the Internet where network disruptions are probable, nohup ensures resilience:

nohup wget http://example.com/bigfile.iso &

If you log off or the connection drops, wget keeps working, with progress tracked in nohup.out or a redirected file.

Database Operations

For database dumps or restores that could take hours:

nohup mysqldump -u root -p mydatabase > backup.sql 2>&1 &

This backs up MySQL or MariaDB safely. Append 2>&1 to consolidate output and errors in one file for troubleshooting.

For PostgreSQL:

nohup pg_dump mydb > pg_backup.sql 2>&1 &

Monitor backup.sql or nohup.out to check progress or errors.

System Monitoring Tasks

Nohup is invaluable for ongoing resource monitoring, e.g.:

nohup top -b -d 30 > top_report.txt &

• -b (batch mode) and -d 30 (interval) log system state every 30 seconds.

Or, for continuous log tailing:

nohup tail -f /var/log/syslog > monitored_syslog.txt &

Multiple Command Execution

To execute multiple commands sequentially while ensuring all persist:

nohup bash -c 'command1 && command2 && command3' > all_output.log 2>&1 &

Use command chaining (&&) to run steps in order—failure in one halts the sequence, and all outputs are captured efficiently.

Process Management with Nohup

Finding Nohup Processes

To manage or review nohup-spawned processes, obtain their PID using:

ps -ef | grep nohup

Or, filter for a specific command name:

pgrep -fl commandname

This practical approach helps verify your jobs are still running after logout.

Bringing Processes to Foreground

If you started a nohup job in the background, but want to interact with it, check job status:

jobs

And bring it foreground (only possible within the initiating shell):

fg %1

Note: If you log out and back in, this approach won’t recover the job to your active terminal—consider screen or tmux for full session restoration.

Terminating Nohup Processes

To stop a nohup-managed process safely:

1. Find its PID (ps, pgrep, or check nohup.out for clues).
2. Send a gentle termination:

kill <PID>

If the process ignores SIGTERM, escalate with:

kill -9 <PID>

Use caution as kill -9 forces immediate termination without cleanup.

Output Management and Logging

Default Output Behavior

If no redirection is given, all output (stdout and stderr) is sent to nohup.out in the directory where the command was run:

nohup ./heavyjob.sh &

• Creates or appends to nohup.out
• If nohup.out cannot be created in the working directory, it attempts in your $HOME.

File permissions mirror those of the executing user.

Custom Log File Management

For better organization, specify custom log files:

nohup ./dataprocess.sh > /var/log/dataprocess.log 2>&1 &

• Use directories and naming conventions for easier job tracing.
• Consider timestamping files for rotation:

nohup ./dailyjob.sh > logs/dailyjob_$(date +%F).log 2>&1 &

Automated log management tools like logrotate can help prevent disks from filling with excessive output.

Real-Time Log Monitoring

While jobs run in the background, monitor output with:

tail -f nohup.out

Or, for custom files:

tail -f /var/log/dataprocess.log

Filters and search can be applied using grep for spotting errors:

grep -i error nohup.out

For large files, less is optimal for interactive review.

Nohup vs Alternative Tools

Nohup vs Screen

nohup and screen serve different roles. Nohup keeps a process alive past connection drops, but offers no interactivity once the session is closed. Conversely, screen is a terminal multiplexer letting users detach, reattach, and interactively resume ongoing shells. Use nohup for simple persistence, and screen for complex, interactive multi-session workflows.

Nohup vs Tmux

tmux, like screen, allows you to manage multiple terminal sessions, detach from them, and reattach later—perfect for running tasks you may need to monitor interactively. nohup works straightforwardly for simple, non-interactive background tasks.

Nohup vs systemd Services

For truly persistent, reboot-tolerant and monitored jobs, convert your command into a systemd service unit. This is best for production-grade, always-on services needing automatic restart, logging, and resource controls. Nohup is best for ad-hoc, user-managed sessions.

Best Practices and Tips

Security Considerations

• Limit output files’ permissions: chmod 600 to protect logs and command output.
• Avoid writing sensitive data to world-readable nohup.out.
• Always run nohup as a user with appropriate privileges—avoid running as root unless necessary.

Performance Optimization

• Monitor disk usage if output is verbose or command runs for days.
• Use output log rotation or cleanup strategies to prevent filling up storage.
• Design scripts with error handling so unexpected failures do not quietly pollute logs.

Error Handling Strategies

• Check exit codes at the end of nohup-managed scripts: echo $? in the command or after.
• Implement notifications (email or alert) for failures.
• Test your nohup workflow on smaller tasks before deploying on critical jobs.

Common Pitfalls and Troubleshooting

Typical Mistakes

• Forgetting the & symbol: The job runs but you lose the shell until it completes.
• Not redirecting output or errors: Missing important log information for debugging.
• Running commands from directories where you lack write permission—nohup.out cannot be created.
• Using nohup for interactive programs (editors) which is not supported.

Debugging Techniques

• Use ps -ef, pgrep, and jobs -l to identify running and hung processes.
• Scan nohup.out for error messages or incomplete runs.
• Confirm process backgrounds correctly by checking their PID activity (ps, top).
• If remote login drops and you can’t reattach, always fall back to logs—interactive recovery is not possible with nohup alone.

Real-World Use Cases

System Administration

Nohup is indispensable for system admins. Use it for:

• Remote package upgrades: nohup apt-get upgrade -y > upgrades.log 2>&1 &
• Automated server patching overnight
• Backup and restore operations executing securely while minimizing human intervention

Development and Testing

Devs and DevOps engineers benefit from nohup during:

• Continuous integration tasks (build scripts, automated testing)
• Deployment scripts that must not be interrupted
• Launching long-running simulations without holding a local SSH terminal

Data Processing

Data operations can be safely backgrounded, such as:

• Running ETL jobs or big data transformations: nohup spark-submit job.py > spark.log 2>&1 &
• Machine Learning model training over several hours
• Mass log parsing jobs, preventing accidental session drops from killing vital jobs