nohup仅使命令忽略sighup信号，不自动后台运行；必须加&才能真正后台执行并释放终端控制权，且2>&1必须置于>log之后才能将标准错误一并重定向到文件。
nohup 本身不后台运行，必须显式加 & 才真正在后台执行；只写 nohup command 会卡在前台，且仍接收终端输入（除非重定向 stdin），这是最常被误解的一点。
nohup command 和 nohup command & 的行为差异
前者只是让命令忽略 SIGHUP，但仍在前台阻塞当前 shell，你无法继续输入其他命令；后者才真正交还控制权，进程进入后台。关键区别不是“有没有 nohup”，而是“有没有 &”。
-
nohup python app.py：进程前台运行，Ctrl+C 可终止，关终端仍存活（因忽略 SIGHUP），但你被卡住不能干别的 -
nohup python app.py &：进程后台启动，shell 立即返回提示符，关终端后持续运行 - 如果没加
&又没重定向 stdin，程序可能因尝试读取终端而挂起（比如 Python 脚本里写了input()）
输出重定向为什么必须写成 2>&1 &，而不是 >log 2>&1
顺序决定重定向是否生效：2>&1 表示“把 stderr 指向当前 stdout 的目标”，所以它必须出现在 >log 之后；否则 stdout 还是连着终端，stderr 就跟着 stdout 一起打到屏幕上了。
- ✅ 正确：
nohup python app.py >app.log 2>&1 &—— 先把 stdout 定向到文件，再让 stderr 跟过去 - ❌ 错误：
nohup python app.py 2>&1 >app.log &—— stderr 先指向终端，再把 stdout 定向到文件，结果只有 stdout 进文件 - ⚠️ 静默丢弃：
nohup python app.py >/dev/null 2>&1 &—— 常用于不需要日志的守护任务
为什么有时关终端后进程还是退出了
根本原因不是 nohup 失效，而是 shell 会话未正常退出。直接点击 X 关闭终端窗口，会向整个会话发送 SIGHUP，而 nohup 只保护它直接启动的进程，不保护其子进程树（尤其当启动链中有 bash -c、sh -c 等中间壳时）。
- 安全做法：先按
Enter确保看到 shell 提示符，再输入exit或logout - 更可靠替代：
setsid python app.py >app.log 2>&1 &——setsid创建新会话，彻底脱离终端控制组 - 终极方案：用
screen -dmS myapp python app.py或tmux new-session -d -s myapp 'python app.py'，它们从会话层隔离，不依赖信号屏蔽
如何确认 nohup 进程真的在跑且不受终端影响
别只信 jobs —— 它只显示当前 shell 的作业，nohup + & 启动的进程很快脱离 job 控制，jobs 查不到是正常的。
- 查进程存在：
ps aux | grep app.py或pgrep -af app.py - 看父进程 PPID：
ps -o pid,ppid,comm -C python，nohup 启动的应显示 PPID 为 1（systemd/init）或某个稳定父进程，而非你的终端 bash PID - 验证 SIGHUP 忽略：
kill -SIGHUP $(pgrep -f "app.py")，然后检查进程是否仍在（需提前确保没被其他逻辑捕获该信号）
真正容易被忽略的是：nohup 不解决进程崩溃重启、资源泄漏、日志轮转或依赖服务就绪等问题。它只做一件事——屏蔽挂起信号。需要长期稳态运行，得配合 systemd service、supervisord 或容器化方案。
