From 05d2287fbf78e587d318bcdf344eb92a76bab31c Mon Sep 17 00:00:00 2001 From: xmz7891 Date: Thu, 8 Oct 2026 18:56:44 +0800 Subject: [PATCH] remove temp --- _build/_cmsg_deadlock.txt | 66 --------------------------------------- 1 file changed, 66 deletions(-) delete mode 100644 _build/_cmsg_deadlock.txt diff --git a/_build/_cmsg_deadlock.txt b/_build/_cmsg_deadlock.txt deleted file mode 100644 index d84225f..0000000 --- a/_build/_cmsg_deadlock.txt +++ /dev/null @@ -1,66 +0,0 @@ -修「网站容易挂」的真因：nettune 和隧道之间的死锁 - -用户报「网站还是容易挂」。查到最后是个 systemd 顺序死锁 —— -而且**是我自己引入的**（换掉设备上那份过期 unit 之后才露出来）。 - -== 死锁链条 == - - lanremote-nettune.service: - Before=lanremote-tunnel.service <- 我必须先于隧道启动完 - ExecStart=/bin/bash net-tune.sh - - net-tune.sh 第 4 步（"让已经建立的隧道用上新参数"）: - systemctl restart lanremote-tunnel <- 在这里永久阻塞 - - nettune 在**自己还没结束**的时候去 restart 一个"必须等自己结束 - 才能启动"的服务 —— systemd 判定顺序冲突，restart 一直不返回。 - - 证据（设备上抓的）： - CGroup: /system.slice/lanremote-nettune.service - ├─13388 /bin/bash net-tune.sh - └─13428 systemctl restart lanremote-tunnel - 那个 systemctl 的 etime 是 09:32 —— 卡了 9 分半。 - - 后果：nettune 一直 activating -> 隧道被 Before= 挡着起不来 -> - 公网 530。而 journalctl 里只看得到 nettune 停在 activating， - 没有任何报错，特别难查。 - -== 为什么以前没暴露 == - - 设备上原来那份 unit 的 ExecStart 里有个 iptables ... || ...， - systemd 不支持 ||，所以它**在第 2 条 ExecStart 就报错退出**， - 根本走不到"重启隧道"那一步 —— 死锁被那个 bug 遮住了。 - 我把 unit 换成正确形状之后，死锁才露出来。 - - 另一个迷惑点：**手动跑 net-tune.sh 完全正常**（输出"没有正在跑的 - 隧道，跳过"），因为手动跑时不在服务上下文里、没有 Before= 约束。 - -== 改法 == - - 第 4 步的本意是"改完 MTU/MSS 后让已建立的隧道用上新参数"， - 这个功能有用，但**只该在人工重跑时做** —— 开机时顺序本来就是 - nettune 先、隧道后，那时隧道还没起来。 - - 所以 unit 里加 Environment=NETTUNE_SERVICE_CALL=1， - 脚本看到就跳过第 4 步。三个地方都改了： - relay/net-tune.sh 认这个开关 - relay/deploy.sh 生成的 unit 带上它 - relay/install.sh 同上（老机器走的安装路径） - - 没选 systemctl restart --no-block：那只是把阻塞变异步， - 开机时仍然做一次无谓的重启（隧道刚起来就被停掉）， - 也没解决"不该在开机时重启"这个语义问题。 - -== 另外 == - - setup-monitor.sh / monitor.sh / rescue.sh 这一整套这次也真的 - 在线上跑起来并验证过了： - - 18:13:03 紧急预案启动：公网连续 3 次不通 - 18:13:07 现场已记录 + [1/5] 重启隧道 - 18:13:59 ✅ 第 1 级救回来了，公网已恢复 - 18:13:59 已把「第 1 级奏效」记进知识库 - - 死锁这次就是被监测单元抓到的（fails=3 / last_code=530）。 - -全量回归 46 个阶段全部通过。