Linux下用nohup让Python脚本后台长期运行

在 Linux 环境中执行长时间运行的 Python 任务（如数据爬取、模型训练或轻量服务端），最常遇到的阻碍是终端会话中断导致进程退出。要让脚本在退出 SSH 登录后依然持续运行，最直接且轻量的方案是结合使用 nohup 命令、后台符号 & 以及标准流重定向。本文将详细讲解这一机制的组合语法、底层信号处理、缓冲区行为及完整的生命周期管理。

1. 核心运行命令与标准语法

让 Python 脚本脱离终端并在后台运行的标准执行命令如下：

nohup python3 -u app.py > app.log 2>&1 &

这条命令由几个独立起作用的 Linux 机制组合而成。若拆开来看，每个部分分管着不同的运行时职责：

• nohup：阻断挂起信号（SIGHUP），防止会话断开时操作系统向进程发送终止信号。
• python3 -u：启用非缓冲（unbuffered）模式，确保 print 输出立即写入文件而非驻留在内存中。
• > app.log：将标准输出（stdout，文件描述符为 1）重定向到指定的日志文件 app.log。
• 2>&1：将标准错误（stderr，文件描述符为 2）重定向到标准输出相同的位置，使得错误堆栈和正常输出汇聚在同一文件。
• &：通知 Shell 将该任务置于后台子进程中运行，立即释放当前命令行提示符。

图 1：nohup 信号屏蔽与标准流重定向架构说明

2. 为什么必须同时使用 nohup 与 &

一个流传甚广的误区是：“只需要在命令末尾加 & 就能让脚本在后台永久运行”，或者“用了 nohup 就不需要 &”。这两种理解都只覆盖了一半的实际需求。

在 Linux 进程模型中：

• & 的作用域仅限于终端前后台切换：它告诉当前 Shell“不要等待该命令返回，把当前控制台输入权交还给我”。但是，该进程的父进程依然是当前的 Shell。一旦你关闭终端窗口或网络断开，终端所属的会话（Session）结束，系统默认会向该会话下的所有子进程广播发送 SIGHUP 信号，未做防护的后台任务随即被强行杀死。
• nohup 的作用是信号过滤：它的全称是 no hang up，用来让启动的进程忽略所有 SIGHUP 信号。即使终端断开、父会话消失，子进程被系统 1 号进程（systemd 或 init）接管，依然可以继续运转。但 nohup 本身并不会将进程放入后台——单独执行 nohup python3 app.py 会持续占据你的控制台，直到你手动按下 Ctrl + C 发送 SIGINT 信号直接将其打断。

因此，nohup 负责“免除挂断终止”，& 负责“让出前台交互”，两者配合才能达到“脱离会话且不卡住当前控制台”的目的。

图 2：常用后台命令形式与行为特征对比

3. 关键细节：为什么必须加 -u 参数

很多开发者在初次使用 nohup python app.py > app.log 2>&1 & 时，会发现一个普遍现象：通过 ps 能查到进程正常运行，但查看日志文件 app.log 时却始终为空，甚至几个小时都不见任何新内容输出。这往往被误认为是脚本锁死或没有执行。

造成这一现象的根本原因是 Python 标准 I/O 的缓冲机制：

• 当 Python 脚本直接运行在终端（TTY 交互设备）时，标准输出默认采用行缓冲（Line Buffering），即代码中只要执行到换行符 print("hello\n")，内容就会立刻刷出到屏幕。
• 当标准输出被重定向到普通磁盘文件（非 TTY 设备）时，C 标准库与 Python 会自动切换为块缓冲（Block Buffering）。这意味着数据必须在内存缓冲区积攒到指定大小（通常为 4KB 或 8KB）后，才会一次性刷入磁盘。如果脚本输出频率不高，日志文件就会长时间保持 0 字节。

添加 -u（即 unbuffered）参数会强制关闭标准输出与标准错误的二进制/文本缓冲区，确保每一次 print() 或异常输出都能被实时写入磁盘文件。

4. 完整操作步骤与验证流程

在实际服务器上部署并管理一个长时间运行的脚本，建议遵循标准的操作周期：启动、记录 PID、查看状态、实时验流以及必要时的终止。

图 3：nohup 后台任务的标准操作周期

第一步：进入目录并启动任务

cd /home/work/project
nohup python3 -u app.py > app.log 2>&1 &

执行后终端会立刻返回类似 [1] 23891 的提示，其中 23891 即系统分配给该任务的进程编号（PID）。如果执行时省略了输出重定向，nohup 会默认在当前目录创建名为 nohup.out 的日志文件。

第二步：确认进程确实存活

不要启动后立刻退出 SSH。由于环境缺依赖或配置路径写错，很多脚本在前 2 秒内就会崩溃退出。通过 ps 检查该命令是否在列表中正常运作：

ps -ef | grep app.py | grep -v grep

示例输出：

work  23891  14201  0 10:20 pts/0  00:00:01 python3 -u app.py

第三步：动态观察日志输出

使用 tail -f 跟踪日志内容，确认业务逻辑按预期在周期性执行：

tail -f app.log

确认无误后，按下 Ctrl + C 仅退出日志跟踪工具，此时后台 Python 脚本依然在稳定运行。此时可以放心关闭终端会话。

第四步：任务完成或需要停止时的回收操作

因为脚本已经脱离了前台，停止它需要向指定 PID 发送终止信号：

# 优先使用 SIGTERM，通知 Python 触发清理并安全退出
kill 23891

# 若进程无响应且确认卡死，再使用强制信号（谨慎使用）
kill -9 23891

5. 实际使用中的边界与进阶建议

nohup 是一种零配置、跨各种 Linux 发行版均通用的临时/轻量级运行方案。理解它的能力边界有助于在开发运维中少踩坑：

• 无自动拉起功能：nohup 并不具备守护进程（Daemon）的崩溃自启特性。如果脚本因为代码未捕获的 Exception、内存耗尽（OOM Killer）或底层系统重启而退出，nohup 不会重新启动脚本。对于核心业务系统，更推荐编写 systemd 服务单元或使用 Supervisor。
• 单文件体积膨胀：使用 > app.log 2>&1 会无限制地追加日志。若程序打印极其密集且长期运行，可能会耗尽服务器磁盘 Inode 或存储空间。如果程序需要长期运作，建议在 Python 代码内部使用自带的 logging.handlers.RotatingFileHandler 实现按大小轮换，或者在 Linux 层配置 logrotate 配合管理。
• 追加写与覆盖写：单大于号 > 代表清空覆盖，如果重启脚本希望保留历史日志，应改用双大于号 >> 实现追加写入：nohup python3 -u app.py >> app.log 2>&1 &。

图 4：根据场景权衡不同的后台长期运行方案

总结

在 Linux 中利用 nohup 保证 Python 脚本长期运行的核心在于组合的准确性：用 nohup 屏蔽中断信号，用 & 换取控制台自由，用 -u 绕过标准输出缓冲以保证日志即时刷写，最后用 2>&1 将全部运行信息归集保存。这一套组合具备极强的通用性与便携性，掌握其细节足以应对绝大多数常规的自动化脚本与离线计算任务。