答案：Linux下后台运行命令的核心是解放终端并确保任务持续执行。使用&可将命令放入后台，但终端关闭后进程会终止；nohup结合&能忽略SIGHUP信号，使任务在终端关闭后仍运行，并自动重定向输出至nohup.out；screen和tmux提供会话管理功能，支持分离与重新连接，适合长期服务或远程工作；disown可用于已后台运行的作业，使其脱离shell控制。选择方法需根据任务时长、是否需交互及稳定性要求决定。

在Linux下，将命令放入后台运行，核心目的就是让它们在不占用当前终端的情况下继续执行，即使你关闭了终端，任务也能不中断地跑下去。这不仅能释放你的命令行，让你能继续其他操作，更重要的是，它能确保一些耗时或需要持续运行的服务不因终端关闭而中断。最常用的几种方法包括利用

&

符号、

nohup

命令，以及更强大的会话管理工具如

screen

或

tmux

。

解决方案

要让Linux命令在后台运行，我们通常有以下几种策略，每种都有其独特的适用场景和优势：

使用

&

符号将命令放入后台

这是最直接、最简单的办法，在任何命令的末尾加上一个

&

符号，它就会立即被扔到后台执行，并返回一个进程ID（PID）。比如，你想运行一个耗时的脚本但又不想等它执行完：

./my_long_running_script.sh &

这样，你的终端会立刻恢复可输入状态，脚本则在后台默默运行。不过，这里有个重要的坑：如果你的终端会话（比如SSH连接）关闭，这个后台进程通常也会收到一个SIGHUP信号，然后跟着挂掉。除非脚本内部有处理这个信号的机制，否则它不会继续执行。这对于一些临时的、不那么重要的后台任务来说还行，但对于需要长时间稳定运行的任务，就显得不够健壮了。

利用

nohup

命令忽略SIGHUP信号

当我们需要确保命令在终端关闭后依然存活，

nohup

就派上用场了。

nohup

的全称是”no hang up”，它的作用就是让命令忽略SIGHUP信号。结合

&

符号，它能让你在关闭终端后，命令仍然在后台持续运行。

nohup ./my_service_starter.sh &

这样执行后，

my_service_starter.sh

会脱离当前终端的控制，即使你退出SSH会话，它也会继续跑。

nohup

还会将命令的标准输出和标准错误默认重定向到一个名为

nohup.out

的文件中（如果当前目录下没有这个文件，它会创建一个；如果已经存在，则会追加内容）。如果你想指定输出到其他文件，可以这样：

nohup ./my_data_processor.py > /var/log/data_process.log 2>&1 &

这里

> /var/log/data_process.log

是将标准输出重定向到指定文件，

2>&1

则是将标准错误也重定向到标准输出（即同一个文件）。这对于长时间运行的服务或批处理任务来说，是我的首选之一。

使用

screen

或

tmux

进行会话管理

对我来说，

screen

或

tmux

才是真正的后台运行利器，它们提供的不仅仅是简单的后台执行，更是一种持久化的会话管理。它们允许你创建一个虚拟终端会话，然后在这个会话中运行命令。你可以随时“分离”（detach）这个会话，让它在后台继续运行，然后关闭你的SSH连接。当你需要的时候，可以再次“附着”（attach）到这个会话，就好像你从未离开过一样。

• screen
  • 启动一个新的

    screen

    会话：

    screen
  • 在会话中运行你的命令。
  • 分离会话（不终止）：

    Ctrl+a d
  • 查看所有

    screen

    会话：

    screen -ls
  • 重新附着到会话：

    screen -r [session_id]

• tmux
  • 启动一个新的

    tmux

    会话：

    tmux
  • 在会话中运行你的命令。
  • 分离会话：

    Ctrl+b d
  • 查看所有

    tmux

    会话：

    tmux ls
  • 重新附着到会话：

    tmux attach -t [session_name_or_id]

我个人更偏爱

tmux

，因为它在分屏、窗口管理方面更加灵活强大。这种方式是运行长期服务、开发环境或需要频繁断开重连的远程工作的最佳选择，因为它提供了完整的交互式环境。

disown

命令脱离父进程

如果你已经用

&

