mirror of
https://gitee.com/xmz7891/ykxmz.git
synced 2026-10-19 08:20:44 +00:00
2.1.0：网站自动抢救 + 后台抢救报告分区 + 网络热门音效 + 全量测试后台静默
按用户定的规矩，这一轮有新功能，升第二位：2.0.0 -> 2.1.0。
== 一、网站挂了会自己救 ==
用户原话：「网站还是容易挂，建议继续增加隧道稳定性，并在后台设立
检测单元，实时检测网站状态，一旦检测到网站挂了，立即启动紧急预案」。
新增 relay/monitor.sh + lanremote-monitor.timer：
每 60 秒从**公网**查一次 /v1/health（不是查 127.0.0.1）
为什么不查本机：本机 200 只说明中转进程活着，用户真正关心的是
经过 Cloudflare 边缘 + 隧道 + 本机三段之后能不能打开。实测过
隧道两条实例都掉了、本机 curl 照样 200，只有从公网测才发现 502。
连续 3 次不通才动手（这条 4G 线路本来就有 2~4% 偶发失败），
救完 10 分钟内不再动手（否则预案刚重启完隧道还没连上，
下一次检查又救一遍，来回重启反而永远连不上）。
新增 relay/rescue.sh：五级阶梯，每级做完立刻复验，好了就停
1 重启隧道 不动中转，在线设备不掉线
2 重启中转服务 设备要重连，但很快
3 重新施加网络调优 MSS / MTU 跑偏时用
4 重启无线网卡 4G / WiFi 卡死时用
5 重启整机 最后的底牌，**默认不开**（要 RESCUE_REBOOT=1）
理由：如果问题出在供电或上游线路，重启只会让恢复更慢；
而且半夜自动重启一台没人管的机器风险太大。
== 二、抢救报告 + 后台分区 ==
用户原话：「如果紧急预案未能解决，则将问题打包成 .txt，然后在
中转站设置里面加一个分区专门放还有下载这个 txt。解决后将解决问题
的方法加入紧急预案」。
* 五级都没救回来 -> 把现场（内存/进程/隧道连接数/路由和 MTU、
三份日志尾部、内核异常）整理成 rescue_reports/<时间戳>.txt
* 后台新增「抢救报告」分区，列出报告（带结论摘要），点一下下载
* 下载走单独的 /rescue/<名字>，**不发缓存头**（内容会变，
也不该让 Cloudflare 边缘留着）。和 /download/ 分开是有意的：
那个是给用户的安装包，文件名带版本号、内容永不改变，
所以敢发 604800 长缓存
* **要登录才能下** —— 报告里有内网 IP、进程表、日志尾部，
是运维信息。第一版把这条路由插在 _admin_gate() 之前，
等于匿名可下，自己查出来补上了
* 每次自动抢救成功，把「第几级奏效」写进 rescue_knowledge.md；
监测单元读它，下次同类症状优先试历史上管用的那一级
（这就是用户说的"解决后将解决问题的方法加入紧急预案"）
== 三、网络热门音效 ==
用户原话：「再加上近期网络热门音效，什么冰冰冰，啊哈哈哈哈，
各种老牧师音效，可以直接远程播放」。
**版权说明**：网上那些「冰冰冰」「啊哈哈哈」是**有版权的真实录音**
（影视片段 / 别人的作品），不能下载打包进安装包 —— 那既侵权，
也会让这个项目在 Gitee 那边直接踩线（这个仓库已经被判过一次
"内容可能含有违规信息"）。
所以：
* 内置 8 个**程序合成**的音效（正弦/方波现场算，零版权风险、
不占安装包体积）：冰冰冰 / 啊哈哈哈 / 老牧师 / 叮 / 当当当 /
警报 / 鼓点 / 弹簧。名字对着感觉来，但不是那些录音本身
* 做「自己放进来」的目录：mp3/wav 丢进 data/sfx/ 就自动出现在
列表里，照样能远程播。目录里放了一份说明
* 手表首页新增「音效」按钮，点开选一个，电脑就响
（复用现成的 showChooser，不新建面板）
协议加 sfx_list / sfx_play 两条命令。
== 四、修「安卓设置页一片空白」 ==
用户报的。根因：设置页**建好了但忘了 root.addView()** ——
showOnly() 让它 VISIBLE 也没用，它根本不在视图树里。
这类"漏挂"编译完全不报，只在运行时表现为空白。已加断言
_tests/test_watch_panels_wired.py 盯着：每个面板都必须挂到 root、
并且纳入 showOnly()。
== 五、全量测试改成后台静默 ==
用户原话：「把全量测试改为在后台静默运行不要打开任何窗口或锁屏」。
会开窗口的 6 个阶段（含开**全屏**那个）现在跑在独立的 Windows
隐藏桌面上（_tests/hidden_desktop.py）。窗口是**真的** —— 全屏、
可见、几何、Win32 枚举都真实，测试有效性一点没损失 ——
只是不在用户眼前，全屏也不会锁屏。
顺带修了一个一直在骗人的检测：判断"锁屏"时只看 OpenInputDesktop
成不成功是不对的 —— **锁屏时它同样成功**（那时输入桌面是 Winlogon）。
于是截屏类测试在锁屏时被记成 FAIL 而不是 SKIP，把真问题淹掉了
（用户电脑锁了一夜，我就是被这个误导过）。改成看输入桌面的**名字**。
现在锁屏也能跑全量：该 SKIP 的 SKIP，该跑的照跑。
== 六、顺手修的真 bug ==
* windows/lanremote/server.py 的 sfx_play 分支用了不存在的变量名 body
（应该是 msg）-> **一调就 NameError**。pyflakes 那关抓出来的，
说明"未定义名"这条检查有用。
* _build/package_remote.py 的文件白名单只有 .py/.sh/.ico，
**.service/.timer 收不进服务端 zip** -> 新机器上监测根本不启动，
而且不报错、只是静默不跑。已加。
* protocol.py 被我补丁插入了 LF 行到 CRLF 文件里 -> 行尾混用，编码审计红。
* deploy.sh 的 watchdog 块被我改锚点时吃掉了 start/say 两行
（bash -n 通过、只是少两条执行语句）—— 改完读回来核对才发现。
* _build/CHANGELOG.md 的 2.1.0 说明里写了"管理后台"，
触发对外材料清洁度检查。改成不提管理页（用户定的规矩：
对外只能提官网）。
全量回归 46 个阶段全部通过。
This commit is contained in:
xmz7891
@@ -0,0 +1,148 @@
|
||||
#!/bin/bash
|
||||
# ============================================================================
|
||||
# 网站监测单元 —— 每 60 秒看一次公网，挂了就叫紧急预案
|
||||
# ============================================================================
|
||||
#
|
||||
# 用户要求：
|
||||
# 「在后台设立检测单元，实时检测网站状态，一旦检测到网站挂了，
|
||||
# 立即启动紧急预案」
|
||||
#
|
||||
# 由 lanremote-monitor.timer 每 60 秒起来跑一次（不是常驻进程 ——
|
||||
# 小机器内存紧，定时任务比常驻守护省得多，而且崩了下一分钟自己就回来了）。
|
||||
#
|
||||
# ---------------------------------------------------------------------------
|
||||
# 为什么一定要**从公网测**，不能测 127.0.0.1
|
||||
# ---------------------------------------------------------------------------
|
||||
#
|
||||
# 本机 200 只说明中转进程活着。用户真正关心的是"打开
|
||||
# https://relay.xxmxxs.top 能不能出页面" —— 那要经过
|
||||
# Cloudflare 边缘 + 隧道 + 本机三段。
|
||||
#
|
||||
# 实测过的场景：隧道两条实例都掉了，本机 curl 127.0.0.1 照样 200，
|
||||
# 但公网 502。只看本机的话，监测单元永远不会报警。
|
||||
#
|
||||
# ---------------------------------------------------------------------------
|
||||
# 防抖与冷却
|
||||
# ---------------------------------------------------------------------------
|
||||
#
|
||||
# * 连续失败 FAIL_THRESHOLD 次才动手（默认 3 次 ≈ 3 分钟）。
|
||||
# 实测这条 4G 线路本来就有 2~4% 的偶发失败，一次就救会天天瞎折腾。
|
||||
#
|
||||
# * 救过一次之后 COOLDOWN 秒内不再救（默认 600 = 10 分钟）。
|
||||
# 否则预案刚重启完隧道、还没连上，下一次检查又判失败、又救一遍，
|
||||
# 来回重启反而永远连不上。
|
||||
#
|
||||
# ---------------------------------------------------------------------------
|
||||
# 知识库
|
||||
# ---------------------------------------------------------------------------
|
||||
#
|
||||
# rescue.sh 每次救成功都会把"第几级奏效"写进 rescue_knowledge.md。
|
||||
# 这里读出来，如果历史上某一级反复奏效，就把它记下来传给预案，
|
||||
# 预案可以据此跳过前面没用的级别（见 rescue.sh 的 PREFER_STEP）。
|
||||
#
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
set -u
|
||||
|
||||
RELAY_DIR="${RELAY_DIR:-/root/lanremote-relay}"
|
||||
PUBLIC_URL="${PUBLIC_URL:-https://relay.xxmxxs.top}"
|
||||
|
||||
FAIL_THRESHOLD="${FAIL_THRESHOLD:-3}" # 连续失败几次才动手
|
||||
COOLDOWN="${COOLDOWN:-600}" # 救完之后多少秒内不再救
|
||||
CHECK_TIMEOUT="${CHECK_TIMEOUT:-12}" # 单次检查超时（秒）
|
||||
|
||||
STATE="$RELAY_DIR/monitor_state.txt"
|
||||
LOG="$RELAY_DIR/monitor.log"
|
||||
LOCKFILE="/tmp/lanremote-monitor.lock"
|
||||
|
||||
# 同时只跑一个（timer 到点时上一次可能还没跑完）
|
||||
if ! mkdir "$LOCKFILE" 2>/dev/null; then
|
||||
exit 0
|
||||
fi
|
||||
trap 'rmdir "$LOCKFILE" 2>/dev/null' EXIT
|
||||
|
||||
log() { echo "$(date '+%F %T') $*" >> "$LOG"; }
|
||||
|
||||
# ---- 读状态（连续失败次数 / 上次抢救时间）----
|
||||
FAILS=0
|
||||
LAST_RESCUE=0
|
||||
if [ -f "$STATE" ]; then
|
||||
FAILS=$(grep -m1 '^fails=' "$STATE" 2>/dev/null | cut -d= -f2)
|
||||
LAST_RESCUE=$(grep -m1 '^last_rescue=' "$STATE" 2>/dev/null | cut -d= -f2)
|
||||
FAILS=${FAILS:-0}
|
||||
LAST_RESCUE=${LAST_RESCUE:-0}
|
||||
fi
|
||||
NOW=$(date +%s)
|
||||
|
||||
# ---- 检查公网 ----
|
||||
CODE=$(curl -s -o /dev/null -w '%{http_code}' --max-time "$CHECK_TIMEOUT" \
|
||||
"$PUBLIC_URL/v1/health" 2>/dev/null)
|
||||
DUR=$(curl -s -o /dev/null -w '%{time_total}' --max-time "$CHECK_TIMEOUT" \
|
||||
"$PUBLIC_URL/v1/health" 2>/dev/null)
|
||||
DUR=${DUR:-0}
|
||||
|
||||
write_state() {
|
||||
{
|
||||
echo "fails=$1"
|
||||
echo "last_rescue=$2"
|
||||
echo "last_code=$CODE"
|
||||
echo "last_check=$NOW"
|
||||
echo "last_dur=$DUR"
|
||||
} > "$STATE"
|
||||
}
|
||||
|
||||
if [ "$CODE" = "200" ]; then
|
||||
if [ "$FAILS" != "0" ]; then
|
||||
log "公网恢复（HTTP 200，${DUR}s）—— 之前连续失败 $FAILS 次"
|
||||
fi
|
||||
# 只在状态变化时记一行，避免日志被 60 秒一条刷爆（460MB 机器）
|
||||
PREV=$(grep -m1 '^last_code=' "$STATE" 2>/dev/null | cut -d= -f2)
|
||||
[ "$PREV" != "200" ] && log "公网正常（HTTP 200，${DUR}s）"
|
||||
write_state 0 "$LAST_RESCUE"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# ---- 失败：累加计数 ----
|
||||
FAILS=$((FAILS + 1))
|
||||
log "公网异常 第 $FAILS 次（HTTP ${CODE:-无响应}，${DUR}s）"
|
||||
write_state "$FAILS" "$LAST_RESCUE"
|
||||
|
||||
if [ "$FAILS" -lt "$FAIL_THRESHOLD" ]; then
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# ---- 到阈值了，看冷却 ----
|
||||
SINCE=$((NOW - LAST_RESCUE))
|
||||
if [ "$LAST_RESCUE" != "0" ] && [ "$SINCE" -lt "$COOLDOWN" ]; then
|
||||
log " 已经连续失败 $FAILS 次，但距上次抢救只过了 ${SINCE}s（冷却 ${COOLDOWN}s），先不动手"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# ---- 读知识库，看历史上哪一级最常奏效 ----
|
||||
HINT=""
|
||||
if [ -f "$RELAY_DIR/rescue_knowledge.md" ]; then
|
||||
HINT=$(grep -oE '第 [0-9] 级奏效' "$RELAY_DIR/rescue_knowledge.md" 2>/dev/null \
|
||||
| sort | uniq -c | sort -rn | head -1 | grep -oE '[0-9]' )
|
||||
fi
|
||||
|
||||
log "连续失败 $FAILS 次，启动紧急预案${HINT:+（知识库提示：第 $HINT 级常奏效）}"
|
||||
|
||||
# 记下"这次救了"（在救之前记，防止预案自己崩了导致无限重试）
|
||||
write_state "$FAILS" "$NOW"
|
||||
|
||||
# 调预案。给足够长的时间（五级 + 各自的等待，最长可能 3 分钟）
|
||||
if [ -n "$HINT" ]; then
|
||||
RESCUE_PREFER_STEP="$HINT" timeout 300 bash "$RELAY_DIR/rescue.sh" \
|
||||
"监测单元：公网连续 $FAILS 次不通" >> "$LOG" 2>&1
|
||||
else
|
||||
timeout 300 bash "$RELAY_DIR/rescue.sh" \
|
||||
"监测单元：公网连续 $FAILS 次不通" >> "$LOG" 2>&1
|
||||
fi
|
||||
RC=$?
|
||||
|
||||
if [ "$RC" = "0" ]; then
|
||||
log " 预案完成：已恢复"
|
||||
else
|
||||
log " 预案完成：仍未恢复（退出码 $RC），报告在 rescue_reports/"
|
||||
fi
|
||||
exit 0
|
||||
Reference in New Issue
Block a user