引言

在 Linux 系统中，一个常见的挑战是确保程序在您注销或关闭终端后仍能继续运行。如果直接在终端中启动一个进程，当终端关闭时，该进程通常会收到 SIGHUP (挂断) 信号并随之终止。nohup 命令为这个问题提供了一个直接而有效的解决方案，它能让您的任务不受终端挂断信号的影响，持续稳定地在后台运行。

什么是 nohup 命令？

nohup 是 “no hang up” 的缩写，它是一个 Linux 命令，用于使进程在您退出 shell 或终端后仍能继续执行。nohup 的核心功能是阻止其所启动的进程或作业接收 SIGHUP 信号。当您关闭终端或退出会话时，系统会向该会话下的所有进程发送 SIGHUP 信号，而 nohup 可以确保其保护的进程忽略此信号，从而保持运行。

nohup 命令语法与版本查看

nohup 命令的基本语法非常简单：

nohup command [arguments]

或者，如果您只想查看 nohup 自身的选项：

nohup [options]

要检查 nohup 命令的版本，您可以使用以下语法：

nohup --version

使用 nohup 启动进程

如果您希望某个进程或作业在您退出 shell 后继续运行，只需在命令前加上 nohup。即使您关闭终端或断开 SSH 连接，该作业仍会在后台持续运行，而不会被终止。

例如，考虑一个简单的 Bash 脚本 hello.sh：

./hello.sh

#!/bin/bash
echo "Hello World!"

现在，使用 nohup 运行此脚本：

nohup ./hello.sh

默认情况下，nohup 命令的输出（包括 stdout 和 stderr）将被重定向并保存到当前目录下的一个名为 nohup.out 的文件中。您可以使用 cat nohup.out 命令来查看其内容。

您也可以将输出重定向到其他指定的文件：

nohup ./hello.sh > output.txt

要将标准错误（stderr）重定向到与标准输出（stdout）相同的文件中，请使用 > filename 2>&1 语法：

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

使用 nohup 在后台启动进程

为了让进程在后台运行，并在执行 nohup 命令后立即返回 shell 提示符，请在命令的末尾加上 & 符号。

例如，在后台持续 ping google.com：

nohup ping google.com &

要检查该进程是否在 shell 恢复后仍在运行，您可以使用 pgrep 命令，并结合 -a 选项来显示完整的命令：

pgrep -a ping

如果您需要停止或终止正在运行的进程，可以使用 kill 命令，后面跟上进程的 ID (PID)：

kill 2565

（这里的 2565 仅为示例进程 ID，实际操作时请替换为通过 pgrep 或 ps 命令查到的真实 PID。）

nohup、screen 与 tmux 的对比

在 Linux 中，除了 nohup，还有 screen 和 tmux 这样的终端复用器，它们也能实现进程在会话断开后继续运行的功能。理解它们的区别有助于选择最适合您需求的工具。

• nohup：

  • 定位：一个基础工具，主要用于让单个命令在用户注销后持续运行。
  • 原理：通过使命令免疫于 SIGHUP 信号来实现。其标准输出和标准错误默认重定向到 nohup.out 文件。
  • 特点：使用简单，开销低。
  • 限制：不支持交互式会话管理，即您无法重新连接到该进程的终端并与其互动。

• Screen：

  • 定位：一个更高级的终端会话管理器。
  • 原理：允许用户在一个会话中创建和管理多个虚拟终端窗口。
  • 特点：核心功能是能够从会话中分离（detach）并在之后重新连接（reattach），即使从不同的位置连接。这确保了在 Screen 会话中运行的进程即使终端连接中断也能继续运行，并且您可以随时返回到该会话进行交互。
  • 适用场景：需要管理多个长期运行的交互式任务。

• Tmux：

  • 定位：被认为是现代且功能更强大的终端复用器。
  • 原理：采用客户端-服务器模型来管理终端会话，将工作组织成会话，每个会话可以包含多个窗口，每个窗口又可以进一步划分为窗格（pane）。
  • 特点：提供出色的交互性、高度可定制的键绑定和强大的脚本功能。
  • 适用场景：处理复杂工作流、需要高度自定义和多窗口管理的场景。

总结来说，nohup 适用于简单的、非交互式的后台任务；而 screen 和 tmux 则更适合需要长期保持会话、管理多个并发任务或需要随时重新连接进行交互的复杂场景。

nohup 如何与用户会话交互

理解 nohup 在不同会话断开情境下的行为至关重要：

• SSH 会话断开（网络中断、客户端崩溃）： 当 SSH 连接意外终止时，SSH 守护进程通常会向用户的登录 shell 发送 SIGHUP 信号。然而，使用 nohup 启动的命令被配置为忽略此信号，因此即使会话断开，进程也会继续在服务器上运行。其输出安全地重定向到 nohup.out 或您指定的文件。

• 正常用户注销（例如，输入 exit 或 logout）： 在正常用户注销期间，登录 shell 会向其所有子进程（包括后台作业）发送 SIGHUP 信号。使用 nohup 启动的命令将忽略此信号，因此即使用户注销且父 shell 终止，进程也会继续在后台执行。

