关掉终端后程序仍能运行的关键是避免接收sighup信号或被父进程终止；nohup + & 是最简可靠组合，适合一次性任务；已启动前台程序可用ctrl+z→bg→disown抢救；交互场景选screen/tmux；长期服务应使用systemd用户服务。

关掉终端后程序还能活，关键不是“放后台”，而是“不收 SIGHUP 信号”或“不被终端父进程连带杀死”。& 单独用不行，nohup 是最轻量可靠的起点。

nohup + & 是最常用且够用的组合

它让命令忽略挂起信号，并自动把输出写进 nohup.out（当前目录下），适合一次性、非交互类任务。

• nohup python3 app.py &：最简写法，输出默认进 nohup.out
• nohup ./server.sh > server.log 2>&1 &：显式重定向，2>&1 必须写在 > 后面，否则错误仍打屏
• 如果当前目录不可写，nohup 会退到 $HOME/nohup.out；若两者都失败，命令直接不执行
• 注意：& 一定要放在整条命令末尾，写成 nohup cmd &，不是 nohup cmd&（空格不能省）

已启动的前台程序怎么补救？用 disown

你已经敲了 python3 task.py，还没加 & 或 nohup，但又不想 Ctrl+C 重来——可以抢救。

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• 先按 Ctrl+Z 暂停它，此时变成“stopped”状态
• 运行 bg 把它切到后台继续跑
• 再运行 jobs 确认作业号（比如显示 [1] + running python3 task.py &）
• 执行 disown %1（%1 是作业号），它就从 shell 的作业表里移除了
• 之后关终端，进程不再收 SIGHUP，能继续活

需要交互或长期维护？选 screen 或 tmux

适合要随时看日志、按 Ctrl+C 中断、甚至临时敲几行命令的场景，本质是换了个“不会死”的终端容器。

• screen -S myapp 启动命名会话，然后运行你的程序
• 按 Ctrl+A 再按 D（不是 Ctrl+D）分离，会话保留在后台
• 恢复用 screen -r myapp；如果提示 “There is a screen on…”，说明已有连接，用 screen -D -r myapp 强制接管
• tmux new-session -d -s mytask 可直接后台启动（适合脚本调用），恢复用 tmux attach-session -t mytask
• 注意：screen 在 Alpine 等精简系统里默认没装；tmux 依赖 ncurses，两者都不是“开箱即用”

要开机自启、崩溃重启、服务化？走 systemd 用户服务

这不是临时方案，而是把程序当正式服务管。适合你希望它像 nginx 或 redis 那样稳住跑几年。

• 写一个 $HOME/.config/systemd/user/myapp.service 文件，里面指定 ExecStart= 和 Restart=always
• 运行 systemctl --user daemon-reload 加载配置
• 启用并启动：systemctl --user enable --now myapp.service
• 日志统一用 journalctl --user -u myapp 查，不用自己管文件轮转
• 注意：必须用 --user，否则它会试图注册为系统级服务，普通用户没权限

真正容易被忽略的是输出重定向——哪怕用了 nohup 或 screen，如果程序内部有未捕获的 panic、或者 stdout/stderr 没被接住，它可能因为写不到终端而静默退出。所以只要不是纯丢弃日志，务必加上 > log 2>&1 这类重定向。