如何在Linux中后台运行程序 Linux nohup与&符号区别解析

答案是：在Linux中，使用nohup command &可让程序忽略终端关闭信号并在后台运行，结合输出重定向能避免nohup.out文件膨胀，而jobs、ps和kill命令用于管理后台进程，对于需交互的长期任务，推荐使用screen或tmux实现会话重连与多窗口管理。

在Linux环境下，当我们希望一个程序在关闭终端后依然能继续运行，或者仅仅是想让它在后台默默工作而不阻塞当前会话时，通常会用到两种主要的机制：

符号和 命令。简单来说， 符号能让程序立即在后台运行，而 则确保程序在终端退出（SIGHUP信号）后不会被终止。两者结合使用，即 ，是实现真正“不挂断”后台运行的经典组合。

解决方案

在我看来，理解

和的工作原理，远比死记硬背它们的用法要重要得多。符号，当你把它放在一个命令的末尾，它告诉shell：“嘿，这个命令你给我丢到后台去跑，别占用我的命令行了。” 这么一来，你就可以立即输入其他命令，继续你的工作。但这里有个坑，这个程序虽然在后台跑了，它依然是当前shell的一个子进程，而且它对终端发出的信号，尤其是SIGHUP（挂断信号）是敏感的。也就是说，如果你关掉终端，或者网络断开导致SSH会话中断，这个后台程序很可能也就跟着“殉职”了。

这就是

命令登场的时候了。，全称是“no hang up”，它的核心作用就是让命令忽略SIGHUP信号。当你用执行一个程序时，即使终端关闭，这个程序也不会因为收到SIGHUP信号而终止。默认情况下，还会将程序的标准输出和标准错误重定向到一个名为的文件中，这样你就能在之后查看程序的输出信息了。

所以，如果你想要一个程序既在后台运行，又不怕终端关闭，那么最稳妥、也是我最常用的方式就是将两者结合起来：

这条命令的含义是：

1. nohup your_command_here

   登录后复制
   : 让

   your_command_here

   登录后复制
   忽略SIGHUP信号。

2. > output.log

   登录后复制
   : 将标准输出重定向到

   output.log

   登录后复制
   文件。

3. 2>&1

   登录后复制
   : 将标准错误也重定向到标准输出（也就是

   output.log

   登录后复制
   ）。

4. &

   登录后复制
   : 将整个

   nohup

   登录后复制
   命令放到后台执行。

这样一来，你的程序就能在后台安安稳稳地跑着，即便你下班关机了，它也还在服务器上辛勤工作。

Linux后台进程管理：如何查看、终止和恢复？

一旦你把程序扔到后台，自然会想知道它们过得怎么样，或者需要的时候怎么“管教”它们。这就像你把孩子送去幼儿园，总得知道怎么探视和接回家吧。

首先，对于通过

符号启动的后台作业，你可以使用命令。它会列出当前shell会话中所有在后台运行的作业，并给它们分配一个作业号（job ID）。比如，你可能会看到类似这样的输出：

这里的

和就是作业号。如果你想把某个后台作业重新拉回前台继续交互，可以使用，比如。反过来，如果一个程序当前在前台运行，你想把它暂停并放到后台，可以先按暂停它，然后用（通常是，因为它是最近暂停的作业）让它在后台继续运行。

然而，

命令的局限性在于，它只显示当前shell会话的作业。如果你关闭了终端，或者程序是通过启动的，就无能为力了。这时候，我们就需要请出更强大的工具：命令。能列出系统上所有正在运行的进程。通常我会结合来查找我关心的程序：

这会显示包含

关键词的进程信息，其中最关键的就是PID（进程ID）。有了PID，你就可以通过命令来终止它了：

如果一个进程顽固不化，不响应

命令（默认发送SIGTERM信号），你可能需要更强制的手段，比如发送SIGKILL信号：

但请注意，

是强制终止，程序没有机会做清理工作，所以通常是最后手段。

nohup.out文件膨胀问题及日志重定向策略

使用

时，一个非常常见的“陷阱”就是文件。默认情况下，会将程序的所有标准输出和标准错误都重定向到当前目录下的文件。如果你的程序是个“话痨”，或者运行时间很长，这个文件会迅速膨胀，占用大量磁盘空间，甚至可能把磁盘撑爆，导致系统出现各种奇怪的问题。我见过不少服务器因此而“宕机”的案例，真的是血的教训。

解决这个问题的方法其实很简单，就是明确地将输出重定向到你指定的位置，或者干脆丢弃掉。

如果你根本不关心程序的输出，或者程序本身会将日志写入到特定文件，那么最直接的做法就是将标准输出和标准错误都重定向到

这个“黑洞”：

这样，程序的所有输出都会被丢弃，

文件就不会产生了。

但更多时候，我们是需要程序的日志的，只是不希望它们都挤在

里。这时，你可以将输出重定向到你指定的日志文件，并最好加上时间戳或者其他标识，方便管理和回溯：

这样，每天的日志都会写入到一个新的文件中，方便你进行日志轮转和管理。当然，你也可以结合

工具来自动化日志文件的压缩、归档和删除，避免日志文件无限增长。

何时选择screen或tmux而非简单的nohup &？

虽然

组合拳在大多数后台运行的场景下表现出色，但它并非万能。它最大的局限在于，一旦程序进入后台，你就无法再与它进行交互了。你不能查看实时输出，也不能发送键盘输入。这对于那些需要长时间运行、但又偶尔需要人工干预或者查看实时状态的程序来说，就显得捉襟见肘了。

这时候，

或这类终端多路复用器（terminal multiplexer）就显得尤为强大。它们的工作原理是创建一个虚拟的、可分离的终端会话。你可以启动一个或会话，在这个会话里运行你的程序，然后随时“分离”（detach）这个会话，即使关闭了当前的SSH连接，会话里的程序也会继续运行。当你需要的时候，可以再次“连接”（attach）到这个会话，就像从未离开过一样。

举个例子，如果你正在服务器上编译一个大型项目，或者运行一个需要你偶尔输入指令的Python脚本，又或者你想在同一个SSH连接下同时管理多个独立的终端窗口，

或就是你的不二之选。它们不仅能保证程序的持续运行，还能提供：

• 会话分离与重连： 这是它们最核心的功能，解决了

  nohup &

  登录后复制
  无法重新连接到后台进程的痛点。
• 多窗口/面板： 在一个会话中创建多个独立的终端窗口或面板，方便同时处理多个任务。
• 会话共享： 允许多个用户同时连接到同一个会话，非常适合团队协作或远程教学。

它们的学习曲线可能比简单的

要陡峭一些，但一旦掌握，你会发现它们在远程工作和服务器管理中的效率提升是巨大的。对我个人而言，无论是部署服务、调试代码，还是进行长时间的数据处理，几乎是我每次登录服务器的第一个命令，它给我带来的便利性是无法比拟的。选择哪一个，取决于你对交互性的需求和对复杂性的接受程度。对于简单的、无需交互的后台任务，足够了；但对于更复杂、需要管理和交互的场景，或才是真正的利器。

以上就是如何在Linux中后台运行程序 Linux nohup与&符号区别解析的详细内容，更多请关注php中文网其它相关文章！