Reports: verify MX8500 EasyTier restart and close TR3000 reboot follow-up

reports/2026-10-30-cudy-tr3000-adguardhome-memory.md

@@ -34,7 +34,7 @@
 | 17:54 – 17:56 | — | 122 MB | SSH 和 Tailscale ping 均超时约 1 分钟，负载升到 9.9；没有重启 |
 | 17:57（修复后） | 234 MB | 0.2 MB | `/tmp` 从 135 MB 降到 5.4 MB |
 
-开机后的 6.5 小时里路由器重启过一次，原因查不到：没有 pstore，当前日志中也没有 OOM 记录。按查询日志的增长速度，内存迟早会被耗尽，那次重启很可能就是这个原因，但没有证据。
+上述内存数据证明查询日志占用较大，但不能据此认定此前重启由内存耗尽引起。
 
 17:54 的卡顿还有一个人为因素：排查时一条 `tail -20000 querylog.json` 命令超时被中断，但路由器上的 `tail` 进程没有退出，一直以 R 状态占用 CPU。它还持有已删除的 `querylog.json`，导致删除后约 112 MB 内存迟迟没有释放。手动 `kill` 后内存才回来。以后在路由器上分析大文件，要先复制一小段出来再处理，并确认远端进程已退出。
 
@@ -226,9 +226,9 @@ uci commit dhcp
 
 ### 解决：重启路由器
 
-18:33 执行 `reboot`。约 2.5 分钟后路由器**又重启了一次**，原因不明：`/sys/fs/pstore` 为空，没有 panic 记录；日志从新的一次开机开始，前一次开机的日志已丢失。可能是手动重启，也可能是硬件看门狗（`mtk-wdt`，31 秒）复位。如果以后再出现无故重启，需要先把日志写到持久存储再查。
+18:33 执行 `reboot`，用户随后确认恢复正常。后续重启现象用户倾向于供电原因，按用户要求不列为软件排查待办；供电原因尚未通过更换电源对照验证。
 
-第二次开机后（18:35:40 左右）：
+重启后检查结果（启动早期墙上时钟会校准，以下以状态和日志事件为准）：
 
 | 项目 | 结果 |
 |---|---|
@@ -255,10 +255,12 @@ uci commit dhcp
 | `ratelimit` | 20 | 改为 0（`wan` 区入站同样是 `REJECT`） |
 | 查询日志 | 90 天，11.5 小时 59 MB（`/tmp/lib/adguardhome/data`），绝大部分是本机 EasyTier 的解析 | 改为 6 小时轮转，并忽略三个 EasyTier 对端域名 |
 | 内存 | 887 MB 总量，修改前可用 243 MB；`/tmp` 61 MB → 5 MB | — |
-| EasyTier | 配置 17:48 改过，但进程没有重启，仍在重试 `wss://home…`、`wss://cloud…`、`wss://backup…`；配置里还保留着两条 `wss://…:0` | 未改，需要用户确认后重启 |
+| EasyTier | 初查时配置 17:48 改过但未重启；配置仍有两条 `wss://…:0` | 18:43 按用户要求重启，cloud、backup 两条 TCP 均为 Connected，旧 home 连接器消失；两条 WSS 仍为 Connecting，保留待办 |
 
 MX8500 备份：`/root/adguardhome.yaml.bak`。修改后 DNS 正常，53 端口在 20 秒内恢复监听。
 
+EasyTier 收尾验证：执行 `/etc/init.d/easytier restart`，启动初期 CLI 的 RPC 端口尚未就绪，随后查询成功。核心进程 PID 从 5950 变为 5638；`easytier-cli peer` 能列出 CloudCone、Mac mini、TR3000 等节点。本次重启加载现有配置，没有修改 peer 地址。
+
 ## 回滚
 
 ```sh