把一个命令扔到后台，但后来又想让它脱离当前shell的控制，防止SIGHUP信号影响，

disown

命令就派上用场了。它能将一个在后台运行的作业从shell的作业列表中移除。

my_command_that_is_now_running_in_background & jobs # 查看作业列表，找到作业ID，例如[1] disown -h %1 # 或者使用PID：disown -h PID

disown -h

表示不发送SIGHUP信号。这样操作后，即使你关闭终端，该进程也不会收到SIGHUP信号而终止，它会变成一个孤儿进程，通常会被

init

进程（或

systemd

）收养。这个方法在某些特定情况下非常实用，比如你忘记用

nohup

启动，但又不想中断当前任务。

为什么我们需要将命令放入后台运行？

将命令放入后台运行，这绝不仅仅是为了让终端看起来干净，它背后承载着实实在在的工作效率提升和系统稳定性考量。从我的经验来看，主要有几个非常实际的理由。

首先，解决长时间任务阻塞终端的问题。想象一下，你在远程服务器上运行一个需要几小时甚至几天才能完成的数据分析脚本，或者编译一个大型项目。如果它在前台运行，你的终端就会被这个任务完全霸占，你无法执行其他命令，也无法关闭终端。这显然是不可接受的。将其放入后台，你就可以继续处理其他工作，比如查看日志、编辑文件、运行其他诊断工具。

其次，保持服务持续运行。很多时候，我们需要在服务器上启动一些服务，比如Web服务器、数据库进程、消息队列消费者等。这些服务需要不间断地运行，以响应请求或处理数据。如果它们依赖于某个特定的终端会话，一旦会话断开（比如SSH连接断开），服务就会随之终止，这显然会造成业务中断。后台运行机制，特别是结合

nohup

或

screen

/

tmux

，就是为了确保这些关键服务能够独立于用户会话而稳定运行。

再者，提升远程操作的灵活性和稳定性。对于经常通过SSH连接到远程服务器进行操作的工程师来说，网络连接的不稳定是常态。一次临时的网络波动就可能导致SSH连接断开，进而终止所有在前台运行的任务。将任务放入后台，特别是使用

screen

或

tmux

，可以有效抵御这种风险。即使连接断开，你的工作会话依然存在于服务器上，你只需要重新连接并附着到会话即可，工作进度丝毫不受影响。这就像给你的远程工作加上了一层“保险”，让我可以更安心地进行远程开发和维护。

最后，资源管理和任务优先级。虽然这不是后台运行的直接目的，但它也间接促成了更合理的资源分配。将一些非交互式、CPU密集型或I/O密集型任务放入后台，并可能通过

nice

或

ionice

调整其优先级，可以避免它们过度抢占前台交互式任务的资源，从而保持系统的响应性。

nohup

与

&

符号：它们之间有什么区别和适用场景？

nohup

和

&

符号虽然都能够让命令在后台运行，但它们在行为和目的上存在显著差异，理解这些差异对于选择正确的工具至关重要。我经常看到有人混淆这两者，导致任务意外终止。

ChatGPT Writer

免费 Chrome 扩展程序，使用 ChatGPT ai 生成电子邮件和消息。

34

查看详情

&

符号

• 行为：将命令立即放入当前shell的作业（jobs）列表中，并在后台执行。它返回一个PID，并允许你继续在当前终端输入其他命令。
• 与终端的关联：它依然与你的当前终端会话紧密关联。当终端关闭（或者收到SIGHUP信号）时，这个后台进程通常也会收到SIGHUP信号并随之终止。可以把它想象成一个在后台跑的“子进程”，但它仍然依附于“父进程”（你的shell）。
• 输出：命令的标准输出和标准错误仍然会打印到当前终端，除非你手动重定向它们。这有时会干扰你的终端显示。
• 适用场景：
  • 短期、非关键的后台任务，例如在编译代码时，临时在后台运行一个

    grep

    命令搜索日志。

  • 在

    screen

    或

    tmux

    会话内部，因为

    screen

    /

    tmux

    本身就提供了会话持久性，所以

    &

    在这里使用是安全的，它不会因为你的SSH断开而终止。

  • 当你只是想暂时不阻塞当前终端，但并不介意任务随着终端关闭而终止时。

