 opendance
|
ea58520fc2
|
fix(deploy): .env 中带空格的值未加引号导致 install.sh 以 127 失败
现象：
./deploy/.env: line 53: Miku.pmx: command not found
[install] 第 53 行执行失败（退出码 127）
根因：deploy/.env.example 的 MODEL_CONVERT_PMX=Hatsune Miku.pmx 值含空格
却没加引号，install.sh 用 `set -a; . deploy/.env` 载入时被切成
「赋值 + 命令」，Miku.pmx 被当成命令执行。
修复：
1. 模板改为 MODEL_CONVERT_PMX="Hatsune Miku.pmx"（占位符值同样加引号）；
2. 新增 deploy/env-lib.sh：.env 语法预检，install.sh / ctl.sh 在 source
之前检查，报错给出「哪一行 / 原文 / 改法」， 与反引号建议单引号；
3. install.sh 的 ERR trap 补上出错文件名（lineno 属于被 source 的 .env，
只报行号无法定位）；
4. 新增 test/env-file.spec.ts 12 项回归测试，锁住「模板可被 shell 原样载入」；
5. 版本升到 0.2.1，README(.md/.txt)/DSH.md 补 .env 写法约定、FAQ 与测试数量。
|
2026-09-15 22:26:58 +08:00 |
|
 zijunchiang
|
caca7672cb
|
fix(release): 修复发布包缺失 storage 模块，并加入产物完整性校验
用户实测：用发布包部署后启动报 MODULE_NOT_FOUND
at dist/models/models.module.js:13 require('../storage/storage.module')
根因：package-release.sh 的 rsync 用了 --exclude 'storage'。该模式匹配
**任意层级**的同名目录，把源码目录 src/storage/ 与编译产物 dist/storage/
一并排除——发布包里完全没有 storage 模块，服务必然起不来。
这与第一阶段 .gitignore 里 'storage/' 误伤 src/storage/ 是同一类错误，
本项目第二次踩到。
修复：
- 排除模式全部锚定到 web-server 根：'/storage/'、'/data/'、'/tmp/'、
'/.env'、'/admin/'，不再匹配嵌套同名目录
- 新增产物完整性校验（打包后自动执行，失败即删除压缩包）：
src 下每个 .ts 必须有对应 dist/*.js；关键文件清单齐全；
不得混入 node_modules / 真实 .env / 运行时存储 / keystore
- ctl.sh 补上缺失的 warn 函数（line 120: warn: command not found）
实测：
- 对照实验：排除模式改回 'storage' 后校验准确报出缺少
dist/storage/storage.module.js 并删除压缩包，退出码 1
- 新包端到端：解压 → npm ci --omit=dev（213 包）→ 启动 → /health 200、
MariaDB 已连接、迁移 0、catalog/songs/models/motions 全部 200
|
2026-09-15 00:54:22 +08:00 |
|
|
zijunchiang
|
c092b833fb
|
fix(deploy): 支持无 systemd 的环境，并修复降级路径的两个真实缺陷
用户实测：服务器没有 systemctl，install.sh 直接报错退出。
原错误信息本身也是错的（建议 SKIP_NGINX=1，但那只跳过 nginx，仍走 systemctl）。
进程管理改为四层降级：
systemd → OpenRC → SysVinit → nohup 后台进程（deploy/ctl.sh）
- 新增 deploy/ctl.sh：start/stop/restart/status/logs，PID 文件 + 进程名双重判定
- 新增 deploy/openrc/opendance-api、deploy/initd/opendance-api
- 无 init 系统时写 crontab @reboot 实现开机自启
- uninstall.sh 同步支持四种模式清理（原先只处理 systemd，会留下运行中的进程）
- 汇总输出按实际初始化系统给出对应运维命令
测试中发现并修复降级路径的两个真实缺陷：
1. nohup 无法调用 shell 函数
实测退出码 127 且什么都不执行
（nohup 是外部命令，只能执行可执行文件）。
这会让无 systemd 的降级路径完全失效——服务根本起不来。
改为按 runuser / setpriv / su 显式拼接成外部命令后再 nohup。
另加启动后 1 秒存活检测，失败立即打印日志，不再白等 30 秒。
2. find_pids 在无进程时返回一个空格
在空输入下仍会执行一次 echo，输出空行，
最终得到 " "；调用方 [ -n ... ] 会判为「有进程」，
导致 start 直接跳过、status 谎报运行中。改为纯 bash 拼接，空时返回空串。
实测（真实 API 进程，端口 3100）：
start → 健康检查 200，PID 正确
重复 start → 识别已在运行，进程数保持 1
status → 运行中
restart → 新 PID，健康检查 200
stop → 无残留进程，端口释放
无 process 时 find_pids 返回空串，is_running=false
|
2026-09-15 00:34:52 +08:00 |
|