Linux后台运行进程的常用技巧-linux运维-PHP中文网

答案是使用&amp;amp;amp;amp;amp;、nohup、screen/tmux和systemd四种方法。首先&amp;amp;amp;amp;amp;符号可将程序放入后台运行，但终端关闭时进程会终止；其次nohup命令能忽略SIGHUP信号，确保进程在终端关闭后继续运行，并重定向输出到文件；接着screen或tmux提供虚拟终端会话，支持分离与重新连接，适合需要交互的长期任务；最后systemd通过.service文件管理开机自启、自动重启和日志记录，适用于生产环境服务的系统级管理。

linux后台运行进程的常用技巧

在Linux系统里，让程序在后台持续运行，不被终端关闭影响，是日常工作里一个很基础但又特别重要的技能。简单来说，我们主要通过几种方式来实现：最直接的是使用

&amp;amp;amp;amp;amp;amp;

登录后复制

符号让命令在后台执行；更可靠一点，可以用

nohup

登录后复制

命令来防止进程因终端关闭而终止；而对于需要更复杂会话管理或者长期运行的服务，

screen

登录后复制

或

tmux

登录后复制

提供了强大的虚拟终端功能，而

systemd

登录后复制

则是现代Linux系统管理后台服务的标准。

解决方案

我在日常工作中，处理后台进程的需求场景通常有这么几种：偶尔跑个脚本，不希望它霸占我的终端；需要长时间运行一个程序，即使我断开SSH连接它也要继续；或者，干脆就是把一个应用部署成一个服务，让系统开机自启并自动管理。针对这些不同场景，我的选择也不同。

1. 临时后台运行：

&amp;amp;amp;amp;amp;amp;

登录后复制

符号

这是最简单粗暴的方式。当你执行一个命令时，在末尾加上一个

&amp;amp;amp;amp;amp;amp;

登录后复制

，它就会立即在后台运行，并将控制权返回给你的终端。

./my_script.sh &amp;amp;amp;amp;amp;amp;amp;

登录后复制

这种方式的优点是快捷，适合那些你确定很快会完成，或者即使中断了也没关系的任务。但它有个致命缺点：这个进程仍然是当前终端会话的子进程。一旦你关闭终端，或者SSH连接断开，这个进程通常会收到SIGHUP信号（挂断信号），然后随之终止。我刚开始接触Linux的时候，就吃过这个亏，以为加个

&amp;amp;amp;amp;amp;amp;

登录后复制

就万事大吉了，结果第二天回来一看，程序早没了。

2. 防止终端关闭：

nohup

登录后复制

命令

为了解决

&amp;amp;amp;amp;amp;amp;

登录后复制

的“短命”问题，

nohup

登录后复制

就派上用场了。

nohup

登录后复制

的全称是"no hang up"，它的作用是让命令忽略SIGHUP信号。这意味着即使你关闭终端，进程也不会因为收到挂断信号而停止。同时，

nohup

登录后复制

还会将标准输出和标准错误重定向到一个文件（默认为

nohup.out

登录后复制

），避免它们直接输出到终端。

nohup ./my_long_running_process.py > output.log 2>&amp;amp;amp;amp;amp;amp;1 &amp;amp;amp;amp;amp;amp;

登录后复制

这里，

> output.log

登录后复制

是将标准输出重定向到

output.log

登录后复制

文件，

2>&amp;amp;amp;amp;amp;amp;1

登录后复制

则是将标准错误也重定向到标准输出（也就是

output.log

登录后复制

）。最后的

&amp;amp;amp;amp;amp;amp;

登录后复制

当然是让

nohup

登录后复制

命令本身在后台运行。这是我处理那些需要长时间跑但又不想用

screen

登录后复制

或

systemd

登录后复制

来管理的任务时，最常用的组合。比如，跑个数据导入脚本，或者训练一个小型模型。

3. 会话管理与进程持久化：

screen

登录后复制

或
tmux
登录后复制

当我的需求是“我需要在一个虚拟终端里运行多个命令，并且随时可以断开连接，下次再连上来继续操作”时，

screen

登录后复制

或

tmux

登录后复制

