Nicholas Qin1. 为什么一关终端程序就死：前台进程与终端会话的本质
先问一个很基础但值得想清楚的问题：你在服务器上跑了一个数据同步脚本，或者启动了一个 Web 服务，然后本地的 SSH 窗口一关，或者笔记本合上盖子，下一秒远程过去看，任务没了。这种情况干过运维和开发的应该都遇到过至少一次。
很多人第一反应是"我明明用 & 放到后台了，怎么还是断了？"——这时如果你只学了 command & 这个形式而没有理解它背后的机制，就会一直被这类问题坑。
要搞明白后台命令到底怎么回事，得先理解一个非常简单但又特别核心的概念：进程和它的"控制终端"之间的关系。
1.1 前台进程直接绑在终端上
你在终端里敲一条命令，比如 python train.py，这条命令是前台进程。它占据着这个终端，你怎么敲其他命令它都不响应，因为 shell 在等待这个进程结束。
前台进程和当前终端不是"松散的绑定"，而是存在一条会话关系：进程属于某个会话，会话关联着一个控制终端。当你关闭终端窗口或者 SSH 连接断开时，内核会向这个会话的前台进程组发送挂断信号，也就是 SIGHUP。这个信号的默认行为就是终止进程。这也是为什么你关掉窗口，程序就跟着死掉的直接原因。
可以把这个过程类比成：你和同事在一个共享办公室里对接工作，你走了，还把办公室门锁了，同事还在屋里干活——但屋里的对讲机（终端）是唯一沟通渠道，你一走，这跟对讲机的连线就断了，对方也不知道你是否还需要他继续干活，所以也就停了。
1.2 & 只是把任务挪到了"后台作业"列表里
command & 的用途是让命令在 shell 的后台作业里运行，从而解放当前终端，让你能继续输入其他命令。但这里有个关键点：它没有脱离终端会话。
拿 Ubuntu/CentOS 默认的 bash 来说，执行：
bash复制sleep 300 &
输出通常是这样：
text复制[1] 12345
[1] 是这个后台作业的编号，12345 是进程 PID。用 jobs 能看到它：
bash复制jobs -l
这个进程仍然是当前 shell 会话的子进程。你退出当前 shell，它会收到 SIGHUP，一样死掉。当然有个特例是 bash 在退出时对于正在运行的后台作业是否发送 SIGHUP，还要看 huponexit 这个 shell 选项是否开启，默认非交互式 shell 通常不开，交互式 shell 也存在不同发行版的差异——但这是细节，最稳妥的理解方式就是：& 不等于守护进程，它不是脱离终端的方案，完全依赖它来保活不可靠。
1.3 会话里的进程组究竟是什么
为了把"关终端导致进程死掉"这件事讲得更透彻，这里引入三个逐步递进的概念：进程组、会话、控制终端。
- 进程组是一组相关进程的集合，shell 中你用管道（
|）串联起来的一串命令，通常会放进同一个进程组。 - 会话是一个或多个进程组的集合，通常对应一次用户登录。
- 控制终端是会话所关联的那个终端设备，用于交互输入输出。
你从本地 ssh user@server 登录远程主机后，SSH 服务端会为你分配一个伪终端，这个伪终端就是你这个会话的控制终端。你在里面启动的任何任务，默认都归属于这个会话。当 SSH 断开、窗口关闭，这个伪终端就结束了。内核清理这个会话的时候，会向前台进程组发送 SIGHUP。
这时如果你有一个守护进程完全脱离了会话、没有控制终端，就不会收到这类信号，自然也就不会因为终端关闭而退出。后台命令的终极目标，其实就是让进程彻底脱离当前会话，成为一个独立存在的任务。
明白这个原理，后面讲的每一种工具和方法，都可以归到一个逻辑上：要么让进程忽略 SIGHUP，要么让进程脱离会话，彻底和终端断绝关系。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. nohup 和 & 的组合：适合临时任务的最简可靠方案
如果只是临时跑一个脚本，不想引入 systemd 服务或者 tmux 这类重量级方案，nohup 加 & 就是最经典、最常见的组合。
bash复制nohup python train.py > train.log 2>&1 &
这条命令应该算是后台运行命令里出场率最高的一句了，但我见过太多人只背命令、不理解每个部分干什么，结果一换场景就出问题。
2.1 nohup 干了什么：忽略 SIGHUP 信号
nohup 名字本身就是 no hangup 的缩写，意思是忽略挂断信号。它用 signal() 或者更现代的 sigaction() 把 SIGHUP 这个信号的默认处理覆盖成忽略，然后执行后面的命令。所以当你关闭终端时，内核发送 SIGHUP，进程收到后选择无视它，继续运行。
注意一个容易忽略的细节：nohup 只是忽略 SIGHUP，不负责处理 SIGINT（Ctrl+C 中断）和 SIGTERM（终止信号）。如果你在启动它的那个终端里按 Ctrl+C，进程大概率还是会收到 SIGINT 并结束。当然，既然用了 nohup 基本都是要脱离交互的，现实场景里不太会再往那个终端里发 Ctrl+C。另外，如果系统要关机或重启，init/systemd 会发 SIGTERM，nohup 也不挡这个，进程还是会退出。
2.2 输出重定向为什么必须写完整
> train.log 2>&1 这部分是把标准输出和标准错误都写进 train.log。如果你只写 nohup command & 没带重定向，nohup 会默认把输出写到当前目录的 nohup.out 文件。这个行为在 GNU coreutils 的 nohup 实现里是写死的。多个任务都用默认方式，日志就会混在一起，排查问题非常痛苦。
另外有个容易踩的小坑：如果当前目录不可写，nohup 会尝试把输出写到 $HOME/nohup.out。但如果 $HOME 也不可写呢？它会直接报错退出。所以显式指定日志路径是必须养成的习惯。
2>&1 的顺序也有讲究，它表示把文件描述符 2（标准错误）重定向到文件描述符 1（标准输出）当前指向的地方。如果你写反了，比如 2>&1 > file，标准错误仍然输出到终端，而不是日志文件里，排查问题的时候会一头雾水——日志文件里看不到报错，报错全打到终端上了。
2.3 一个容易忽略的点：nohup 与后台符号的顺序
正确的写法是 nohup 命令 &，也就是 nohup 修饰命令整体，然后由 shell 把这个 nohup 进程放到后台。
如果你写成：
bash复制nohup python train.py &
那 shell 做的流程是 fork 出一个子进程，这个子进程执行 nohup python train.py，nohup 再进一步忽略 SIGHUP 后 exec 成 python train.py。最终 python 进程收到 SIGHUP 时是无视状态。
如果你把 & 放在整个 nohup 前面，比如直接敲命令时不加 nohup 而只是 python train.py &，那退出终端时这个后台作业还是有被杀的风险。具体是否被杀，取决于 shell 退出时是否会主动向后台作业发 SIGHUP。bash 的交互式 shell 在退出时通常会向所有作业发送 SIGHUP（除非显式 disown 过）。而 nohup 解决的正是这个信号问题。
2.4 nohup 方案什么时候不适合
nohup 适合的场景是：脚本自己能跑完，不需要人工介入，也不要求重启后还能自动恢复。
如果你启动的是一个需要持续对外提供服务、崩溃后要自动拉起的程序，nohup 就力不从心了。进程意外挂掉没有人管，服务器重启后也不会自动恢复。这种场景应该交给 systemd 或进程管理工具，后面会专门讲。
还有一类场景是任务需要交互、需要频繁查看输出内容。nohup 启动后虽然能通过 tail -f 日志文件 来看输出，但如果你需要中途进入程序内部、发送指令（比如调试 Python REPL、进入 GDB 附加进程），那就得用 tmux/screen 这类交互式复用工具。
3. setsid：让进程彻底脱离终端会话
nohup 的思路是"忽略 SIGHUP"，但本质上进程依然还在原来的会话里。有些场景下你希望进程完全脱离会话，成为一个独立的存在——这时候 setsid 比 nohup 更彻底。
3.1 setsid 的原理：新开一个会话
Linux 中每个进程都有一个会话 ID（Session ID，简称 SID）。默认情况下，你自己启动的进程会继承你当前 shell 的会话 ID。会话的首进程通常是你的登录 shell，也就是你 SSH 登录后的那个 bash 进程。
setsid 的原理是 fork 一个子进程，然后让这个子进程调用 setsid() 系统调用，从而创建一个全新的会话，并且这个新会话没有控制终端。因为进程脱离了原来的会话，原终端关闭时发起的 SIGHUP 根本不会找到它——连接都没了，信号自然送不到。
用法：
bash复制setsid python train.py > train.log 2>&1 < /dev/null
这里额外加了 < /dev/null 把标准输入也重定向掉了，避免某些程序因为读不到输入而异常或因为继承了终端输入流导致一些 tty 相关的 ioctl 报错。
对比一下 nohup 和 setsid：
| 特性 | nohup + & | setsid |
|---|---|---|
| 对 SIGHUP 的防御 | 忽略信号 | 直接脱离会话，收不到信号 |
| 是否还在原会话 | 在 | 不在，新会话首进程 |
| 是否有控制终端 | 仍有（除非手动重定向） | 默认无 |
| 适用场景 | 临时脚本、快速任务 | 需要更强隔离的临时守护 |
3.2 什么场景用 setsid 而不是 nohup
说实话，日常运维里 nohup 已经覆盖了大多数临时任务的需求。setsid 的优势主要体现在一些比较特殊的场景，举个例子：你在 CI/CD 流水线里要启动一个中间服务，供后续测试步骤调用。流水线里执行命令的 shell 可能在脚本结束时会做收尾清理，nohup 不一定能完全防住所有信号连带问题；setsid 就更干净，它直接脱离流水线的会话体系。
另外，如果进程在处理某些终端相关的 ioctl 时对是否拥有控制终端非常敏感，或者你不希望进程因为某个终端消失而陷入奇怪的挂起状态，用 setsid 也会少很多幺蛾子。
3.3 disown 和 setsid 的关系
有些资料会提到 disown，它是 shell 内建命令，作用是把某个后台作业从当前 shell 的作业表中移除。移除之后，shell 退出时即便想给所有作业发 SIGHUP，名单里也没有它了，所以能起到"不那么容易死"的作用。
bash复制python train.py &
disown
但这种方案的可移植性不如 nohup/setsid，因为 disown 是 bash 的特性，其他 shell 可能不提供或语义不同。而且 disown 以后，你连 jobs 都看不到它，想管理反而麻烦。临时用一下可以，但不建议当作常规套路。
4. 不只有后台命令：screen 和 tmux 在长任务运维中的真实价值
后台命令能解决"不断开"的问题，但解决不了"想重新看现场"的问题。如果你启动的脚本会输出大量过程信息，中途你想看一眼跑了多少；或者你想在一个会话里同时跑多个不同任务，又希望随时能切回去——这时候 nuhup 和 setsid 都不太方便，因为它们的输出只能靠日志文件，没有交互能力。
我的做法是：临时单任务用 nohup，需要多任务切换或长期驻留终端会话的选择 tmux 或 screen。两者二选一的话，我倾向 tmux，因为它的分屏和会话管理能力更强；screen 在极简环境里更通用，很多老的 Linux 发行版默认装了 screen 但没装 tmux，看你手上机器的实际情况。
4.1 tmux 的典型用法
核心概念是：tmux 本身是服务端，你在里面开的每一个会话（session）都是一个独立环境，SSH 断开不会销毁它，下次登录可以重新 attach 回去。
开启新会话并直接给会话命名：
bash复制tmux new -s deploy
这样会进入一个 tmux 的虚拟终端，你可以像平时一样敲命令，前台运行脚本也行：
bash复制python train.py
然后你可以按 Ctrl+b 再按 d，临时脱离（detach）这个会话。此时 SSH 断开都没有关系，训练任务照样跑。
重新连上服务器后，找回会话：
bash复制tmux attach -t deploy
如果不记得会话名，可以先列出所有会话：
bash复制tmux ls
如果会话意外还在但 attach 时提示权限问题，先确认是不是多个用户登录导致的 socket 权限问题，可以用 tmux -S /tmp/custom.sock 指定 socket 路径来规避。
4.2 隐藏会话和脚本内启动 tmux
有些场景不想手动进入 tmux 再敲命令，希望能直接在一个新会话里启动某个程序。tmux 支持这样：
bash复制tmux new -d -s worker 'python worker.py > worker.log 2>&1'
-d 表示直接 detach，不进入交互界面；-s worker 指定会话名；后面的命令字符串由 tmux 的 shell 去执行。
这样既拿到了 nohup 一样的后台效果，又保留了随时 tmux attach -t worker 进入现场的能力，还能看程序有没有报错、甚至给程序发信号。
4.3 tmux 里的多窗口和分屏
当你负责一台机器上多个服务的部署时，一个会话里开多个窗口非常实用：
bash复制Ctrl+b c 创建新窗口
Ctrl+b n 切到下一个窗口
Ctrl+b p 切到上一个窗口
同一个会话里也可以分屏：
bash复制Ctrl+b % 垂直分屏
Ctrl+b " 水平分屏
调试前后端联调时，左边窗口 tail -f 后端日志，右边窗口执行 curl 请求，非常直观。
4.4 运维习惯上的建议
我自己的操作习惯是：能固定用 tmux 统一管理交互式长任务。比如启动数据库迁移、跑数据回刷脚本、持续观察某个服务的日志输出等，都是先 tmux new -s 再执行，不用 nohup。这样即使任务跑了几个小时，随时可以 attach 回去看屏幕输出，甚至中途 Ctrl+C 调整参数重新来，不用杀掉整个进程。
比较而言，nuhup 适合"启动后完全不看、让它自己结束"的任务；tmux 适合"我还要回来看一眼"的任务。
5. 追查与清理后台进程：从 PID 到会话树的完整思路
后台命令的问题往往不是"怎么启动"，而是"启动完发现忘了记 PID、现在找不到它在哪"。很多做运维没多久的朋友，真遇到服务异常需要清理时，常常只记得一个模糊的名字，然后用 pkill 一把梭，结果误杀了别的进程。
5.1 查找进程信息的基本命令
查看进程最常用的是 ps，但我更推荐直接看进程树：
bash复制ps -ef --forest
这个命令能直观显示进程的父子关系。比如你用 nohup 启动了一个服务，它的父进程是 1 号进程（systemd）还是你的 shell，在 --forest 视图里一目了然。
如果你只知道程序名的部分关键词，可以用：
bash复制pgrep -a python
pgrep -a 会列出 PID 和完整命令行，能方便你确认到底匹配到了谁。也可以用：
bash复制ps aux | grep python | grep -v grep
但多级管道明显不如 pgrep 干净。
5.2 为什么要理解父子进程关系
后台任务和普通任务的差别，很大程度体现在父子关系上。如果任务的父进程还是你的 shell，那 shell 一退，它也活不长；如果任务被 Init 或 systemd 收养（PPID 变成 1），说明它已经成功"脱孤"了。
实际操作里排查问题的思路通常是这样的：
bash复制ps -ef | grep train
找到 PID 后，查看进程状态：
bash复制cat /proc/PID/status
重点看 State 和 PPid 两行。State 如果是 S 表示睡眠，R 表示运行，Z 表示僵尸。
也可以用 pstree 查看从 systemd 到目标进程的完整树：
bash复制pstree -p | grep train
5.3 结束后台进程的正确姿势
结束进程首选 kill，它默认发送 SIGTERM（信号 15），给进程一个清理资源、释放锁的机会。
bash复制kill 12345
如果进程不响应，一两秒后可以尝试：
bash复制kill -9 12345
SIGKILL（信号 9）不能被捕获或忽略，内核直接强制结束进程。但 SIGKILL 会让进程没有机会做任何清理，比如临时文件可能残留、数据库连接可能没正常释放，只能作为最后手段。
如果任务是通过 tmux 会话跑的，可以先进会话按 Ctrl+C，正常终止进程后再退出会话，而不是直接 kill 掉 tmux server，否则里面的子进程可能变成孤儿。
对于同名进程很多的情况，不要盲目 pkill。先 pgrep -a 确认匹配范围，再用 pkill -f 精确匹配完整命令行。-f 表示匹配完整参数，但也正因为匹配范围变大，误杀风险也高，要格外小心。
5.4 一些隐藏问题：僵尸进程与孤儿进程
后台命令跑久了，系统里难免出现僵尸进程（Zombie）。僵尸进程的特征是进程已经退出，但父进程没有调用 wait() 系统调用回收它的退出状态。它在进程表里占一个位置，但不消耗 CPU 和内存。
处理僵尸进程的唯一办法是让它的父进程去回收，或者让父进程退出，这样僵尸进程会被 1 号进程收养并清理。你不能直接 kill 一个已经死掉的僵尸进程，kill -9 对它无效。
当你启动一个后台任务后就把终端关了，进程可能被 1 号进程收养。这时候它的父进程变成了 systemd，如果它退出，systemd 会及时回收，一般不会变僵尸。
孤儿进程则是指父进程先退出、子进程还在运行的进程。这类进程会被内核托付给 1 号进程收养，本身无害。但如果你丢了 PID 又找不到日志，孤儿进程的排查会比较费劲。所以每次启动后台任务时，把 PID 写到一个固定文件里是个很好的习惯：
bash复制nohup python train.py > train.log 2>&1 &
echo $! > /tmp/train.pid
$! 是 shell 里上一个后台进程的 PID。之后要停就：
bash复制kill $(cat /tmp/train.pid)
这套逻辑虽然简单，但在脚本化管理机器时非常省心。
6. 后台命令在脚本和服务化场景里的进阶实践
前面讲的方法解决的都是"启动一个进程并让它活下来"，但真实工作里还有一个常见的问题：脚本里启动后台进程，结果脚本退出后进程也莫名其妙没了。或者，你在脚本里启动了一串后台任务，想统一管理退出码，却死活拿不到状态。
6.1 脚本中使用 nohup 时，父 shell 退出是否影响子进程
有个反直觉的陷阱：你用 nohup 启动进程后，如果父 shell 是某个脚本的执行环境，脚本跑完后，这个 nohup 进程绝大多数情况下是能活下来的，因为 nohup 已经忽略 SIGHUP 了。但有一种情况会让它死掉：进程本身不是直接由 nohup 启动，而是经过了一层包装，比如：
bash复制bash -c "nohup python train.py &"
这写法理论上也成立。真正要小心的是：如果进程在启动后立刻向标准输出写大量内容，而你重定向没写好，可能会因为写入已关闭的管道而收到 SIGPIPE，然后进程就默默退出了。
所以脚本里启动后台任务时，一定确保标准输出、标准错误、标准输入三个文件描述符都做了重定向：
bash复制nohup python train.py >/var/log/train.log 2>&1 </dev/null &
这条命令对新手来说可能觉得"多此一举"，但加上了 < /dev/null 后，即使终端断开、网络异常，进程也不会因为读取输入而陷入荒谬的等待。
6.2 等待多个后台任务结束：wait 的运用
如果在一个脚本里同时启动多个后台任务，需要等它们全部完成后汇总结果，可以用 shell 内置的 wait 命令：
bash复制#!/bin/bash
python task1.py &
pid1=$!
python task2.py &
pid2=$!
wait $pid1
status1=$?
wait $pid2
status2=$?
echo "task1 exit: $status1"
echo "task2 exit: $status2"
wait 后面可以加 PID 等待指定进程，也可以不加参数等待所有后台子进程。这个命令在脚本批量任务里比一个个轮询省心得多。
但有个问题要意识到：wait 只能等待当前 shell 的子进程。如果你在脚本里用 nohup 或 setsid 启动的任务已经脱离会话、父进程最终变成 1 号进程，wait 就等不到了。适合 wait 的其实是同一个 shell 里直接 & 启动的后台任务，这是两个不同的应用场景。
6.3 后台进程的持久化：从 nohup 到 systemd service
当"后台任务"变成"常驻服务"时，正确思路是放弃纯命令行的 nohup，尽早让程序作为 systemd 服务被托管。
一个最基本的 systemd service 单元文件长这样：
ini复制[Unit]
Description=My Python Service
After=network.target
[Service]
Type=simple
User=www-data
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/server.py
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target
把上述内容写入 /etc/systemd/system/myapp.service，然后：
bash复制systemctl daemon-reload
systemctl start myapp
systemctl enable myapp
systemd 方案最大的好处不是"启动时不被 SIGHUP 搞死"，而是：
Restart=on-failure可以在进程异常退出时自动拉起。journalctl -u myapp可以集中查看日志。- 开机自启动由 enable 管理，天然支持。
- 停止、重启都有规范命令，不用自己找 PID。
我曾经接手过一个跑在服务器上的内部 API，别人用 nohup 启动的，每次服务器一重启就得手动登录敲一遍命令，而且进程崩了完全没人知道。后来我把它改成了 systemd service，配上健康检查，重启由系统自己搞定，日志也能用 journalctl -f 实时跟踪，运维成本降了一大截。
6.4 用户级 systemd 服务：没有 root 也能守护进程
如果你所在环境没有 root 权限，不能往 /etc/systemd/system 里写单元文件，还可以用 systemd 的 user 模式：
bash复制mkdir -p ~/.config/systemd/user
把 service 文件放到这个目录，然后用：
bash复制systemctl --user daemon-reload
systemctl --user start myapp
systemctl --user enable myapp
注意 user 模式的 service 默认在用户退出登录后可能被停止。需要让它持续运行的话，得开启 linger：
bash复制loginctl enable-linger $USER
这个命令让系统保留你的 user manager，即便你注销了，user 服务也能继续运行。这条命令通常也需要一定的权限，但和写全局 systemd 目录相比门槛低很多。
6.5 SSH 断连后的完整排查链路
说了这么多，最后沉淀一个最典型的真实排查流程：你在本地 SSH 启动了一个服务，SSH 断开后再登录发现服务没了。
完整排查链路是：
- 先用
ps aux | grep 服务名或者pgrep -a 服务名，确认进程是不是真的没了，还是换了用户导致看不到。 - 查看对应日志，如果日志没有任何输出且进程消失，考虑是不是收到了 SIGHUP（基本可以确定是没加 nohup 或没用对方式）。
- 确认启动方式。如果当初只是
command &，那退出 SSH 时进程确实可能被 SIGHUP 杀掉。 - 检查是否有系统层面的资源限制，比如
ulimit -u（最大用户进程数），如果启动的服务线程很多或者短时间内拉起了大量进程，可能触碰到上限，进程被创建失败导致"看起来启动失败"。 - 用
dmesg -T | tail -20看看有没有Out of memory或者内核杀进程的记录，确认是否被 OOM killer 结束。
如果是常驻服务，日志查不到退出原因的话，优先看 systemd 的 journal：
bash复制journalctl -u 服务名 --since "10 minutes ago"
这比翻应用自己的日志更早定位到系统层面的杀进程原因。
7. 面试里那些关于后台命令的高频追问
看了一些后台与运维岗位的面试经验，关于 Linux 后台命令这一块的问题其实特别密集，而且面试官问得细的时候，是真的需要踩过坑才能答得漂亮的。这里整理几个高频考点我自己的回答思路。
问：怎么让一个命令在用户退出终端后仍然运行？
先回答最稳妥的方式：用 tmux 或 screen 开一个会话执行，或者用 nohup 加 &，或者写成 systemd 服务托管。再说一句"这些都是为了让进程脱离 SIGHUP 的影响，只是实现层级不同"，基本能体现理解深度。
问：nohup 和 & 有什么区别？
& 是把命令放到当前 shell 的后台作业列表，进程还在当前会话里；nohup 是让命令忽略 SIGHUP 信号。一般实际使用时会组合起来：nohup command &。如果只说"一个防断一个放后台"，会显得比较浅，把背后的信号机制点出来会好很多。
问：你如何查看一个后台进程的父进程是谁？
用 ps -o ppid= -p PID 或者 ps -ef | grep PID 看 PPID 列。更完整一点说，可以看 /proc/PID/status 里的 PPid 字段。如果 PPID 是 1，说明进程已经被 init/systemd 收养。
问：kill 和 kill -9 的区别？
kill 默认发 SIGTERM，进程可以捕获取处理清理工作；kill -9 发 SIGKILL，内核直接终止，进程无法拦截。实际处理问题时优先 SIGTERM，给进程几秒钟，实在没反应再 SIGKILL。
问：如何处理后台任务成了孤儿进程？
解释清楚什么是孤儿进程：父进程退出后，子进程会被 1 号进程收养，它本身还能正常运行。重点在于不能被"孤儿"两个字吓到，孤儿进程不是破损进程。
问：什么是僵尸进程？如何清理？
僵尸进程是子进程退出后父进程没有正确回收其退出状态，进程表条目仍然残留。普通用户无法直接 kill 僵尸进程。能让其父进程调用 wait()，或者让父进程退出，由 init/systemd 清理。如果父进程是你的 shell，那退出那个 shell 往往就解决了。
问：后台启动一个 Web 服务并记录日志，你会怎么设计命令？
我会写：
bash复制nohup ./webapp --port 8080 >/var/log/webapp.log 2>&1 &
echo $! > /var/run/webapp.pid
然后说明如果把 Web 服务作为长期业务，实际更推荐 systemd 的方式。这样体现出你不是只会背命令，而是有工程化取舍的能力。
考察后台命令的面试题，表面问的是命令用法，实际考察的是你对 Linux 信号机制、进程模型的理解程度。真正理解进程间父子关系和信号的流转过程，面试时不管问题怎么换，都能接得住。
我最早学后台命令时也是死记硬背，直到自己运维的服务因为一次 SSH 断连莫名其妙消失、才真正去翻进程模型和信号处理。把那层窗户纸捅破之后，Linux 后台相关的命令基本上就不太需要刻意背了——因为每个命令解决什么问题，原理上都是清晰的。这个思路对学习和排障都有用，遇到不认识的命令，先问一句"它到底改变了进程的什么状态"，很多问题就迎刃而解。