283d530f82
上一次部署里旧 worker 没随 master 退出，一直占着 8123。新 master 启动、 打印 started、然后什么都不服务——日志每一行看起来都正常，站点却是挂的。 - stop.sh 等进程真正退出，超时后 -9 - start.sh 停完等端口释放，起来后 curl 健康检查通过才算成功，否则返回非零 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
48 lines
1.4 KiB
Bash
Executable File
48 lines
1.4 KiB
Bash
Executable File
#!/bin/sh
|
|
# Start Garmin Health Lab. Safe to run repeatedly: an already-running
|
|
# instance is stopped first. Intended for DSM Task Scheduler (boot-up).
|
|
APP="$(cd "$(dirname "$0")" && pwd)"
|
|
cd "$APP/backend" || exit 1
|
|
|
|
GUNICORN="$APP/backend/.venv/bin/gunicorn"
|
|
|
|
# Stop whatever is already running, then WAIT for the port to actually be
|
|
# free. Killing only the pid in app.pid left orphaned workers holding :8123;
|
|
# the new master then started, reported success, and served nothing — the
|
|
# site was down while every log line looked normal.
|
|
"$APP/stop.sh" >/dev/null 2>&1
|
|
i=0
|
|
while [ $i -lt 20 ]; do
|
|
pgrep -f "$GUNICORN" >/dev/null 2>&1 || break
|
|
sleep 1
|
|
i=$((i + 1))
|
|
done
|
|
pkill -9 -f "$GUNICORN" 2>/dev/null
|
|
sleep 1
|
|
|
|
mkdir -p "$APP/logs"
|
|
# --timeout 300: an AI generation against the reasoning model can run for
|
|
# minutes, and gunicorn kills a worker that looks stuck before then.
|
|
nohup "$GUNICORN" \
|
|
--workers 2 --threads 4 --timeout 300 \
|
|
--bind 0.0.0.0:8123 \
|
|
--access-logfile "$APP/logs/access.log" \
|
|
--error-logfile "$APP/logs/error.log" \
|
|
wsgi:app > "$APP/logs/stdout.log" 2>&1 &
|
|
|
|
echo $! > "$APP/app.pid"
|
|
|
|
# Confirm it is actually serving rather than just running.
|
|
i=0
|
|
while [ $i -lt 25 ]; do
|
|
if curl -sf -m 2 -o /dev/null http://127.0.0.1:8123/api/health/status; then
|
|
echo "started pid $(cat "$APP/app.pid") on :8123"
|
|
exit 0
|
|
fi
|
|
sleep 1
|
|
i=$((i + 1))
|
|
done
|
|
|
|
echo "FAILED to serve on :8123 — see $APP/logs/error.log" >&2
|
|
exit 1
|