nohup

命令

• 行为：

  nohup

  是一个独立的命令，它修改了其后跟随的命令的行为，使其忽略SIGHUP信号。通常，我们会结合

  &

  符号一起使用，以达到在后台运行且不受终端关闭影响的目的。

• 与终端的关联：

  nohup

  的主要作用就是切断命令与终端的SIGHUP信号关联。这意味着即使你的终端会话关闭，

  nohup

  启动的进程也不会因为SIGHUP信号而终止，它会继续在后台运行，成为一个独立的进程。

• 输出：

  nohup

  会自动将其所执行命令的标准输出和标准错误重定向到

  nohup.out

  文件（如果未指定其他文件）。这避免了后台任务的输出污染你的终端。

• 适用场景：
  • 需要长时间运行的服务或脚本，例如启动一个Web服务器、一个后台数据处理脚本、一个消息队列消费者等。
  • 当你通过SSH连接到远程服务器，需要启动一个任务，并且希望在断开SSH连接后任务依然能够持续运行时。
  • 任何你希望它“不死”的后台任务。

核心区别：

&

只是将任务放入后台，但它仍然是当前shell的子进程，受SIGHUP信号影响；而

nohup

则是改变了任务对SIGHUP信号的响应方式，使其忽略该信号，从而在终端关闭后依然存活。简单来说，

&

是“后台运行”，

nohup

是“断开连接后仍运行”。

如何有效地管理和监控后台运行的进程？

仅仅将命令扔到后台是不够的，你还需要知道如何有效地管理和监控它们，确保它们正常运行，并在需要时进行干预。这就像你启动了一批无人机，总得有个控制中心来查看它们的飞行状态。

1. 查看当前Shell的后台作业：

jobs

如果你只是用

&

符号将命令放入后台，它们会成为当前shell的“作业”（jobs）。你可以使用

jobs

命令来查看这些作业的状态：

jobs -l

-l

选项会显示PID。你会看到类似

[1]+ Running ./my_script.sh &

的输出，

[1]

是作业ID，

Running

是状态。

• fg %job_id

  ：将指定作业ID的后台任务拉回到前台运行。

• bg %job_id

  ：如果你暂停了一个前台任务（

  Ctrl+z

  ），可以使用

  bg

  将其放到后台继续运行。

• kill %job_id

  ：终止指定作业ID的后台任务。

2. 查找所有进程：

ps

grep

对于那些通过

nohup

启动，或者脱离了当前shell控制的进程，

jobs

命令就看不到了。这时，你需要使用

ps

命令结合

grep

来查找：

ps aux | grep "my_script.sh"

这会列出所有用户（

a

）、所有终端（

x

）上的进程，并显示详细信息（

u

），然后通过管道

|

将结果传递给

grep

，过滤出包含

my_script.sh

的行。你会看到进程的PID、CPU和内存占用等信息。找到对应的PID后，就可以进行下一步操作。

3. 终止进程：

kill

当你找到一个进程的PID后，可以使用

kill

命令来终止它：

kill PID

• kill PID

  （默认发送SIGTERM信号，要求进程优雅退出）

• kill -9 PID

  （发送SIGKILL信号，强制终止进程，慎用，因为它不会给进程清理资源的机会）

4. 管理

screen

tmux

会话

如果你主要依赖

screen

或

tmux

，管理它们的方式有所不同：

• screen -ls

  /

  tmux ls

  ：列出所有正在运行的

  screen

  或

  tmux

  会话。这会显示会话ID或名称。

• screen -r [session_id]

  /

  tmux attach -t [session_name_or_id]

  ：重新连接到指定的会话。

• screen -X -S [session_id] quit

  /

  tmux kill-session -t [session_name_or_id]

  ：终止一个会话。

通过这些命令，你可以随时检查你的后台任务是否还在运行，它们的资源占用情况，并在需要时进行干预。我发现，对于长期运行的关键服务，定期检查

nohup.out

或其他日志文件，并结合

ps aux

来监控进程状态，是确保系统健康的关键习惯。当然，更高级的监控系统（如Prometheus, Nagios）会提供更全面的解决方案，但这些基础命令是日常运维不可或缺的。