就是不二之选。它们创建了一个持久化的虚拟终端会话，你可以把程序跑在这些会话里，然后“分离”会话（detach），即使你关闭了SSH连接，会话和里面的程序依然在服务器上运行。下次你再连接上来时，可以“附加”回之前的会话（attach），继续操作。

# screen
screen -S my_session  # 创建一个名为my_session的会话
# 在新会话中执行你的命令，例如：
# python my_app.py
# 按 Ctrl+A D 分离会话

screen -ls           # 查看所有会话
screen -r my_session # 重新附加到my_session

# tmux
tmux new -s my_session # 创建一个名为my_session的会话
# 在新会话中执行你的命令
# 按 Ctrl+B D 分离会话

tmux ls              # 查看所有会话
tmux attach -t my_session # 重新附加到my_session

登录后复制

我个人更偏爱

tmux

登录后复制

，因为它在分屏和窗口管理上更灵活，学习曲线可能稍微陡峭一点，但一旦掌握，效率提升非常明显。我常常用它来管理多个开发或部署任务，一个会话里开好几个窗口，每个窗口跑一个服务，方便来回切换和查看日志。

4. 系统级服务管理：

systemd

登录后复制

对于那些需要开机自启、持续运行、并且需要系统级别管理（例如自动重启、资源限制等）的应用程序，

systemd

登录后复制

是现代Linux发行版（如CentOS 7+, Ubuntu 16.04+）的首选。它通过服务单元（

.service

登录后复制

文件）来定义和管理后台进程。这适用于Web服务器、数据库、消息队列等生产环境中的核心应用。

你需要创建一个

.service

登录后复制

文件，通常放在

/etc/systemd/system/

登录后复制

目录下。

# /etc/systemd/system/my_app.service
[Unit]
Description=My Custom Application Service
After=network.target

[Service]
User=your_user
WorkingDirectory=/path/to/your/app
ExecStart=/usr/bin/python3 /path/to/your/app/main.py
Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

登录后复制

然后，通过

systemctl

登录后复制

命令来管理它：

sudo systemctl enable my_app.service  # 设置开机自启
sudo systemctl start my_app.service   # 启动服务
sudo systemctl status my_app.service  # 查看服务状态
sudo systemctl stop my_app.service    # 停止服务
sudo systemctl restart my_app.service # 重启服务

登录后复制

我发现，一旦一个应用需要长期稳定运行，并且可能需要团队其他成员维护时，把它做成

systemd

登录后复制

服务是最好的选择。它提供了统一的管理接口，日志也能集中管理，排查问题方便得多。

为什么我的后台进程会意外终止？

这个问题几乎是每个初学者都会遇到的“坑”。你明明把一个程序扔到后台跑了，结果过了一段时间回来一看，它却悄无声息地挂掉了。这背后主要有几个原因，而理解它们对于我们选择正确的后台运行策略至关重要。

最常见的原因是SIGHUP信号。当你的终端会话结束（比如你关闭了SSH客户端，或者直接关闭了终端窗口），操作系统会向该会话下的所有子进程发送一个SIGHUP（Hang Up）信号。默认情况下，收到SIGHUP信号的进程会终止。这就是为什么你用

&amp;amp;amp;amp;amp;amp;

登录后复制

符号把一个程序扔到后台后，一旦你断开连接，它就“死”了。这个设计初衷是好的，为了清理那些不再需要的进程，但对于我们想让程序持续运行的需求来说，就成了障碍。

nohup

登录后复制

命令的核心作用，就是让进程忽略这个SIGHUP信号。

一览运营宝

一览“运营宝”是一款搭载AIGC的视频创作赋能及变现工具，由深耕视频行业18年的一览科技研发推出。

查看详情

另一个不那么常见但同样致命的原因是资源限制或程序自身的错误。你的程序可能因为内存溢出、CPU占用过高被系统杀死（OOM Killer），或者它在运行过程中遇到了未捕获的异常导致崩溃。这跟后台运行的技巧本身关系不大，但却是后台进程意外终止的常见因素。当遇到这种情况时，我通常会去查看程序的日志文件（如果用

nohup

登录后复制

，就是

nohup.out

登录后复制

或你指定的日志文件；如果是

systemd

登录后复制

服务，就是

journalctl -u your_service

