将Go编译生成的二进制文件作为systemd服务运行失败

我之前也碰到过一模一样的情况——命令行跑起来顺得很，丢给systemd就罢工，别慌，咱们一步步排查根源：

1. 先拉取日志找具体错误 #

这是最关键的第一步，systemd会把服务的运行细节都记在日志里，用这条命令实时追踪日志输出：

journalctl -u gobinary.service -f

日志里会明确告诉你是权限不够、路径找不到还是环境变量缺失，比瞎猜效率高多了。

2. 检查所有路径是否准确 #

• WorkingDirectory：确认/path/to/directory/确实是你的程序所在目录，末尾的斜杠不影响，但路径必须完全正确；
• 配置文件路径：你写的--config config/service.conf是相对路径，它会基于WorkingDirectory解析，实际对应/path/to/directory/config/service.conf，这个文件真的存在吗？不确定的话直接换成绝对路径试试；
• 二进制文件权限：确保你的binary有执行权限，执行chmod +x /path/to/directory/binary给它加上可执行权限。

3. 排查权限匹配问题 #

systemd默认用root用户运行服务，但有时候你的程序需要访问普通用户的文件（比如你命令行运行时用的账号），或者某些目录没有写入权限（比如程序要写日志到WorkingDirectory）：

• 可以在[Service]段添加User=你的用户名，让服务用和命令行一致的用户运行；
• 检查WorkingDirectory、配置文件、日志目录的权限，确保运行服务的用户有对应的读/写权限。

4. 确认环境变量是否匹配 #

命令行运行时的环境变量和systemd服务的环境变量差异很大，systemd的环境变量非常“精简”，如果你的Go程序依赖某些自定义变量或者系统变量（比如GOPATH）：

• 在[Service]段用Environment=KEY=VALUE直接添加，比如Environment=MY_APP_LOG=/var/log/myapp.log；
• 如果变量太多，可以写个环境变量文件，再用EnvironmentFile=/path/to/env/file加载。

5. 确保程序是前台运行状态 #

systemd默认要求ExecStart的程序在前台运行（默认Type=simple），如果你的Go程序自己做了后台daemon化处理，systemd会误以为程序已经退出，导致服务异常。这种情况要么修改程序让它保持前台运行，要么在[Service]段添加Type=forking，告诉systemd程序会fork后台进程。

最后，修改配置后别忘了刷新并重启服务 #

每次修改.service文件后，都要让systemd重新加载配置，再重启服务：

systemctl daemon-reload
systemctl restart gobinary.service

内容的提问来源于stack exchange，提问作者Mnemosyne