1月8日晚上我在实验室把模型训练脚本跑起来的时候心里只有一个念头终于可以回宿舍了。然后我合上笔记本屏幕的那一瞬间终端里的进度条停止了。第二天到实验室一看训练日志空白一片——这大概是每个研一新生都会经历的“合盖事故”。后来我才搞明白不借助任何工具直接通过SSH在远程服务器上跑代码任务进程和SSH会话是绑定在一起的。只要SSH断开系统就会向这个进程发送挂断信号进程随之结束。想要在关闭电脑之后让远程任务继续跑核心思路就是让进程脱离会话而存在。我当时用的方案是screen配合VSCode远程连接服务器实现完整的“挂起任务、断开电脑、隔天恢复、实时看日志”流程。这篇文章不是面面俱到的官方教程我按自己从零摸索的顺序把screen怎么用、VSCode远程连接怎么配、日志怎么看、中间踩了哪些坑都记录成了一份可以直接照着做的经验。特别适合刚拿到服务器账号、第一次跑长时间训练任务的科研小白。1. 一台笔记本、一台服务器和一个说断就断的训练任务1.1 为什么SSH一断开代码就跟着停了先说原理。当你用SSH连接远程服务器时服务器会为这个连接分配一个伪终端PTY。你在这个终端里输入的所有命令启动的所有进程都挂在这个SSH会话之下形成一个进程树。SSH连接就像一根脐带终端里跑的程序靠它维持和你的“联系”。问题出在断开那一刻。SSH连接正常结束或意外中断时远程服务器会给这个会话所属的进程组发送SIGHUP挂断信号。对于没有处理这个信号的普通进程来说默认行为就是终止。所以你在远程终端里启动的训练脚本本质上只是SSH会话的一个子进程连接断了它也就被系统带走了。这个机制对短命令没影响比如你SSH上去跑个ls、grep命令执行完瞬间就返回了。但换成训练模型、跑数据预处理这类需要几小时甚至几天的任务问题立刻就暴露出来任何一点网络波动、一次本地休眠、一个合盖动作都足以让几小时的计算白费。1.2 我在那次“合盖事故”里学到的事那次事故的完整经过是这样的下午我在服务器上敲了python train.py看到loss正常下降想着晚上回来再收结果。我直接关了笔记本走人甚至没有先按exit退出SSH就是很自然地把盖子合上了。第二天打开电脑重新连上服务器终端提示连接被关闭再一查进程整个训练进程已经不存在了。后来师兄告诉我远程跑长任务有三条路nohup、screen、tmux。我当时选了screen理由很简单——它能在任何SSH断开的情况下把会话保留在服务器端下次连上还能原样恢复回来还能实时看到输出。而nohup虽然也能让进程不挂但只能把日志写到文件里想再回到那个任务的交互界面就很麻烦。那天晚上我在服务器上把screen装好又从头到尾把完整流程跑了一遍确认关掉笔记本再恢复也没问题之后才踏实回宿舍。这篇文章里写的内容多数就是那前后的真实操作记录。2. screen到底做了什么才让任务“脱离”终端2.1 screen的两层结构会话与窗口screen是一个终端复用器。它的核心思路是把“进程运行环境”和“你眼前的终端显示”拆成两层screen在服务器端创建一个常驻的会话session会话里可以开多个窗口window每个窗口都对应一个shell你的训练程序就跑在其中一个窗口里。关键点在于这个session不是某个SSH连接的附属品。当你断开SSH时session本身由服务器上的screen进程继续托管里面的窗口和正在运行的命令都不受影响。你下次重新SSH登录后输入screen -r 会话名就能把之前的窗口原样拉回来屏幕上还在滚动着training log这就是会话恢复。可以这样理解SSH是你和服务器之间的临时通道而screen是服务器上的一个“后台值班室”。通道断了不影响值班室里的人继续干活你下次回来推开门还能看见他在哪个窗口里忙什么。2.2 为什么不用nohup代替screen没接触过的人可能会问nohup也能让进程不退出啊为什么非要screen两者解决的问题有重叠但侧重点不同。nohup python train.py train.log 21 确实能让进程在后台跑即使SSH断开也不受影响。但它的问题是启动之后你和这个进程之间就只剩一个日志文件了。如果训练过程中突然需要暂停、调整参数、进入Python交互式调试或者某个步骤卡住需要人工干预nohup就帮不上忙你只能kill掉重新跑。screen则保留了完整的交互能力。训练跑着的时候你可以随时screen -r进入会话观察输出、按CtrlC中断、改完代码再重新跑。如果需要离开按分离快捷键任务继续。这种自由度在调试代码、跑长实验的过程中非常有用。下面的表格是我当时做的对比适合快速决策能力nohup 重定向screen后台运行不受SSH影响支持支持断线后重新查看输出只能看日志文件可恢复交互界面训练中手动干预不支持支持多任务同时管理靠多个日志文件多窗口/多会话学习成本低低到中等对于纯“丢上去跑第二天看日志”的场景nohup够用但只要你有任何中途查看、调试、多任务并行管理的需求screen明显更顺手。2.3 第一次在服务器上安装和验证screen绝大多数服务器系统没有预装screen需要自己装。我当时连的是Ubuntu服务器命令很简单sudo apt update sudo apt install screen如果是CentOS等使用yum的系统就用sudo yum install screen。装好之后可以先跑一个最基础的自测screen -S test这个命令会创建一个叫test的会话并进入界面看起来整个终端被清空只有一个新的shell提示符。此时可以随便跑个命令比如htop然后按快捷键分离CtrlA松开再按D分离之后会回到原来的SSH终端同时看到一行提示[detached from ...]。再查看会话列表screen -ls如果看到test会话还在就说明创建、分离这个循环已经通了。我当时看到(Detached)状态时第一反应是“竟然这么简单”后面真正跑到训练任务里才陆续碰见各种细节问题但这些放到后面章节说。3. VSCode Remote-SSH把远程目录变成本地工程3.1 配置Remote-SSH和ssh configscreen解决的是任务后台运行问题但日常开发还有一个更基础的需求编辑远程服务器上的代码。很多研一新生还在用vim在服务器上改代码也不是不行但VSCode的Remote-SSH插件提供了更接近本地开发的体验。在VSCode扩展商店搜索“Remote - SSH”认准微软官方出品那个安装即可。它属于Remote Development系列扩展包装上之后左侧会多出“远程资源管理器”的入口。连接前最好先配置好~/.ssh/config文件。VSCode的远程连接本质上就是调系统SSH所以配置文件写清楚能省很多重复劳动。我的配置长这样Host lab-server HostName 192.168.1.100 User student Port 22其中Host是你自己起的别名后面无论VSCode还是终端都直接连lab-server就行不用每次记IP和用户名。如果有跳板机或者特殊端口在config里按需增加字段。配置好之后在VSCode里按F1输入“Remote-SSH: Connect to Host”选择刚才配置的lab-serverVSCode会在新窗口里建立远程连接左下角显示SSH: lab-server就代表成功。第一次连接会下载并安装远程服务器端的VSCode Server组件耐心等一会儿就好。3.2 免密登录配置这一步别偷懒如果每次连接都输密码很快就会烦。尤其是配合screen的场景你可能一天要来回断开、重连好几次输密码会拖慢节奏。更推荐用SSH密钥认证。在自己的电脑上生成密钥对ssh-keygen -t ed25519 -C your_emailexample.com一路回车会在~/.ssh/下生成id_ed25519私钥和id_ed25519.pub公钥。然后把公钥内容追加到服务器的~/.ssh/authorized_keys文件里。最简单的做法是用ssh-copy-idssh-copy-id student192.168.1.100执行完会提示输入一次密码之后SSH连接就不需要密码了。这一步做完后面配合screen的频繁重连体验会丝滑非常多。3.3 远程打开项目后的第一件事连接成功后在VSCode里选择“打开文件夹”输入服务器上项目所在路径。注意VSCode菜单里的“文件-打开文件夹”在远程模式下会变成打开服务器端目录不是本地目录别被绕晕。我个人的习惯是打开项目后第一件事就是按Ctrl打开终端。这个终端默认就是SSH到服务器的shell可以直接输入screen -r恢复之前的会话也可以在VSCode里直接编辑代码、右键运行脚本配合screen使用编辑、运行、查日志都集中在同一个窗口流里不需要来回切换软件。顺便提一句VSCode的远程终端和本机终端在screen看来没有任何区别用screen -r恢复会话时它并不关心你是在哪种终端里发起的连接。所以你可以今天用VSCode终端恢复明天用系统自带终端恢复完全没问题。4. 一套完整的“跑代码、断开、恢复、看日志”工作流4.1 用screen挂起训练任务的完整命令序列下面这套流程是我现在每次跑长期任务的固定操作每一步都标注了用途。第一步SSH连接服务器并进入项目目录ssh lab-server cd ~/projects/my_exp第二步确认没有其他会话残留并创建一个用于本次训练的screen会话screen -ls screen -S train_run_0118注意给会话起一个有意义的名字日期加任务名最直观。这样后面多个会话并存时不会认错。第三步在screen会话里启动训练脚本。这一步可以在VSCode终端里交互式启动也可以配合重定向把日志写到文件里后面章节会细说。python train.py --config conf/exp1.yaml第四步按下分离快捷键CtrlA松开再按D看到[detached from ...]提示后就可以直接关闭VSCode窗口、关闭笔记本。SSH断开后screen会话在服务器端不受影响。第五步第二天恢复会话ssh lab-server screen -r train_run_0118进入后就能看到训练还在继续终端上滚动着新产生的日志。按下CtrlA D再次分离就是下一次“下班”操作。整个循环可以无限重复直到训练结束。4.2 实时查看log的三种姿势实时查看日志是远程跑任务的高频需求我整理了几种姿势按适用场景分类。第一种直接在screen会话里看。最直接适合“进了会话就不想出来”的场景。但要注意screen窗口的回滚缓冲区是有限的默认只保留最近若干行。如果日志刷得很快想看更早的输出就不行。解决办法是利用screen的copy mode按CtrlA再按[进入回滚浏览用上下键翻屏按q退出。第二种日志重定向到文件后用tail -f实时跟踪。这种方式的好处是日志永久落盘回滚、搜索都非常方便。启动命令可以写成python train.py train.log 21这样stdout和stderr都写进了train.log。然后在任何终端里执行tail -f train.log就能实时看到新追加的日志行。这也是我日常用得最多的组合因为可以不用进screen直接在VSCode开个新终端看日志screen会话保持原样不受干扰。第三种用tee实现“屏幕和文件双写”python train.py 21 | tee train.log这个命令让日志同时在screen界面上滚动、又写入文件。好处是进了screen能看到实时输出退出后用tail -f train.log也能看历史记录。缺点是程序输出量极大时tee会稍微增加一点IO开销但对绝大多数科研任务来说完全无感。如果只想看关键部分的日志可以在tail管道后面接greptail -f train.log | grep -E Epoch|Loss|Error再配合grep --colorauto一眼就能从海量输出里找到关键指标。4.3 训练日志的规范化建议日志好不好看直接决定你第二天打开服务器时的心情。我早期跑实验时日志写得很随意用print随便打几个值结果训练到一半要排查问题时完全不知道进度到哪了。现在的日志至少包含以下信息当前epoch、当前step、loss值、学习率、当前时间戳。例如2026-01-08 23:14:32 | Epoch 3/50 | Step 1200/5000 | Loss: 0.3421 | LR: 1e-4这样在tail -f里扫一眼就能判断训练是否正常。还有一个很好的习惯是每隔固定步数往单独的文件里存一份可解析的指标比如直接存成csv或json line后续做实验对比时会非常方便。另外训练代码里最好加上flush逻辑让日志即时写到文件。我踩过的一个坑是Python的print在重定向到文件时有缓冲导致tail -f看到的内容滞后甚至看不到。解决方法是在启动命令前加python -u参数unbuffered或者在代码里给logging模块设置streamNone等合适配置。具体操作是python -u train.py train.log 21这个-u很小但能让日志实时性天差地别强烈建议加上。5. 消耗了我大量时间的screen事故现场5.1 最常见报错attached状态与-d -r用screen一周内必然会遇到的一个状况明明之前创建的会话还在但执行screen -r train_run_0118时系统提示会话是Attached状态无法直接恢复。这不是bug而是你上次分离操作没有正确执行。常见场景是SSH连接意外中断比如网络断了一下、笔记本合盖前没按分离快捷键screen会认为那个会话还“握”在某个终端里。但实际上那个终端已经不存在了。解决办法就是强制从原终端“夺回”会话screen -r -d train_run_0118-d表示先把原连接detach掉-r再重新恢复。如果只有一个会话也可以简写为screen -d -r。这个命令我几乎每周都会用到值得记牢。还有一种更少见的情况是你在两个终端同时连接服务器一个终端已经进入了某个screen会话另一个终端又想进去。同样会报“Attached”错误。所以养成每个会话“有进有出”的习惯很重要分离快捷键要按得勤快。5.2 用户切换和多人共用服务器时的session冲突实验室服务器通常多人共用账号体系可能比较复杂。如果师兄用root或者另一个账号创建了一个screen会话你用自己账号执行screen -ls是看不到他的会话的。screen的会话默认归属于创建它的用户多用户之间不可见。反过来如果你们课题组共用一个公共账号那么所有人都会看到同一个会话列表。这时候随便执行screen -r可能会误进别人的会话。我见过最混乱的一次是四个人同时用一个账号跑实验某个人不小心按了screen -r恢复到了另一个人正在跑的评测任务然后直接按CtrlC把人家任务停了。在共用账号环境下唯一的规范就是会话名必须带上所有人名字或者任务名类似screen -S zhang_exp1这种。每次做任何操作前先screen -ls看清楚归属再动手。5.3 服务器重启后所有screen会话消失这是很多人忽略的一个问题screen会话保存在内存里依赖服务器上还在运行的screen进程。一旦服务器被重启所有screen会话都会消失里面的任务也会随之终止。不要指望screen能跨重启保留任务。所以我们实验室外挂了UPS重要任务通常会再加一层自启动机制或者用systemd把训练任务注册成服务。但对于日常实验比较务实的做法是训练开始前把关键信息和命令写进一个shell脚本或README万一服务器重启了能快速恢复环境和重新启动任务避免“忘记当初怎么拉起环境的”这种尴尬。另外每次长任务跑完后养成及时清理screen会话的习惯。我见过有人一个服务器上累积了几十个弃用的Detached会话列表长得根本分不清谁是谁白白消耗系统资源。5.4 快捷键与其他终端的冲突screen的快捷键默认以CtrlA作为命令前缀但很多终端软件里CtrlA有别的用途。比如在shell里CtrlA是光标跳到行首这个冲突会让第一次用screen的人非常困惑明明按了快捷键界面上却什么也没发生还莫名其妙把命令行光标移到了开头。解决方法是快速按完再松开期间不要按住不放。比如“分离”的组合是CtrlA松开这两个键再单独按一下D整体节奏要干脆。如果想彻底避免冲突也可以在~/.screenrc配置文件里改掉前缀键escape ^Bb这会把前缀键改成更少被占用的CtrlB。改动之后所有快捷键都从CtrlA变成CtrlB统一的。另外要特别注意在screen会话里使用vim时会遇到另一层映射冲突。vim的很多快捷键以数字或符号开头而screen会默认把“CtrlA后跟数字键”解释为切换窗口。需要输入这类组合时可以连续按两下CtrlAscreen就会把后一个CtrlA原样传给shell或vim再输入真正想要的字符。6. 进一步挖掘screen在科研日常里的价值6.1 多窗口管理不同任务screen另一个非常好用的能力是多窗口。一个会话里可以同时开多个窗口每个窗口独立运行一个shell进程。创建新窗口的快捷键是CtrlA然后按C切换窗口是CtrlA然后按对应数字键查看所有窗口列表是CtrlA然后按W。这个特性在跑多个对比实验时很有用。比如我可以建一个叫exp_compare的会话里面窗口0跑baseline训练窗口1跑改进模型训练窗口2放一个htop监视GPU和内存。一个会话三个窗口分开跑互不干扰想看哪个切哪个。窗口多了之后可以给窗口重命名方便辨认。在窗口里执行screen -X title window_name或者按CtrlA再按A输入新名字。这样CtrlA W列出的窗口列表一眼就能看懂。6.2 在screen会话里跑交互式程序screen会话里跑交互式程序有个天然劣势你不在终端里的时候程序无法得到键盘输入。比如你想让Python脚本中途暂停一下问你是否继续shell里常见的read -p Continue?这类交互只会卡在那里等待。解决方法是尽量避免在交互式命令中加入等待输入的逻辑把该自动化的全都自动化遇到需要配置的选项时用参数传递而不是等待交互输入。如果确实需要和运行中的进程交互可以考虑在screen会话内配合使用tmux的send-keys功能或者给程序预留一个控制管道。但对绝大多数训练任务来说让代码无人工干预地跑完才是常态。还有一个小技巧是把需要定期查看状态的程序放进screen后配合CtrlA加M快捷键可以把当前窗口设为“监视模式”窗口内容发生变化时屏幕右下角会出现提示标记。多个窗口并行跑任务时一眼就能看出哪个窗口又输出了新日志。6.3 用.screenrc做轻定制~/.screenrc是screen的配置文件活用好它能省不少心。我的配置非常简洁但每一条都解决了具体问题# 关闭启动时的欢迎信息 startup_message off # 设置状态栏显示窗口列表和系统负载 hardstatus alwayslastline hardstatus string %{b}%H | %{b}%w %%{b}%m-%d %c # 增强终端类型兼容性避免vim等程序配色异常 term screen-256color # 解除CtrlA对shell的干扰改用CtrlB escape ^Bb其中term screen-256color值得一提。很多人在screen里用vim发现颜色不对劲、语法高亮缺失大部分是终端类型没配对导致的。加上这行配置后vim和各类TUI程序的显示基本和普通SSH终端一致了。配置修改后新打开的screen会话会立即生效已经存在的旧会话不受影响。所以我会特意开一个“配置验证”会话确认新配置没问题之后再让它退出。6.4 我最后想补充的几个建议前面几条多多少少都是从踩坑里挤出来的最后再分享几点个人习惯层面的东西。第一重要任务一定要做“可恢复性”设计。也就是让你自己具备“服务器挂了、会话没了也能快速恢复任务”的能力。所有环境依赖写进requirement文件启动命令写进一键脚本数据进度定期备份。有了这些兜底screen只是工具而不是救命稻草。第二选择适合自己的工具组合。我这篇文章全程在讲screen但如果你试用后觉得tmux的快捷键更顺手、分屏更好用那完全没有问题。screen和tmux解决的是同一类问题选一个用熟就好不要两个都学个皮毛。第三日常跑任务时养成“分离前多看一眼”的习惯。在按CtrlA D之前花两秒确认训练确实正常启动、日志在正常输出、会话名没写错。这两秒钟能避免绝大多数“第二天发现啥也没跑”的事故。一年下来我已经数不清用这套工作流跑了多少轮实验但再也没有发生过合上电脑就前功尽弃的事。对于研一刚接触服务器的同学来说screen这一关真的只花半小时就能迈过去之后每一次断开重连都会感谢当时愿意折腾一下的自己。