使用nohup命令结合&符号可在linux中让进程在后台持续运行，即使关闭终端也不会中断。nohup用于忽略sighup信号，防止进程随终端关闭而终止，&则将命令放入后台执行，默认输出重定向至nohup.out文件。可通过重定向输出到指定文件或/dev/null避免日志过大。此外，screen、tmux、disown及systemd等工具也适用于不同场景的后台任务管理，而ps、kill等命令可用于查看和控制后台进程。
要在Linux系统里让一个命令在后台跑起来，并且在你关掉终端或者登出后它还能继续运行不中断，最常用的办法就是结合使用
nohup命令和
&符号。
解决方案
这事儿其实挺常见的，比如你要跑个耗时很长的脚本，或者启动一个服务，但又不想一直开着终端。
nohup的作用，简单来说，就是“不挂断”，它会阻止 SIGHUP 信号发送给你的进程。SIGHUP 信号通常在终端关闭时发送给所有子进程，导致它们跟着一块儿挂掉。而
&符号则是把命令放到后台去执行，这样你就能立即拿到终端的控制权，继续做其他事情。
所以，基本用法就是这样：
nohup your_command [arguments] &
举个例子，如果你想在后台运行一个Python脚本：
nohup python your_script.py &
执行后，你会看到类似这样的提示：
[1] 12345，这表示你的命令已经作为一个后台作业（job）启动，
12345是它的进程ID（PID）。同时，
nohup默认会将命令的所有输出重定向到一个叫做
nohup.out的文件里，这个文件会在当前目录下生成。如果你不希望有这个文件，或者想把输出放到其他地方，可以这样：
nohup your_command > /dev/null 2>&1 &这里
> /dev/null是把标准输出丢弃掉，
2>&1则是把标准错误也重定向到标准输出，这样就彻底安静了。
我个人在使用的时候，经常会遇到一个场景，就是忘记重定向输出，结果
nohup.out文件变得巨大无比，占满磁盘空间，所以养成重定向输出的习惯很重要。或者，你可以明确指定输出文件：
nohup your_command > my_log.log 2>&1 &这样日志就都在
my_log.log里了，方便后续查看。
为什么我在终端关闭后，后台进程会停止？
这背后其实是Linux进程管理的一些机制在起作用。当你通过SSH连接到一个服务器，或者打开一个本地终端时，实际上是创建了一个“会话”（session）。在这个会话里，你启动的每一个命令，都是这个会话的子进程。当这个会话，也就是你的终端，被关闭时，系统会给会话中的所有进程发送一个 SIGHUP（Hangup）信号。这个信号的默认行为就是让接收到的进程终止。
所以，你可能觉得已经用
&把命令放到后台了，但它仍然是当前会话的子进程，一旦会话结束，SIGHUP 信号一发，它就“挂”了。
nohup的核心作用，就是让你的命令对这个 SIGHUP 信号“免疫”，它会忽略这个信号，这样即使终端关了，会话断了，你的进程也依然能继续运行，就像它从一开始就跟你的终端没关系一样。这就像给你的进程穿了一件“防弹衣”，让它不受会话关闭的影响。
我曾经就遇到过一个情况，跑一个数据分析脚本，想着反正加了
&就能后台跑了，结果第二天一看，脚本根本没跑完，这才想起来是SIGHUP信号捣的鬼。所以，理解这个原理，对于正确使用后台命令至关重要。
除了nohup，还有哪些方法可以有效地管理Linux后台任务？
当然，
nohup只是其中一种简单直接的方法，尤其适合那些你启动后就不太需要交互的单次任务。但如果你的任务需要长时间运行，并且你可能需要随时“回来”查看它的输出、甚至进行交互，那么
screen或
tmux这样的终端复用工具会是更好的选择。
screen
/tmux
: 这两个工具可以创建一个“虚拟终端会话”，你可以把你的命令在这个虚拟会话里运行，然后随时“分离”（detach）这个会话，即使你关闭了当前的SSH连接，虚拟会话里的程序也依然在运行。当你下次登录时，可以再“连接”（attach）回这个会话，就像你从未离开过一样。它们功能非常强大，支持多窗口、分屏等，对于需要频繁交互或监控的长时间任务来说，简直是神器。我个人更偏爱tmux
，因为它在配置和使用上感觉更现代化一些，但screen
也是非常成熟和可靠的选择。disown
: 这是一个shell内置命令，它能将一个在后台运行的作业（job）从当前shell的作业列表里移除。一旦disown
掉，即使你关闭终端，这个进程也不会收到SIGHUP信号而终止。它的用法通常是在你已经用&
启动了一个命令之后，再执行disown -h PID
或disown -h %job_number
。这和nohup
的效果类似，但disown
是在命令启动后才操作，而nohup
是在命令启动前就设置好。systemd
/init.d
: 如果你的任务是一个需要开机自启动、长时间运行、并且需要稳定可靠的服务（比如一个Web服务器、数据库），那么把它配置成一个系统服务是最佳实践。在现代Linux系统中，这意味着编写一个systemd
unit 文件。虽然这比nohup
复杂得多，但它提供了更强大的生命周期管理、日志记录、依赖关系处理等功能，是生产环境的首选。
这些工具各有侧重，选择哪一个取决于你的具体需求和任务的性质。对于快速、临时的后台任务，
nohup依然是简单高效的。
如何查看和管理那些使用nohup启动的后台进程？
当你用
nohup启动了一个进程，它就变成了一个独立的后台进程，不再直接受你的终端控制。但你仍然可以通过一些标准的Linux命令来查看和管理它们。
首先，要找到你的进程，最常用的就是
ps命令配合
grep：
ps aux | grep your_command_name或者，如果你知道
nohup.out文件是在哪个目录下生成的，你甚至可以
grep这个文件名来定位：
ps aux | grep nohup.out
ps aux会列出所有用户的进程，
a表示所有终端上的进程，
u表示显示用户和启动时间，
x表示显示没有控制终端的进程。通过
grep过滤，你就能找到你的目标进程，并获取它的PID（进程ID）。
比如，你可能看到类似这样的一行：
user 12345 0.0 0.1 123456 4567 ? Sl 10:00 0:01 python your_script.py这里的
12345就是PID。
有了PID，你就可以对它进行管理了：
-
终止进程:
kill 12345
(发送TERM信号，允许进程优雅退出) -
强制终止进程:
kill -9 12345
(发送KILL信号，强制终止，不给进程清理的机会，慎用)
如果你的
your_command_name比较独特，也可以用
pkill或
killall：
pkill your_command_name
killall your_command_name这两个命令会根据进程名来杀死所有匹配的进程，所以要确保你的进程名是唯一的，以免误杀。
至于
nohup.out文件，它通常会在你执行
nohup命令的那个目录下生成。你可以用
tail -f nohup.out来实时查看进程的输出，这在调试或者监控长时间运行的任务时非常有用。如果文件变得太大，记得定期清理或者轮转（logrotate）。我见过好几次因为
nohup.out塞满硬盘导致系统出问题的案例，所以对这些日志文件保持关注是很重要的。
