systemd 服务启动失败？先查这四处

服务用 systemctl start 起不来，报错往往只有一句 Failed to start，看不出根因。别急着重装或改配置，按下面四处逐个过，多数问题几分钟就能定位。

第一处：先看它到底为什么死

systemctl status <服务名>
journalctl -u <服务名> --since "10 minutes ago"

status 给的是摘要，journalctl 才是完整报错。先拿到最后一屏报错再动手，别凭感觉改配置。常见报错分三类：配置文件语法错、依赖文件找不到、端口已被占用，对应处理完全不同。

第二处：配置文件和路径对不对

服务启动时读不到配置、ExecStart 里的可执行文件路径写错、WorkingDirectory 不存在，都会直接退出。重点核对三点：unit 文件里的路径是不是真实存在的、配置里的相对路径在服务运行时解析到哪里去了、文件权限够不够。刚改完 unit 文件别忘了：systemctl daemon-reload。不 reload，systemd 跑的还是旧配置，改了等于没改。

第三处：端口和依赖服务冲突

端口被别的进程占了，服务起不来就退；依赖的数据库、网络还没就绪，服务也会启动失败。先确认端口归属：ss -tlnp | grep <端口>。如果是别的进程占了端口，要么停掉它，要么改服务的监听端口。再看 After 和 Requires 有没有把依赖关系写对——依赖服务没起来就强行启动，失败是迟早的事。

第四处：权限和环境变量够不够

服务默认以 root 之外的用户运行时，读不到证书、写不了日志目录都会失败。检查 User 指定的用户对配置、数据、日志目录有没有读写权限。再看 EnvironmentFile 指向的文件存不存在、里面的必填变量有没有缺：本地手动能跑、systemd 里跑不起来，十有八九是环境变量在两种运行方式下不一致。

一句话总结：先看 journalctl 的报错，再确认 unit 配置、端口依赖、权限环境变量。按这个顺序查，服务起不来基本能快速破案；修好一个再往下走，别同时改四处。