mirror of
https://gitee.com/xmz7891/ykxmz.git
synced 2026-10-18 21:50:44 +00:00
xmz7891
3f18e6bb40
按用户定的规矩，这一轮有新功能，升第二位：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 个阶段全部通过。
93 lines
3.2 KiB
Python
93 lines
3.2 KiB
Python
# -*- coding: utf-8 -*-
|
||
r'''写监测单元的两个 systemd 单元文件。
|
||
|
||
用户要求「在后台设立检测单元」。
|
||
|
||
为什么用 timer 而不是常驻服务：
|
||
* 这台机器只有 460MB 内存，常驻 bash 循环白占一份内存
|
||
* 常驻脚本万一自己挂了就永远不检查了；timer 到点拉起来一次，
|
||
崩了下一分钟自己就回来
|
||
* 而且每次都是全新进程，不会有"跑久了状态变脏"的问题
|
||
'''
|
||
from __future__ import annotations
|
||
|
||
import sys
|
||
from pathlib import Path
|
||
|
||
ROOT = Path(__file__).resolve().parent.parent
|
||
OUT = ROOT / "relay"
|
||
|
||
SERVICE = '''[Unit]
|
||
# ykxmz 网站监测单元 —— 每 60 秒看一次公网，挂了就叫紧急预案。
|
||
#
|
||
# 由 lanremote-monitor.timer 拉起（不是常驻进程，见 timer 里的说明）。
|
||
Description=ykxmz 网站监测单元（每 60 秒检查公网，异常时启动紧急预案）
|
||
After=network-online.target
|
||
Wants=network-online.target
|
||
|
||
[Service]
|
||
Type=oneshot
|
||
# 检查本身最长 12 秒，预案最长 5 分钟，给 6 分钟余量
|
||
TimeoutStartSec=360
|
||
|
||
# ⚠ 用 bash 显式跑，别靠 shebang + 可执行位 ——
|
||
# 部署时文件权限被改掉是最常见的"脚本不执行"原因。
|
||
ExecStart=/bin/bash /root/lanremote-relay/monitor.sh
|
||
|
||
# 环境变量
|
||
# FAIL_THRESHOLD 连续失败几次才动手（默认 3 次 ≈ 3 分钟）
|
||
# COOLDOWN 救完之后多少秒内不再救（默认 600 秒）
|
||
# 不设的话：预案刚重启完隧道还没连上，下一次检查
|
||
# 又判失败又救一遍，来回重启反而永远连不上
|
||
# RESCUE_REBOOT 预案里是否允许"重启整机"这张底牌。**默认 0（不开）**。
|
||
# 想开就把下面这行的 0 改成 1 —— 但先想清楚：
|
||
# 如果问题出在供电或上游线路，重启只会让恢复更慢，
|
||
# 而且半夜自动重启一台没人管的机器风险很大。
|
||
Environment=RESCUE_REBOOT=0
|
||
Environment=FAIL_THRESHOLD=3
|
||
Environment=COOLDOWN=600
|
||
|
||
StandardOutput=append:/root/lanremote-relay/monitor.log
|
||
StandardError=append:/root/lanremote-relay/monitor.log
|
||
|
||
[Install]
|
||
WantedBy=multi-user.target
|
||
'''
|
||
|
||
TIMER = '''[Unit]
|
||
# 每 60 秒检查一次公网。
|
||
#
|
||
# 为什么是 60 秒不是 5 秒：
|
||
# 实测这条 4G 线路本来就有 2~4% 的偶发失败，检查太勤会一直看到
|
||
# "失败"（其实一两秒后自己就好了）。配合 monitor.sh 里
|
||
# "连续 3 次才动手"的防抖，实际最快 3 分钟响应，够用了。
|
||
#
|
||
# OnBootSec=90s：开机后等 90 秒再开始查。
|
||
# 隧道一般几十秒才连上，太早开始会一开机就误判、白抢救一轮。
|
||
Description=每 60 秒检查一次网站是否可用
|
||
|
||
[Timer]
|
||
OnBootSec=90s
|
||
OnUnitActiveSec=60s
|
||
AccuracySec=5s
|
||
Unit=lanremote-monitor.service
|
||
|
||
[Install]
|
||
WantedBy=timers.target
|
||
'''
|
||
|
||
|
||
def main() -> int:
|
||
(OUT / "lanremote-monitor.service").write_text(
|
||
SERVICE, encoding="utf-8", newline="\n")
|
||
(OUT / "lanremote-monitor.timer").write_text(
|
||
TIMER, encoding="utf-8", newline="\n")
|
||
for n in ("lanremote-monitor.service", "lanremote-monitor.timer"):
|
||
p = OUT / n
|
||
print(" ✓ %s（%d 字节）" % (n, p.stat().st_size))
|
||
return 0
|
||
|
||
|
||
if __name__ == "__main__":
|
||
sys.exit(main())
|