登录后复制

），看看有没有错误信息。有时候，程序可能默默地抛出异常，然后退出，但由于你没有捕获这些异常，或者没有将错误输出重定向到日志，就显得它“无故消失”了。

还有一种情况，是父进程的退出。在某些复杂的进程树结构中，如果一个程序的父进程意外终止，那么它的子进程也可能随之被终止，这取决于进程组和会话的机制。不过，对于我们通常的后台运行场景，只要解决了SIGHUP信号的问题，并确保程序自身稳定，这种情况就比较少见了。理解这些“幕后杀手”，能帮助我们更好地选择工具，比如

nohup

登录后复制

就是为了抵御SIGHUP，而

screen

登录后复制

tmux

登录后复制

和

systemd

登录后复制

则提供了更强的会话和进程管理能力，进一步隔离了终端会话的影响。

如何在不关闭终端的情况下安全退出？

这个问题的核心在于，你希望让程序在服务器上继续跑，但你又不想让它霸占你当前的终端窗口，并且你可能还想在未来的某个时候重新“连接”到这个程序的运行环境，查看它的输出或者进行交互。这时候，

screen

登录后复制

和

tmux

登录后复制

就是你的最佳拍档。它们提供了一种“会话持久化”的能力。

当你使用

screen

登录后复制

或

tmux

登录后复制

时，你实际上是连接到了一个在服务器后台运行的虚拟终端会话。你在这个会话里启动你的程序，比如一个长时间运行的数据分析脚本，或者一个需要持续监控的日志工具。然后，你就可以“分离”（detach）这个会话。分离之后，你的SSH连接可以断开，或者你可以关闭当前的终端窗口，但这个虚拟会话以及它里面运行的程序，会继续在服务器上默默地执行。

下次当你需要查看程序的运行状态，或者想继续与它交互时，你只需要重新SSH登录到服务器，然后“附加”（attach）回之前的那个虚拟会话。你会发现一切都保持原样，仿佛你从未离开过。这种感觉就像你把电脑屏幕关掉了，但电脑本身还在运行，等你再打开屏幕，所有窗口和程序都还在那里。

screen

登录后复制

的基本操作：

启动一个新会话：
```
screen -S my_long_task
```
登录后复制
。
```
-S
```
登录后复制
参数给会话起个名字，方便管理。
在会话中运行程序： 正常输入你的命令，例如
```
python my_script.py
```
登录后复制
。
分离会话： 按下
```
Ctrl+A
```
登录后复制
，然后松开，再按下
```
D
```
登录后复制
。你的终端会显示
```
[detached from ...]
```
登录后复制
。
查看现有会话：
```
screen -ls
```
登录后复制
。
重新连接会话：
```
screen -r my_long_task
```
登录后复制
(如果会话只有一个，也可以直接用
```
screen -r
```
登录后复制
)。
强制杀死会话：
```
screen -X -S my_long_task quit
```
登录后复制
。

tmux

登录后复制

的基本操作：

启动一个新会话：
```
tmux new -s my_long_task
```
登录后复制
。
在会话中运行程序： 正常输入你的命令。
分离会话： 按下
```
Ctrl+B
```
登录后复制
，然后松开，再按下
```
D
```
登录后复制
。你的终端会显示
```
[detached (from session ...)]
```
登录后复制
。
查看现有会话：
```
tmux ls
```
登录后复制
。
重新连接会话：
```
tmux attach -t my_long_task
```
登录后复制
。
杀死会话：
```
tmux kill-session -t my_long_task
```
登录后复制
。

我个人在使用这些工具时，会习惯性地给每个重要的任务创建一个独立的会话，并起一个有意义的名字。这样，即使服务器上跑着好几个后台任务，我也能清晰地知道哪个会话对应哪个任务，管理起来井井有条。它们极大地提升了我在远程服务器上工作的效率和舒适度，避免了因为网络不稳定或者不小心关闭终端而导致工作中断的烦恼。

长期运行的服务如何实现自动化管理？

对于那些需要长期稳定运行，甚至要求系统开机自启，并且能够被系统统一监控和管理的应用程序，仅仅依靠

nohup

登录后复制

或者

screen

登录后复制

tmux

