2.1.1：修一个会让网站整个挂掉的死锁（「网站容易挂」的真因）

2.1.0 的服务端包里带着这个死锁，所以要单独发一版让部署的人拿到修好的包。

== 死锁 ==

    lanremote-nettune.service   Before=lanremote-tunnel.service
    net-tune.sh 第 4 步         systemctl restart lanremote-tunnel

  nettune 在**自己还没结束**的时候去 restart 一个"必须等自己结束
  才能启动"的服务 -> systemd 判定顺序冲突 -> restart 永不返回
  -> nettune 卡在 activating -> 隧道被 Before= 挡着起不来 -> 公网 530。

  设备上实测卡了 9 分半（CGroup 里能看到 net-tune.sh 下面挂着
  一个 etime 09:32 的 systemctl restart lanremote-tunnel）。
  journalctl 里只有 nettune 停在 activating、**一句报错都没有**；
  手动跑 net-tune.sh 却完全正常（那时没有 Before= 约束）。
  是靠这次新加的监测单元抓到的（fails=3 / last_code=530）。

== 改法 ==

  unit 加 Environment=NETTUNE_SERVICE_CALL=1，脚本据此跳过第 4 步。
  第 4 步只在人工重跑时才有意义（改完 MTU/MSS 让已建隧道用上新参数），
  开机时顺序就是调优先、隧道后，不需要它。

  三处都改了：net-tune.sh 认开关；deploy.sh / install.sh 生成的 unit 带上它。

  没选 systemctl restart --no-block：那只是把阻塞变异步，开机时仍然
  做一次无谓重启（隧道刚起来就被停掉），也没解决"不该在开机时重启"。

== 为什么以前没暴露 ==

  设备上那份旧 unit 的 ExecStart 里有 iptables ... || ...，
  systemd 不支持 ||，所以它在第 2 条 ExecStart 就报错退出，
  根本没走到会死锁的那一步。把 unit 换成正确形状之后才露出来。

_build/CHANGELOG.md

@@ -1,3 +1,33 @@
+## 2.1.1
+
+- **修一个会让网站整个挂掉的死锁**（这是「网站还是容易挂」的真因）。
+
+  在装了中转服务器的那台机器上，网络调优服务和隧道之间会互相等：
+
+  ```
+  网络调优服务（nettune）:  "我必须先于隧道启动完"
+  网络调优脚本第 4 步:      "重启隧道，让新参数生效"     ← 卡在这里
+  ```
+
+  它在**自己还没结束**的时候去重启一个「必须等自己结束才能启动」的服务，
+  系统判定成顺序冲突，那一步就永远不返回。结果网络调优一直卡在
+  「正在启动」，隧道被挡着起不来，**公网就是 530**。
+
+  实测卡了 9 分半。而且**日志里一句报错都没有**，
+  手动跑那个脚本却完全正常（那时没有顺序约束）——
+  所以特别难查，是靠这次新加的监测单元抓到的
+  （它记录到「连续 3 次不通」并把现场留了下来）。
+
+  **改法**：让脚本知道「这次是服务在调我」，那就跳过重启隧道那一步。
+  开机时本来也不需要它 —— 顺序就是调优先、隧道后，那时隧道还没起来。
+
+  > 这个坑以前一直藏着：设备上那份旧的服务定义里有一个写法错误，
+  > 导致它在更早的步骤就报错退出了，反而没走到会死锁的那一步。
+  > 把服务定义改对之后，死锁才露出来。
+
+- 另外这一版的服务端包也带上了上面那个修复。
+  **2.1.0 的服务端包是有问题的**，请用 2.1.1 重新部署。
+
 ## 2.1.0
 
 - **网站挂了会自己救**：中转服务器上常驻一个监测单元，每 60 秒从**公网**