From 74f27214012597a3420de8cdab983520f96121a9 Mon Sep 17 00:00:00 2001 From: ericwyuan Date: Tue, 8 Sep 2026 07:27:22 +0800 Subject: [PATCH] =?UTF-8?q?fix(deploy):=20S99garmin.sh=20=E4=B8=A2?= =?UTF-8?q?=E4=BA=86=E5=8F=AF=E6=89=A7=E8=A1=8C=E4=BD=8D=EF=BC=8C=E9=87=8D?= =?UTF-8?q?=E5=90=AF=E4=B8=A4=E5=A4=A9=E6=B2=A1=E4=BA=BA=E5=8F=91=E7=8E=B0?= =?UTF-8?q?=E6=9C=8D=E5=8A=A1=E5=B7=B2=E7=BB=8F=E6=AD=BB=E4=BA=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 09-06 07:08 NAS 重启（DHCP 顺带把它的局域网地址从 .64 换成了 .65），佳明健康 服务再也没起来——两天后才被发现。 根因：`deploy/S99garmin.sh` 本地就没有 +x（`-rw-r--r--`，另外三个部署脚本都是 `-rwxr-xr-x`）。DSM 的 rc.d 启动器碰到一个没有执行权限的软链接目标，既不执行 也不报错，静默跳过。push.sh 用 tar 同步 deploy/ 目录会原样带走权限位，所以自 09-01 起只要重新部署一次，就会把 NAS 上（原本可能是手工修过的）可执行权限 再次覆盖回不可执行——这颗雷从那天就埋下了，直到这次重启才被踩到。 - 本地补上 S99garmin.sh 的 +x - push.sh 同步完 deploy/ 之后显式 chmod +x 三个会被开机脚本或部署流程直接 执行的文件，并断言生效——以后这个位再丢，部署会报错退出，不会再悄悄失效 到下次重启才现形 - push.sh 的默认目标 IP 也是这次连带发现的坑：硬编码的 192.168.50.64 已经 证明会被 DHCP 换掉，改成当前地址 .65 并加注释——真正的解法是给 NAS 做 DHCP 保留（MAC 90:09:d0:22:a6:33），不在这次改动范围内 现场同时处理：手动 chmod +x 后 sh start.sh 拉起服务；frpc 配置里的 localIP 硬编码着 192.168.50.64（同样的病），改成 127.0.0.1 后不再受局域网 IP 变化影响，公网已验证恢复。frpc 改动是 NAS 系统配置，不在这个仓库里， 旧文件备份在 NAS 的 /etc/frp/frpc.toml.bak-20260908。 遗留：auth-hub 注册的 LAN 回调地址还是 http://192.168.50.64:8124/auth/callback （CLAUDE.md:99），局域网内直接用 .65 访问会在登录环节被拒；公网入口不受影响。 要不要把它也换成 DHCP 保留后的固定地址，留给用户决定。 Co-Authored-By: Claude Sonnet 5 --- deploy/S99garmin.sh | 0 deploy/push.sh | 18 +++++++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) mode change 100644 => 100755 deploy/S99garmin.sh diff --git a/deploy/S99garmin.sh b/deploy/S99garmin.sh old mode 100644 new mode 100755 diff --git a/deploy/push.sh b/deploy/push.sh index a7f25d1..8608693 100755 --- a/deploy/push.sh +++ b/deploy/push.sh @@ -15,7 +15,11 @@ # Never touches .env, .venv or the database on the far side. set -e -HOST="${1:-ericwyuan@192.168.50.64}" +# DHCP-assigned and has already changed once (192.168.50.64 -> .65 on the +# 2026-09-06 reboot) — this default will go stale again after the NAS's next +# reboot unless a DHCP reservation is set for it on the router. Until then, +# pass the current IP explicitly: `./deploy/push.sh ericwyuan@`. +HOST="${1:-ericwyuan@192.168.50.65}" PORT="${2:-2222}" # Needed for the sudo restart below. Prompted for rather than stored, and only # used over the already-authenticated ssh master connection. @@ -69,6 +73,18 @@ $TAR --exclude .venv --exclude .env --exclude __pycache__ \ # them. echo "==> deploy scripts" $TAR -C "$REPO/deploy" . | sh_ "tar xzf - -C '$APP/deploy'" +# tar carries whatever bit the local file has, and it silently had none: +# S99garmin.sh lost +x at some point before this repo existed, every deploy +# since then re-clobbered the NAS's copy back to non-executable, and nothing +# noticed until a 2026-09-06 reboot left the service down for two days — +# DSM's rc.d runner does not execute a script it cannot execute, and does not +# warn either. Asserted here so a future loss of the bit fails the deploy +# instead of failing silently at the next reboot. +sh_ "chmod +x '$APP/deploy/S99garmin.sh' '$APP/deploy/start.sh' '$APP/deploy/stop.sh'" +if ! sh_ "[ -x '$APP/deploy/S99garmin.sh' ]"; then + echo "S99garmin.sh is not executable after chmod — the boot script will not run on the next reboot" >&2 + exit 1 +fi echo "==> static (cleared first, so stale JS chunks do not pile up)" if [ ! -f "$REPO/client/build/index.html" ]; then