登录后复制

就不够了。这些场景下，我们需要的是一个更健壮、更系统化的解决方案，而

systemd

登录后复制

就是现代Linux发行版（如CentOS 7+, Ubuntu 16.04+, Debian 8+）提供的标准答案。

systemd

登录后复制

通过“单元”（unit）的概念来管理系统资源，其中最常用的是“服务单元”（

.service

登录后复制

文件）。你可以为你的应用程序创建一个

.service

登录后复制

文件，详细定义它的启动方式、运行时用户、工作目录、依赖关系、重启策略以及日志输出等。这样一来，你的应用程序就从一个普通的后台进程，升级成为了一个由操作系统统一管理的服务。

为什么选择

systemd

登录后复制

？

开机自启： 最核心的需求之一。通过
```
systemctl enable
```
登录后复制
命令，你可以让你的服务在系统启动时自动运行，无需手动干预。
可靠性与容错：
```
systemd
```
登录后复制
可以配置服务的重启策略，例如在服务意外崩溃时自动重启（
```
Restart=always
```
登录后复制
）。这对于确保服务的持续可用性至关重要。
统一管理： 所有的服务都通过
```
systemctl
```
登录后复制
命令进行管理，包括启动、停止、重启、查看状态和日志。这提供了一个标准化的接口，无论是你自己还是团队成员，都能轻松上手。
资源隔离与安全性： 你可以指定服务运行的用户和组（
```
User=
```
登录后复制
,
```
Group=
```
登录后复制
），限制其文件系统访问权限，甚至通过
```
systemd
```
登录后复制
的沙箱功能进一步增强安全性。
日志管理： 服务的标准输出和标准错误会被
```
systemd
```
登录后复制
的日志系统（journald）捕获。你可以通过
```
journalctl -u your_service_name
```
登录后复制
命令方便地查看服务的实时日志和历史日志，这对于故障排查非常有帮助。

创建一个

systemd

登录后复制

服务单元的步骤：

编写
```
.service
```
登录后复制
文件： 在
```
/etc/systemd/system/
```
登录后复制
目录下创建一个文件，例如
```
my_web_app.service
```
登录后复制
。文件的内容通常分为几个部分：
- ```
[Unit]
```
  登录后复制
  ：定义服务的描述、启动顺序和依赖关系。例如，
```
After=network.target
```
  登录后复制
  表示服务在网络就绪后启动。
- ```
[Service]
```
  登录后复制
  ：核心部分，定义如何启动、停止服务，以及运行时的行为。
  - ```
  User=your_user
```
  登录后复制
  ：指定运行服务的用户。
- ```
WorkingDirectory=/path/to/your/app
```
    登录后复制
    ：指定服务的工作目录。
  - ```
  ExecStart=/usr/bin/python3 /path/to/your/app/main.py
```
  登录后复制
  ：指定启动服务的命令。
- ```
Restart=always
```
    登录后复制
    ：服务退出时总是重启。
  - ```
  RestartSec=3
```
  登录后复制
  ：重启前等待3秒。
- ```
StandardOutput=journal
```
    登录后复制
    ：标准输出重定向到journald。
  - ```
  StandardError=journal
```
  登录后复制
  ：标准错误重定向到journald。
- ```
[Install]
```
  登录后复制
  ：定义服务如何被
```
systemctl enable
```
  登录后复制
  命令启用。
```
WantedBy=multi-user.target
```
  登录后复制
  表示在多用户模式下启动。
重新加载
```
systemd
```
登录后复制
配置：
```
sudo systemctl daemon-reload
```
登录后复制
。当你修改或添加了
```
.service
```
登录后复制
文件后，需要执行此命令让
```
systemd
```
登录后复制
重新读取配置。
启用并启动服务：
- ```
sudo systemctl enable my_web_app.service
```
  登录后复制
  ：设置服务开机自启。
- ```
sudo systemctl start my_web_app.service
```
  登录后复制
  ：立即启动服务。
查看服务状态和日志：
- ```
sudo systemctl status my_web_app.service
```
  登录后复制
  ：查看服务当前运行状态。
- ```
sudo journalctl -u my_web_app.service -f
```
  登录后复制
  ：实时查看服务的日志。