16、【Ubuntu】【VSCode】VSCode 断联问题分析：问题解决
【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Ubuntu】【VSCode】VSCode 断联问题分析：UID 补充
最后补充了下 UID 的说明，下面回归问题本身
VSCode 断联问题
回归问题本身
首先，这里是尝试用 xdg-open 命令去打开一个链接，前面一系列 blog 【OS】【Nuttx】【周边】效果呈现方案解析：strace 日志解析（十一） 分析了由于是 SSH 客户端远程登录，没有桌面应用可以用来打开链接，此时检测到当前环境为 VSCode Server，便尝试用 VSCode IPC Socket 与 VScode 主进程取得联系，想通过 SSH 隧道反向从 Windows 打开该链接，然后结果在连接 VSCode IPC Socket 时出了问题，发现连接不上了
然后用 lsof 命令查询当前登录用户下，已建立的 Socket 通信，发现有如下这些
虽然这里有很多 Socket 文件，却没有报错中提到的以 aed2 结尾的 Socket 文件
从这儿可以得出一个结论：当远程的 VS Code Server 试图通过本地 IPC Socket 与主进程通信，但这个 IPC Socket 文件不存在
这个 IPC Socket 文件命名来源于环境变量 VSCODE_IPC_HOOK_CLI ，在终端输入
echo $VSCODE_IPC_HOOK_CLI
可以打印出当前终端所使用的 VSCode IPC Socket 如下（问题出现时的环境太久已经被破坏了，现在是新的环境，不影响分析说明）
关于 VSCODE_IPC_HOOK_CLI 提几个点：
- 首先，
VSCODE_IPC_HOOK_CLI是与终端会话相关的环境变量，不是全局的，只在通过 VS Code Remote-SSH 启动的终端中被设置，并且只对那个终端及其子进程有效，比如上面那个终端的 Socket 文件是以9689结尾的，如果再新建一个新的 Bash Shell
再打印，可以看到就是一个全新的 Socket 文件了
- 另外，
VSCODE_IPC_HOOK_CLI是由 VSCode 的远程服务器组件（VSCode-Server） 在客户端通过 Remote-SSH 插件连接，或新建终端时，动态注入到集成终端的启动环境中的，VSCode-Server 会为每个特定终端会话创建一个唯一，临时的 Socket 文件，并将这个 Socket 文件的路径再通过环境变量VSCODE_IPC_HOOK_CLI写入到该终端进程的环境中，然后 VSCode 就可以使用这个 Socket 文件与该终端内的进程进行双向通信
VSCODE_IPC_HOOK_CLI 指向一个不存在的的 Socket 文件路径，说明这个终端曾经通过 VS Code Remote-SSH 连接过，VSCode-Server 注入了这个变量，但后来 VSCode-Server 与 Windows VSCode 远程客户端断开了连接，这个终端的 Socket 文件被删除，但 Shell 还在运行（Shell 进程本身被设计为在断开后继续运行，防止意外中断长时间运行的任务，影响用户体验），环境变量仍然保留在内存中，这就是残留环境变量问题，相当于现在的终端是一个僵尸会话：该终端保留着旧的环境，但对应的 IPC 通道已经不存在了
所以解决办法就是关闭原来的 Shell 进程，比如主动输入命令 exit ，或者光标操作删除终端
然后退出 Windows VSCode 客户端，然后重新进入，就可以用新的 IPC 通道进行通信了，或者直接新建个终端也是可以的
当然，未来这个 BUG 也可能被修复掉，通过终端生命周期管理，ok，先分析到这里，下篇 blog 继续