Linux怎么使用nohup命令保持进程运行

P粉602998670

发布时间：2025-09-15 09:45:01

352人浏览过

来源于php中文网

原创

最直接的方法是使用nohup命令结合&符号，让进程忽略SIGHUP信号并在后台运行，即使终端关闭也能持续执行，同时建议重定向输出到指定日志文件以便追踪。

linux怎么使用nohup命令保持进程运行

在Linux环境下，要让一个进程在终端关闭后依然保持运行，最直接且常用的方法就是结合使用

nohup

命令和

符号。

nohup

的全称是 "no hang up"，它的作用就是让命令忽略SIGHUP（挂断）信号，而

符号则让命令在后台运行。简单来说，就是启动一个进程，告诉系统：“嘿，这个程序即使我走了，你也得给我继续跑着，别停！”

解决方案

nohup

命令的核心在于它能让进程脱离控制终端。当你通过SSH连接到一个远程服务器，或者在一个本地终端中启动一个耗时任务，一旦终端关闭，通常会发送SIGHUP信号给所有子进程，导致它们随之终止。

nohup

就是为了规避这一点。

其基本用法是：

nohup your_command [args...] &

这里有几个关键点需要说明：

nohup
: 这是命令本身，它确保
```
your_command
```
在接收到SIGHUP信号时不会终止。
your_command [args...]
: 你真正想要执行的命令及其参数。
&
: 这个符号非常重要，它告诉shell立即将
```
your_command
```
放到后台执行，这样你就可以继续使用当前终端，而不用等待命令执行完毕。

一个更完善的用法，通常还会涉及到标准输出和标准错误的重定向，因为

nohup

默认会将这些输出重定向到当前目录下的

nohup.out

文件。但如果

nohup.out

不可写，或者你希望自定义日志文件，就需要手动指定：

nohup your_command > /path/to/your_log_file.log 2>&1 &

```
>
```
: 将标准输出重定向到指定文件。
```
2>&1
```
: 这是一个非常常见的写法，它的意思是将标准错误（文件描述符2）也重定向到标准输出（文件描述符1）所指向的地方。这样，无论命令是正常输出还是报错，所有信息都会写入同一个日志文件，方便后续排查。

举个例子，我经常需要跑一些Python脚本来处理数据，可能要跑几个小时甚至几天。我通常会这么启动：

nohup python3 my_data_processor.py --input data.csv > processing_log.txt 2>&1 &

这样，即使我的SSH连接断了，或者我关了笔记本，脚本依然会在服务器上默默运行，所有输出和错误都会记录在

processing_log.txt

里。

nohup命令的输出重定向有什么讲究？

在我看来，

nohup

命令的输出重定向是其使用过程中最容易被忽视，但又至关重要的一环。很多人可能只知道

nohup command &

，然后就发现当前目录下多了一个

nohup.out

文件。这当然可以，但在实际生产环境或更复杂的任务中，这种默认行为往往不够灵活或不符合预期。

首先，

nohup

默认会将标准输出（stdout）和标准错误（stderr）都重定向到

nohup.out

文件。如果当前目录不可写，它会尝试重定向到用户家目录下的

nohup.out

。如果两者都不可写，那么输出可能会丢失，或者直接输出到终端，这显然就失去了后台运行的意义。

我个人更倾向于明确指定日志文件路径和名称，并且统一处理标准输出和标准错误。这通常通过

> /path/to/your_log.log 2>&1

来实现。

为什么统一处理？ 想象一下，你的程序正常运行的日志写到了
```
stdout.log
```
，但突然崩溃了，错误信息却跑到了
```
stderr.log
```
。当你想排查问题时，就得同时检查两个文件，这无疑增加了复杂性。把它们都导向一个文件，能让你在一个地方看到完整的执行记录，无论是程序的正常进度还是潜在的错误信息。这在调试和监控时简直是福音。
日志文件的位置和命名：我建议根据项目的需要，将日志文件放在一个专门的日志目录下（比如
```
/var/log/my_app/
```
或项目根目录下的
```
logs/
```
），并采用有意义的命名方式，比如
```
my_script_$(date +%Y%m%d%H%M%S).log
```
，这样每次启动都能生成一个带时间戳的独立日志文件，避免覆盖，方便回溯历史记录。
日志轮转：如果你的程序会产生大量的日志，那么日志文件可能会变得非常庞大，占用大量磁盘空间。这时候就需要考虑日志轮转（log rotation）了，比如使用
```
logrotate
```
工具。虽然
```
nohup
```
本身不提供这个功能，但这是你规划日志管理时需要考虑的一个重要方面。

所以，与其依赖

nohup.out

，不如从一开始就养成好习惯，为你的后台进程配置清晰、可控的日志输出。这不仅仅是为了满足

nohup

的需求，更是为了程序的健壮性和可维护性。

如何检查使用nohup启动的进程是否仍在运行，以及如何终止它们？

当你把一个进程扔到后台，并且脱离了终端，自然会想知道它是不是还在尽职尽责地跑着，或者万一出问题了，怎么把它揪出来干掉。

PathFinder

AI驱动的销售漏斗分析工具

下载

检查进程运行状态：

我通常会用

ps

命令结合

grep

来查找。

根据进程名查找：

ps aux | grep [你的程序名或关键词]

例如，如果我跑的是

python3 my_data_processor.py

，我会这样搜：

ps aux | grep my_data_processor.py

或者更精确一点，避免

grep

自身被搜到：

ps aux | grep -v grep | grep my_data_processor.py

-v grep

的意思是排除包含

grep

关键词的行。

