ericwyuan
|
14b6bbecb4
|
fix(deploy): 群晖没有 pgrep，那三处「守卫」一直是空转
上一版给 push.sh 加的 pid 比对刚跑就露馅了：`sh: pgrep: command not found`，
于是 BEFORE 和 AFTER 都是空字符串，`[ -n "$BEFORE" ]` 直接跳过检查——我刚加
的安全网自己就是个摆设。
顺手查了一圈，stop.sh 和 start.sh 里同样的 pgrep 也一直在空转：
- stop.sh 的 `pgrep ... || exit 0` 每次都以 127 失败，永远匹配不到那个提前
返回，所以每次停服都白等满 15 秒，也从没真正确认过残留 worker 已经没了。
- start.sh 的等待循环同理，白等 20 秒。
DSM 有 pkill 没有 pgrep，而且非特权的 ps 看不见 root 起的进程（服务是开机
以 root 启动的），两者任一都会让检查静默返回「没有」——这正是最危险的答案，
因为它长得和「已经停干净了」一模一样。
- push.sh 改用 `sudo ps -eo pid,args | grep`；并且 AFTER 为空时直接报错退出，
不再把「看不见」当成「通过」
- stop.sh / start.sh 改用 `ps -eo args | grep -q`
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 14:34:27 +08:00 |
|
ericwyuan
|
f6687d2b5d
|
fix(deploy): push.sh 报「部署成功」，但跑的还是旧代码
服务是开机时以 root 起的（DSM 任务计划 → S99garmin.sh），所以 logs/
error.log 和 access.log 归 root。以 ericwyuan 重启会立刻失败——gunicorn
连自己的错误日志都打不开；而 stop.sh 同样杀不掉 root 进程，于是旧 master
继续占着 :8124，start.sh 的健康检查看到 200，高高兴兴报了「started」。
这次 AI 教练部署就撞上了：文件推上去了，接口却一直 404，查了半天才发现
在跑的是几小时前那个进程。
- 重启改走 sudo，和服务实际的运行身份一致（密码问一次，或走 NAS_PASSWORD）
- 健康检查加一条：只有 200 不算数——那正是旧 master 会给的答案。比对重启
前后 gunicorn 的 pid，没变就报错退出
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 14:11:17 +08:00 |
|
ericwyuan
|
4d55fb4776
|
chore(deploy): 别把 macOS 的 xattr 塞进 tar，群晖读不懂只会刷警告
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 09:09:21 +08:00 |
|
ericwyuan
|
1c48435b9d
|
chore(deploy): NAS 的 ssh 端口是 2222
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 09:05:35 +08:00 |
|
ericwyuan
|
41b7ae82e4
|
fix(sync): 「全部历史」真的拉全部历史，自动同步不再每次静默失败
四个独立的 bug 叠在一起，表现为「只同步两天、没有进度」：
* 前端 `...(days ? { days } : {})` 把 days=0 当成未传。「全部历史」
存的就是 0，请求体里根本没有 days，后端退回 7 天默认值。
* scheduler 用 `s[0]` 读 query_one 返回的 dict，抛 KeyError 后被
per-account 的 except 吞掉。只要用户存过一次设置，每 30 分钟的
自动同步就一次都没成功过——库里那 2 天全是手动点出来的。
* 增量同步查 `health_daily`（表其实叫 health_data），后台线程直接
死掉，状态永远卡在 syncing，进度条不动。
* UI 完全不看 /sync 的返回值，rate_limited 时按钮点了没反应；轮询
结束时又把 rate_limited 归进 else 分支报「同步完成」。
顺带：
* 日循环遇到 429 立即退避并保留已拉到的天数，而不是当成「跳过一天」
继续往下捶 700 天——这正是之前限流死循环的来源之一。
* 定时循环显式传 SYNC_DAYS。历史范围按 UI 文案只描述手动全量同步，
让半小时一次的 tick 重拉 730 天必然把限流撞得更深。
* 短同步逐天上报进度（原来每 5 天一次，7 天的同步全程停在 0）。
* /sync 路由重复解析 body，空 body 会 None.get 崩。
* 4 个 StubGarth 缺 configure()，7 个测试在此之前一直是红的。
新增 deploy/push.sh：NAS 只认密码，脚本开一个 ssh 复用连接，密码只
输一次，后面推送 / 重启 / 健康检查全走它。不碰 .env、.venv 和数据库。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 08:11:24 +08:00 |
|