Revel应用不可直接用revel run上生产,必须由systemd托管;因其开发模式依赖终端、热重载且无崩溃自愈能力,而nohup或&仅能临时避SIGHUP,无法解决日志丢失、无监控重启、TTY依赖等根本问题。

Revel应用不能靠revel run上生产,必须交由systemd托管;否则进程一断就死、日志难查、重启无保障。
为什么Revel不能直接nohup或&后台运行
Revel默认的revel run是开发模式,会监听源码变化、热重载、输出调试信息到终端——这些行为在后台不可控。用nohup revel run &看似能跑,但实际踩中三个硬伤:
- 进程仍属于当前shell会话,终端关闭后可能被SIGHUP终止(尤其SSH断连)
- 标准输出/错误没重定向,日志直接丢进
/dev/null或丢失,journalctl里看不到任何记录 - 没有进程存活监控,崩溃后不会自动拉起,
ps里一查就空了
Revel二进制交付 + systemd.service最小可行配置
Revel项目应先构建为静态二进制(推荐CGO_ENABLED=0),再交给systemd管理。关键不是“怎么启动Revel”,而是“怎么让systemd可靠地拉起并盯住它”。
- 构建命令示例:
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o ./revel-app . - 把生成的
revel-app二进制拷到目标机(如/opt/myrevel/revel-app) - 配置文件必须放在
/etc/systemd/system/myrevel.service,内容精简但不可缺以下几项:
[Unit] Description=My Revel Web Application After=network.target [Service] Type=simple User=reveluser WorkingDirectory=/opt/myrevel ExecStart=/opt/myrevel/revel-app -import myapp -port 8080 -addr 127.0.0.1 Restart=always RestartSec=5 Environment=REVEL_RUNMODE=prod [Install] WantedBy=multi-user.target
注意:Type=simple适用于Revel这类自己不fork子进程的程序;若用了Type=forking反而会导致systemd误判主进程退出。
用于设计、审查、生成或重构使用Effector、effector-react、Farfetched、AtomicRouter、@effector/next等库的React应用。
常见启动失败原因与排查路径
执行systemctl start myrevel后状态为failed,别急着改配置,按顺序查这三处:
- 权限问题:
reveluser是否真实存在?/opt/myrevel目录是否对该用户可读可执行?用sudo -u reveluser /opt/myrevel/revel-app -import myapp -port 8080 -addr 127.0.0.1手动跑一遍最直接 - 环境变量缺失:Revel依赖
REVEL_RUNMODE=prod关闭热重载,漏掉就会卡在“waiting for changes...”不动;GO_ENV或APP_CONF等自定义变量也得写进Environment=行 - 端口冲突或绑定失败:Revel默认监听
0.0.0.0:9000,生产务必用-addr 127.0.0.1 -port 8080限定,并确认Nginx反代已配好;否则systemctl status里会显示bind: address already in use
所有日志统一走journalctl -u myrevel.service -f,别再翻stdout文件——这是systemd接管后最不该犯的错。
别忽略的两个细节
一是WorkingDirectory必须设,Revel会从该路径下找conf/和app/目录,设错就报app not found;二是RestartSec=5建议显式声明,否则崩溃密集重启时systemd可能触发速率限制,导致服务长时间挂起。










