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

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

nohup

命令和

&

符号。

nohup

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

&

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

解决方案

nohup

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

nohup

就是为了规避这一点。

其基本用法是：

nohup your_command [args...] &

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

1. nohup

   : 这是命令本身，它确保

   your_command

   在接收到SIGHUP信号时不会终止。

2. your_command [args...]

   : 你真正想要执行的命令及其参数。

3. &

   : 这个符号非常重要，它告诉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启动的进程是否仍在运行，以及如何终止它们？

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

Cogram

使用AI帮你做会议笔记，跟踪行动项目

38

查看详情

检查进程运行状态：

我通常会用

ps

命令结合

grep

来查找。

1. 根据进程名查找：

   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

   关键词的行。

2. 根据

   nohup

   关键词查找： 有时候，你可能不记得具体的程序名，但知道它是用

   nohup

   启动的。

   ps aux | grep nohup

   这种方式可能会列出所有通过

   nohup

   启动的进程，你需要从结果中识别出你想要的那个。

3. 查看进程的父ID (PPID)： 一个重要的判断依据是进程的 PPID。如果一个进程的 PPID 是

   1

   (通常是

   init

   或

   systemd

   进程)，那么它就意味着它已经脱离了原始的父进程（你的shell），独立运行了。这正是

   nohup

   的效果。

   ps -ef | grep [你的程序名]

   在输出结果中，第二列是 PID，第三列是 PPID。

终止进程：

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

1. 温柔地终止 (SIGTERM)：

   kill [PID]

   这是最推荐的方式，它会发送一个

   SIGTERM

   信号给进程，给它一个机会来优雅地关闭，比如保存数据、释放资源等。

2. 强制终止 (SIGKILL)：

   kill -9 [PID]

   如果

   kill [PID]

   无效，进程拒绝退出，你可以使用

   kill -9

   。这会发送

   SIGKILL

   信号，强制进程立即终止，不给它任何清理的机会。这就像直接拔电源，可能会导致数据丢失或文件损坏，所以要慎用。

3. 通过进程名终止 (慎用)：

   pkill [你的程序名]

   pkill

   命令可以直接根据进程名终止进程，但它会终止所有匹配该名称的进程。如果你有多个同名进程在运行，这可能会误伤无辜。除非你非常确定只有一个实例在运行，否则我不太推荐这种方式。

需要注意的是，通过

nohup

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

jobs

命令来查看或管理它。

jobs

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

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

其实吧，除了

nohup

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

1. 使用

   screen

   或

   tmux

   (会话管理工具) 这是我个人非常喜欢，也觉得功能最强大的方案之一。

   screen

   和

   tmux

   都允许你创建虚拟终端会话。你可以在这些会话中启动程序，然后“分离”（detach）会话，即使你的SSH连接断开，会话和其中运行的程序依然会在服务器上保持运行。当你需要时，可以随时“重新连接”（re-attach）到这个会话，就像你从未离开过一样，甚至能看到程序的实时输出，并继续与之交互。

   • 优点： 极度灵活，可以管理多个会话，随时查看和交互，非常适合长时间运行的交互式任务或需要频繁检查进度的任务。
   • 缺点： 需要先启动

     screen

     或

     tmux

     会话，然后在这个会话中运行你的命令。对于只想简单启动一个后台进程的情况，可能显得有点“重”。

   • 简单用法：
     • 启动一个新的

       screen

       会话：

       screen
     • 在

       screen

       会话中运行你的命令：

       your_command
     • 分离会话（不关闭）：

       Ctrl+A D
     • 重新连接会话：

       screen -r

       (如果有多个会话，需要指定会话ID)

2. 将进程作为

   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

       (查看服务状态)。

3. 使用

   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会话中已知的后台作业生效，不能用于启动新进程。

在我看来，

nohup

适合快速、临时性的后台任务；

screen

或

tmux

适合需要交互或频繁检查进度的长时间任务；而

systemd

则是生产环境中管理关键服务的首选。选择哪种方法，完全取决于你的具体需求和使用场景。