• 关闭终端模拟器窗口（例如，xterm、gnome-terminal）： 如果命令通过 SSH 会话在终端窗口中运行，关闭窗口会终止本地 SSH 客户端，从而触发 SSH 服务器向远程 shell 及子进程发送 SIGHUP。进程会忽略此信号并继续运行。如果命令在本地 shell 中直接运行，进程也会忽略 SIGHUP 并继续运行，其父进程 ID (PPID) 可能会变为 1 (init 或 systemd)。

• 系统关机或重启： nohup 命令不提供对抗 SIGTERM (终止信号) 或 SIGKILL (强制杀死信号) 等系统级终止信号的保护。因此，在系统关机或重启期间，任何通过 nohup 启动的进程都将与其他所有进程一起终止。要确保进程在系统重启后自动启动，您需要使用 systemd 服务、upstart 作业或 cron 的 @reboot 功能来管理。

• 进程被手动终止： nohup 提供的免疫力专门针对 SIGHUP 信号。如果直接向进程 ID (PID) 发送其他信号（如 kill 命令发送的默认 SIGTERM 或 kill -9 使用的不可忽略的 SIGKILL），进程仍将被终止。

• 不带 & 运行 nohup（在前台）： 如果 nohup 命令不带 & 符号启动（即在前台运行），脚本仍将忽略 SIGHUP，但终端会一直连接到 nohup 命令本身，直到脚本执行完毕才会返回 shell 提示符。此模式不常见，因为它会阻塞当前终端。

• Shell 因会话限制或超时而退出： 如果服务器环境配置了会话限制或空闲超时，导致用户会话自动终止，通常会通过发送 SIGHUP 信号实现。在这种情况下，由 nohup 启动的命令将继续运行而不受影响。

• 如果 nohup.out 无法写入： 当 nohup 尝试重定向标准输出和标准错误时，如果无法在当前工作目录写入 nohup.out（例如由于权限不足），它将尝试在用户主目录 ($HOME/nohup.out) 中创建或追加。如果第二次尝试也失败，nohup 命令本身可能会因错误而退出，或者目标命令会启动，但其输出和错误流将丢失。

理解 nohup 的“静默失败”

尽管 nohup 命令本身很少在没有指示问题的情况下失败（除非它无法写入输出文件），但通过 nohup 执行的命令可能会意外终止，导致用户误认为是“静默失败”。这通常不是因为 nohup 出现故障，而是因为其启动的命令本身提前退出了。

常见的“静默失败”原因包括：

• 内部错误：命令遇到内部错误（如错误的配置或缺少的依赖项）。
• 脚本错误：脚本中存在未处理的错误导致退出。
• 命令未找到：由于 PATH 环境变量极小或其他原因，导致脚本内调用的其他命令无法找到。
• 资源耗尽：例如内存不足 (OOM) 或磁盘空间不足。
• 需要交互式输入：命令在后台运行，但其执行过程中需要用户交互式输入，而这种输入无法从非交互式环境中获得。

在这些“静默失败”场景中，nohup 已经成功地将进程与挂断信号分离；随后的失败是命令内部的问题。用户断开连接后，“静默”通常是从用户的角度来看的，因为命令本身的错误消息通常会重定向到 nohup.out（或用户指定的输出文件）。因此，诊断此类问题的第一步是仔细检查此输出文件和相关的系统日志。

nohup 的正确日志记录实践

与 nohup 结合使用时，有效的日志记录不仅仅依赖于默认的 nohup.out 文件，它还能确保您的后台进程可追溯和可调试。

• 重定向输出：
  • 独立流：将 stdout 和 stderr 发送到不同的文件，以便清晰地追踪错误。

    nohup ./my_cmd > app.log 2> app.err &
    

  • 合并流：将所有输出（stdout 和 stderr）保留在一个自定义命名的文件中。

    nohup ./my_cmd > combined.log 2>&1 &
    

• 使用描述性文件名：考虑在日志文件名中包含时间戳（例如，app_$(date +%F).log），以便轻松识别和管理日志文件。
• 指定日志目录：将这些日志文件存储在指定的日志目录中（例如，/var/log/my_app/ 或项目根目录下的 logs/ 文件夹），并确保进程具有必要的写入权限。
• 应用程序日志质量：确保您的应用程序本身生成结构良好、带有时间戳、详细且日志级别（如 INFO、DEBUG、WARN、ERROR）适当的日志信息。nohup 仅负责捕获这些输出；日志的质量来源于您的应用程序代码。
• 日志轮换：nohup 不会自动轮换日志。对于长时间运行的进程，请务必通过应用程序本身实现日志轮换，或使用 logrotate 等外部工具来防止日志文件过大占用过多磁盘空间。
• 定期审查日志：使用 tail -f（用于实时监控）、less、grep 等工具定期审查日志，以检查错误并确保应用程序行为符合预期。

通过关注应用程序如何记录日志以及 nohup 如何捕获该输出，您可以维护一个高效且可维护的日志策略，从而更好地管理您的后台进程。

关于

关注我获取更多资讯

📢 公众号

💬 个人号