GarminHealthLab

ericwyuan/GarminHealthLab

Fork 0

Commit Graph

Author	SHA1	Message	Date
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	15fba8c25c	feat: NAS 部署 + auth-hub 认证 + 同步逻辑修复部署: - 后端 Python/Flask，数据层可插拔 SQLite/MariaDB - NAS 部署路径 /volume1/web/garmin-health-lab，端口 8124 - Gunicorn 生产服务器 (2 workers / 4 threads) - 开机自启脚本 deploy/S99garmin.sh - frp 隧道甲骨文 8124 → NAS 8124，外网访问 - 前端构建产物纳入版本管理 (backend/static/) 认证: - auth-hub OAuth2/OIDC 统一登录接入 - 新建 NAS 专用 client，注册内外网回调地址 - 前端 LoginPage 支持回调路由 /auth/callback - 数据同步页增加 Garmin 邮箱输入框同步逻辑修复: - 自动同步调度器读取用户 history_days 设置，不再固定 2 天 - 前端 0（全部历史）不再被 \|\| 吞掉，改为 ?? 处理 - 后端路由和 sync_data 中 0 不再被当成 falsy 回退默认值 - sync_data 和调度器中 0 → 730 天（全部历史=最大范围） - 已同步天数显示数据库实际总天数 (totalDays) - 历史范围新增「自上次同步」增量选项 (days=-1) - 后端 settings.py HISTORY 添加 -1 值项目文档: - 创建 PROGRESS.md 跟踪项目进度	2026-09-01 07:39:09 +08:00
ericwyuan	283d530f82	fix(deploy): 启动脚本等端口真正释放，并确认服务可用后才报成功上一次部署里旧 worker 没随 master 退出，一直占着 8123。新 master 启动、打印 started、然后什么都不服务——日志每一行看起来都正常，站点却是挂的。 - stop.sh 等进程真正退出，超时后 -9 - start.sh 停完等端口释放，起来后 curl 健康检查通过才算成功，否则返回非零 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-08-24 04:23:05 +08:00

Author

SHA1

Message

Date

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

15fba8c25c

feat: NAS 部署 + auth-hub 认证 + 同步逻辑修复

部署:
- 后端 Python/Flask，数据层可插拔 SQLite/MariaDB
- NAS 部署路径 /volume1/web/garmin-health-lab，端口 8124
- Gunicorn 生产服务器 (2 workers / 4 threads)
- 开机自启脚本 deploy/S99garmin.sh
- frp 隧道甲骨文 8124 → NAS 8124，外网访问
- 前端构建产物纳入版本管理 (backend/static/)

认证:
- auth-hub OAuth2/OIDC 统一登录接入
- 新建 NAS 专用 client，注册内外网回调地址
- 前端 LoginPage 支持回调路由 /auth/callback
- 数据同步页增加 Garmin 邮箱输入框

同步逻辑修复:
- 自动同步调度器读取用户 history_days 设置，不再固定 2 天
- 前端 0（全部历史）不再被 || 吞掉，改为 ?? 处理
- 后端路由和 sync_data 中 0 不再被当成 falsy 回退默认值
- sync_data 和调度器中 0 → 730 天（全部历史=最大范围）
- 已同步天数显示数据库实际总天数 (totalDays)
- 历史范围新增「自上次同步」增量选项 (days=-1)
- 后端 settings.py HISTORY 添加 -1 值

项目文档:
- 创建 PROGRESS.md 跟踪项目进度

2026-09-01 07:39:09 +08:00

ericwyuan

283d530f82

fix(deploy): 启动脚本等端口真正释放，并确认服务可用后才报成功

上一次部署里旧 worker 没随 master 退出，一直占着 8123。新 master 启动、
打印 started、然后什么都不服务——日志每一行看起来都正常，站点却是挂的。

- stop.sh 等进程真正退出，超时后 -9
- start.sh 停完等端口释放，起来后 curl 健康检查通过才算成功，否则返回非零

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

2026-08-24 04:23:05 +08:00

3 Commits