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 Ecosystem

用于设计、审查、生成或重构使用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可能触发速率限制，导致服务长时间挂起。