nohup仅忽略sighup信号，不实现后台运行；必须加&才能释放终端控制权，否则命令阻塞前台。正确用法为nohup command > log 2>&1 &，否则日志可能丢失或写入失败。
nohup 后不加 & 会卡住终端
很多人执行 nohup python3 server.py 后发现命令没返回提示，光标一直停着——这不是成功了，是进程还在前台运行，只是忽略了 SIGHUP。它仍占用当前终端的 stdin/stdout，你无法输入其他命令。
真正后台运行必须加 &：
-
nohup python3 server.py &：正确，释放终端 -
nohup python3 server.py：错误，阻塞当前 shell
加了 & 后你会看到类似 [1] 12345 的输出，12345 是进程 PID，可用来 kill 12345 终止。
输出重定向不写 2>&1 会导致日志丢失
默认情况下，nohup 把 stdout 和 stderr 都写进 nohup.out。但一旦你用 > 指定文件，stderr 就不会自动合并——它仍输出到终端（如果终端还开着）或被丢弃（如果已关闭）。
常见错误写法：nohup ./run.sh > app.log & → app.log 里只有正常输出，报错信息全没了。
正确做法始终显式合并错误流：
-
nohup ./run.sh > app.log 2>&1 &：stdout 和 stderr 都进app.log -
nohup ./run.sh > stdout.log 2> stderr.log &：分开记录，适合调试 -
nohup ./run.sh > /dev/null 2>&1 &：完全静默，适合无状态守护任务
nohup.out 写入失败时不会报错，但命令根本没跑
如果当前目录不可写（比如权限不足、磁盘满、挂载为只读），nohup 会尝试写入 $HOME/nohup.out；若主目录也不可写，它就直接失败——但你可能看不到任何提示，只发现进程没起来、日志也没生成。
典型现象：nohup ping -c 3 example.com & 执行后 ps aux | grep ping 查不到进程，jobs 也为空。
排查方法：
- 先确认当前目录写权限：
touch test_write && rm test_write - 手动测试写入：
nohup echo test > /dev/null 2>&1 &，再看是否真有子进程 - 加
-v参数（部分系统支持）或改用绝对路径日志：nohup ./script.sh > /tmp/script.log 2>&1 &
nohup 不能解决所有“断连存活”问题
nohup 只拦截 SIGHUP，但它不管进程是否依赖终端设备、是否需要交互式 stdin、是否被 systemd 或容器平台回收。
容易被忽略的边界情况：
- 程序内部调用了
read()等待 stdin 输入 → 即使加了nohup，也会卡住（应配合） - 在 systemd 用户 session 下运行 → 登出后 session 被清理，进程可能被 kill（此时应改用
systemd --user服务） - 脚本里用了
sudo或需要密码 → 后台运行时无法交互输入，直接失败 - 进程自己监听并响应
SIGTERM或SIGINT→nohup不影响这些信号，关机时仍可能被终止
真正长期稳态运行，nohup 只是入门级方案；生产环境建议搭配 systemd、screen 或容器化部署。
