后台执行与 nohup 的核心作用

在 Linux 环境中，将任务置于后台运行通常会在命令末尾追加 & 符号。然而，仅使用 & 并不能保证任务在终端会话结束后继续运行。这就是 nohup（no hang up）命令发挥作用的地方。要理解其底层原理，我们需要深入探讨 Unix/Linux 的信号机制。

Unix/Linux 信号机制与 SIGHUP

信号是 Unix 系统中进程间通信（IPC）的一种基础方式，用于通知进程发生了特定事件。我们可以通过 kill -l 查看系统支持的所有信号：

$ kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
...

在 C 语言的头文件（如 <signal.h> 或 <bits/signum.h>）中，这些信号被定义为宏：

#define SIGHUP   1  /* Hangup (POSIX) */
#define SIGINT   2  /* Interrupt (ANSI) */
#define SIGQUIT  3  /* Quit (POSIX) */
#define SIGKILL  9  /* Kill, unblockable (POSIX) */
#define SIGTERM 15  /* Termination (ANSI) */
// ... 其他信号定义

每个信号都有默认的处理动作（通常是终止进程）。除了 SIGKILL (9) 和 SIGSTOP (19) 无法被捕获或忽略外，进程可以通过信号处理函数来拦截并自定义其他信号的行为。

终端退出与进程终止的真相

当我们通过 SSH 客户端连接到服务器并启动一个后台进程时，该进程的父进程是当前 Shell。如果直接关闭终端窗口，终端模拟器会向 Shell 发送 SIGHUP（信号 1，Hangup）信号。

Shell 在收到 SIGHUP 后，默认会将该信号转发给其所有作业（包括后台作业）。由于 SIGHUP 的默认动作是终止进程，这就导致了即使使用了 &，后台任务也会随着终端的关闭而意外退出。nohup 的核心功能正是让进程忽略 SIGHUP 信号。

对比测试：验证 SIGHUP 的影响

我们使用一个简单的长时间休眠命令 sleep 7200 来模拟后台任务，观察其在不同配置下的表现。

场景一：仅使用 & 后台执行

# 在终端 A 中启动后台任务
[user@host ~]$ sleep 7200 &
[1] 8842
[user@host ~]$ jobs
[1]+  Running                 sleep 7200 &

# 在终端 B 中查看进程状态
[user@host ~]$ ps -ef | grep sleep
user  8842  8801  0 10:00 pts/1    00:00:00 sleep 7200
user  8901  8850  0 10:01 pts/2    00:00:00 grep --color=auto sleep

此时关闭终端 A，再次在终端 B 中检查：

# 终端 A 关闭后
[user@host ~]$ ps -ef | grep sleep
user  8955  8850  0 10:02 pts/2    00:00:00 grep --color=auto sleep

进程已消失，证明终端关闭触发了 SIGHUP 并终止了任务。

场景二：使用 nohup 结合 &

# 在终端 A 中启动
[user@host ~]$ nohup sleep 7200 > task.log 2>&1 &
[1] 9102
[user@host ~]$ jobs
[1]+  Running                 nohup sleep 7200 > task.log 2>&1 &

# 在终端 B 中查看
[user@host ~]$ ps -ef | grep sleep
user  9102  9050  0 10:05 pts/1    00:00:00 sleep 7200

关闭终端 A 后：

# 终端 A 关闭后
[user@host ~]$ ps -ef | grep sleep
user  9102     1  0 10:05 ?        00:00:00 sleep 7200

进程依然存活，且其父进程 ID（PPID）变为了 1（通常是 systemd 或 init）。这说明原 Shell 退出后，该进程被系统接管，且成功忽略了 SIGHUP 信号。

替代方案：使用 trap 拦截信号

如果不想使用 nohup，我们可以利用 Shell 内置的 trap 命令来显式忽略 SIGHUP 信号（信号编号为 1）。

# 在终端 A 中设置 trap 忽略 SIGHUP
[user@host ~]$ trap '' 1

# 启动普通后台任务（不带 nohup）
[user@host ~]$ sleep 7200 > task_trap.log 2>&1 &
[1] 9501

# 在终端 B 中确认进程
[user@host ~]$ ps -ef | grep sleep
user  9501  9450  0 10:10 pts/1    00:00:00 sleep 7200

关闭终端 A 后，在终端 B 中验证：

[user@host ~]$ ps -ef | grep sleep
user  9501     1  0 10:10 ?        00:00:00 sleep 7200

通过 trap '' 1，当前 Shell 及其派生的子进程都会忽略挂断信号，达到了与 nohup 相同的效果。

不同 Shell 的默认行为差异

值得注意的是，SIGHUP 的转发行为与所使用的 Shell 密切相关。在早期的 csh 或 tcsh 中，Shell 默认不会将 SIGHUP 传递给后台作业。

# 切换到 csh
[user@host ~]$ csh
% sleep 7200 > csh_task.log &
[1] 9800

# 在另一个终端查看
[user@host ~]$ ps -ef | grep sleep
user  9800  9750  0 10:15 pts/1    00:00:00 sleep 7200

在 csh 环境下关闭原始终端，后台进程依然会存活并被 PID 1 接管。而在现代常用的 bash 中，可以通过 shopt -u huponexit 来关闭退出时发送 SIGHUP 的特性，或者使用 disown 命令将作业从 Shell 的作业列表中移除，从而避免接收到挂断信号。