revel 应用用 supervisor 保活需严格配置：command 必须为绝对路径，显式设置 directory = /opt/myapp，startsecs ≥10（冷启动需3–8秒），文件放 /etc/supervisord.d/ 下且后缀为 .ini，app.mode 必须为 prod。
Revel 框架应用用 Supervisor 保活，关键不在 Revel 本身，而在启动方式、路径权限和进程就绪判断——配错 startsecs 或漏写 directory，进程会反复闪退，supervisorctl status 显示 STARTING 后秒变 STOPPED。
Revel 应用必须用绝对路径启动，不能依赖当前工作目录
Revel 编译后的二进制文件（如 myapp）默认不带内置工作目录，启动时若没指定 directory，它会在 Supervisor 的根路径（通常是 / 或 /root）下找 conf/app.conf 和 views/，必然失败。
-
command必须是绝对路径，例如/opt/myapp/myapp，不能写./myapp或myapp - 必须显式配置
directory = /opt/myapp，确保 Revel 能正确加载配置、模板和静态资源 - 如果用
revel run开发模式，不要直接丢进 Supervisor——它会监听源码变化并热重载，不适合生产；应先revel build出可执行文件再托管
startsecs 设太小会导致 Revel 进程被误判为启动失败
Revel 应用冷启动包含路由注册、模块初始化、DB 连接池建立等步骤，从执行 myapp 到真正监听端口常需 3–8 秒。Supervisor 默认 startsecs=1，意味着只要 1 秒内没输出或没进入运行态，就判定启动失败并杀掉重试。
- 务必把
startsecs改成10（单位：秒），给 Revel 留出足够初始化时间 - 配合
startretries=3，避免因 DB 临时不可用导致无限循环重启 - 可加
autorestart=unexpected，让正常exit 0（比如主动 reload）不触发重启，只对崩溃或非预期退出响应
常见报错：supervisorctl status 显示 FATAL 或 BACKOFF
这类状态基本锁定在环境缺失或权限问题，不是 Revel 代码 bug。
-
FATAL：通常因user配置的用户不存在，或该用户对directory、日志路径无读/执行权限；建议新建专用用户（如revel-user），而非用root -
BACKOFF：启动失败后指数退避重试，大概率是command执行失败（比如缺少lib）、environment未声明PATH或LD_LIBRARY_PATH，或stdout_logfile路径不可写 - 务必检查
stderr_logfile内容，Revel 启动失败时错误信息全在里面，比supervisord.log更直接
配置文件放哪、后缀怎么写，不同系统有硬性区别
Supervisor 不会自动扫描任意目录，路径和扩展名错一个字，reread 就完全看不到你的配置。
- CentOS/RHEL（含 Rocky/AlmaLinux）：配置必须放在
/etc/supervisord.d/下，且文件名以.ini结尾，例如/etc/supervisord.d/myapp.ini - Debian/Ubuntu：默认读
/etc/supervisor/conf.d/，且要求.conf后缀，例如/etc/supervisor/conf.d/myapp.conf - 改完配置后，顺序执行：
supervisorctl reread→supervisorctl update，缺一不可；只reread不update，新配置不会生效
最易被忽略的是 Revel 的静态资源路径和 app.conf 中的 app.mode 设置——Supervisor 启动的进程没有终端交互能力，app.mode = dev 可能触发调试行为导致异常退出；上线前务必确认是 prod 模式，且所有路径都用绝对路径硬编码或通过 environment 注入。