根据
nohup
关键词查找：有时候，你可能不记得具体的程序名，但知道它是用
```
nohup
```
启动的。
```
ps aux | grep nohup
```
这种方式可能会列出所有通过
```
nohup
```
启动的进程，你需要从结果中识别出你想要的那个。
查看进程的父ID (PPID)： 一个重要的判断依据是进程的 PPID。如果一个进程的 PPID 是
```
1
```
(通常是
```
init
```
或
```
systemd
```
进程)，那么它就意味着它已经脱离了原始的父进程（你的shell），独立运行了。这正是
```
nohup
```
的效果。
```
ps -ef | grep [你的程序名]
```
在输出结果中，第二列是 PID，第三列是 PPID。

终止进程：

一旦你找到了进程的 PID (Process ID)，终止它就相对简单了。

温柔地终止 (SIGTERM)：
```
kill [PID]
```
这是最推荐的方式，它会发送一个
```
SIGTERM
```
信号给进程，给它一个机会来优雅地关闭，比如保存数据、释放资源等。
强制终止 (SIGKILL)：
```
kill -9 [PID]
```
如果
```
kill [PID]
```
无效，进程拒绝退出，你可以使用
```
kill -9
```
。这会发送
```
SIGKILL
```
信号，强制进程立即终止，不给它任何清理的机会。这就像直接拔电源，可能会导致数据丢失或文件损坏，所以要慎用。
通过进程名终止 (慎用)：
```
pkill [你的程序名]
```
```
pkill
```
命令可以直接根据进程名终止进程，但它会终止所有匹配该名称的进程。如果你有多个同名进程在运行，这可能会误伤无辜。除非你非常确定只有一个实例在运行，否则我不太推荐这种方式。

需要注意的是，通过

nohup

启动的进程，因为它已经脱离了shell，所以你无法通过

jobs

命令来查看或管理它。

jobs

命令只能列出当前shell会话中处于后台的进程。

除了nohup，还有哪些方法可以在Linux中保持进程后台运行或在会话断开后继续执行？

其实吧，除了

nohup

这种简单粗暴但有效的办法，Linux世界里还有不少更“高级”或更“正规”的工具和方法来管理后台进程，它们各有侧重，适用于不同的场景。

使用
```
screen
```
或
tmux
(会话管理工具) 这是我个人非常喜欢，也觉得功能最强大的方案之一。
```
screen
```
和
```
tmux
```
都允许你创建虚拟终端会话。你可以在这些会话中启动程序，然后“分离”（detach）会话，即使你的SSH连接断开，会话和其中运行的程序依然会在服务器上保持运行。当你需要时，可以随时“重新连接”（re-attach）到这个会话，就像你从未离开过一样，甚至能看到程序的实时输出，并继续与之交互。
- 优点： 极度灵活，可以管理多个会话，随时查看和交互，非常适合长时间运行的交互式任务或需要频繁检查进度的任务。
- 缺点： 需要先启动
```
screen
```
  或
```
tmux
```
  会话，然后在这个会话中运行你的命令。对于只想简单启动一个后台进程的情况，可能显得有点“重”。
- 简单用法：
  - 启动一个新的
```
screen
```
    会话：
```
screen
```
  - 在
```
screen
```
    会话中运行你的命令：
```
your_command
```
  - 分离会话（不关闭）：
```
Ctrl+A D
```
  - 重新连接会话：
```
screen -r
```
    (如果有多个会话，需要指定会话ID)
将进程作为
```
systemd
```
服务运行 (系统级服务管理) 对于那些需要长期稳定运行、开机自启、并且需要系统级管理和监控的程序，例如Web服务器、数据库、定时任务守护进程等，将其配置为
```
systemd
```
服务是最标准、最推荐的做法。
- 优点：
  - 开机自启： 系统启动时自动运行。
  - 可靠性：
```
systemd
```
    可以配置在进程崩溃时自动重启，保证服务持续可用。
  - 统一管理： 所有服务都在
```
systemctl
```
    的框架下管理，方便查看状态、启动、停止等。
  - 资源控制： 可以设置资源限制。
- 缺点： 配置相对复杂，需要编写
```
.service
```
  文件，不适合临时的、一次性的后台任务。
- 大致流程：
  - 在
```
/etc/systemd/system/
```
    目录下创建一个
```
.service
```
    文件 (例如
```
my_app.service
```
    )。
  - 配置
```
[Unit]
```
    、
```
[Service]
```
    、
```
[Install]
```
    等段落，指定
```
ExecStart
```
    (你的程序路径)、
```
WorkingDirectory
```
    、
```
User
```
    、
```
Restart
```
    策略等。
  - ```
  sudo systemctl daemon-reload
```
  (重新加载
```
  systemd
```
  配置)。
- ```
sudo systemctl enable my_app
```
    (设置开机自启)。
  - ```
  sudo systemctl start my_app
```
  (启动服务)。
- ```
sudo systemctl status my_app
```
    (查看服务状态)。
使用
```
disown
```
命令 (针对已在后台运行的进程)
```
disown
```
命令与
```
nohup
```
有点类似，但它作用于已经通过
&
符号放到后台的进程。如果你不小心忘记用
```
nohup
```
启动了一个进程，但它已经在后台运行了，并且你不想让它在终端关闭时终止，那么
```
disown
```
就能派上用场。
- 用法：
  1. 先将命令放到后台：
```
your_command &
```
  2. 查看后台任务列表：
```
jobs
```
    (会显示类似
```
[1]+ Running your_command &
```
    的信息)
  3. 使用
```
disown
```
    命令：
```
disown -h %1
```
    (这里的
```
%1
```
    是
```
jobs
```
    命令显示的作业号) 或者，如果你知道进程的 PID，也可以用
```
disown -h [PID]
```
    。
- 优点： 补救措施，可以在事后让进程脱离终端。
- 缺点： 只能对当前shell会话中已知的后台作业生效，不能用于启动新进程。