tmux本身不后台运行任务，而是创建解耦会话环境使任务持续存活；关键动作是tmux new -s name启动后必须按ctrl+b d分离，否则仍属前台会话，终端断连即被sighup终止。
直接说结论：tmux 本身不“后台运行任务”，而是创建一个与终端解耦的会话环境，让任务在服务器上持续存活；关键动作是 tmux new -s name 启动 + Ctrl+b d 分离，不是用 & 或 nohup。
为什么 tmux new -s xxx 后还要按 Ctrl+b d？
很多人以为只要 tmux new -s train 就算“后台”了，其实不是——此时你仍处在该会话的前台，关掉终端或 SSH 断连，train 进程照样被 SIGHUP 终止。
必须手动分离（detach），才能把会话交还给 tmux server 管理，脱离当前终端生命周期：
-
Ctrl+b是默认前缀键（松开后再按） -
d触发 detach，终端立刻退回原始 shell，并显示[detached from session train] - 此时即使
exit或关掉整个终端窗口，train里的python train.py或tail -f log.txt都还在跑
tmux ls 没输出？别急着重装，先查这三件事
tmux ls 返回空，不代表会话丢了，大概率是 tmux server 进程挂了。它不写磁盘、全靠内存+socket 活着：
- 运行
df -h /tmp—— 如果/tmp满了（常见于日志堆积），tmux 无法创建 socket 文件（路径通常是/tmp/tmux-$(id -u)/） - 执行
ps aux | grep 'tmux: server'—— 若无输出，说明 server 已死，可能是 OOM killer 杀掉，或 systemd user session 被登出连带清除 - 检查
~/.tmux.conf里有没有set -g default-shell指向一个不存在的 shell（比如配了/bin/zsh但没装 zsh），会导致 server 启动失败
tmux attach -t xxx 报 “no sessions”？名字大小写和 shell 展开是元凶
这不是命令错了，是会话名根本没创建成功，或者你连错了目标：
- 会话名严格区分大小写：
tmux new -s Train和tmux attach -t train是两个世界 - 名字里含空格或特殊字符（如
tmux new -s "my task"）会被 shell 展开成多个参数，实际创建的是my和task两个非法会话名，tmux ls可能不显示 - 安全做法：只用小写字母+数字命名，创建后从
tmux ls输出里复制粘贴名字，例如看到train: 1 windows (created )，就用tmux attach -t train
长期无人值守时，这几个细节决定成败
训练跑三天没问题，但第 36 小时突然卡住？往往败在这些不起眼的地方：
- 交互式程序（如
vim、htop、需要输入密码的sudo）在分离后可能因 stdin 阻塞而假死，提前在会话中运行stty -icanon -echo; cat测试是否支持持续 stdin - 不要依赖图形界面或特定 TTY 的命令（比如某些
systemd --user服务、需要$DISPLAY的工具），它们在 tmux 会话里大概率失败 - 如果任务真要跨系统重启存活，tmux 本身做不到——得配合
tmux-resurrect插件或改用systemd --scope服务
真正难防的不是操作失误，而是 server 在你不知情时静默退出。每次 tmux attach 前，养成习惯先 tmux ls 看一眼，比什么都管用。
