systemd服务开机启动失败，如何从Unit配置和journal日志定位？-嵌入式Linux面试-凡亿教育面试平台

嵌入式Linux / 企业面试高频题 · 2026.11.08

产品开机后网络、采集程序或后台守护进程没有运行，串口控制台却只提示某个.service启动失败。面试官想确认你是否会沿着systemd状态、服务日志、Unit配置和启动依赖逐层定位，而不是反复重启。

面试先说结论

先用systemctl status查看服务状态、退出码和最近日志，再用journalctl -u 服务名 -b查看本次启动的完整服务日志；随后检查Unit文件中的ExecStart、User、WorkingDirectory、Environment和依赖关系。修改Unit文件后执行systemctl daemon-reload，再重启服务并验证，不要把After、Requires和WantedBy混为一谈。

一、核心原理与工程判断

DietPi嵌入式Linux终端中的systemd服务启动失败日志，显示service状态、ExecStart退出码及重启失败信息

先从状态和本次启动日志入手

systemctl status xxx.service可以快速看到Active状态、Main PID、退出码及最近日志；journalctl -u xxx.service -b可以筛选本次开机该服务的日志。若日志很多，应先围绕具体服务名和启动时间定位，不要只看journalctl -xe里最后几行就下结论。

Unit文件中最常见的错误

ExecStart路径写错、脚本没有执行权限、解释器不存在、WorkingDirectory不存在、运行用户无权访问文件、环境变量没有加载，都会导致服务启动失败。交互式终端能运行的命令，不代表systemd服务也能运行，因为服务环境通常更精简，不会自动继承登录Shell配置。

依赖关系和启动顺序怎么区分

After=只表达启动顺序，不会单独拉起另一个服务；Requires=表示依赖关系，依赖单元失败可能影响当前单元；Wants=通常表达较弱的依赖；WantedBy=常用于安装时建立目标单元的关联。若服务依赖网络、挂载分区或设备节点，要确认相应依赖和设备就绪时机。

修改后为什么要daemon-reload

systemd会缓存已加载的Unit配置。修改.service文件后，需要执行systemctl daemon-reload让管理器重新读取配置，再restart服务。若修改的是程序本身而不是Unit文件，是否需要daemon-reload则不同。还要检查服务是否被enable，以及开机目标是否包含对应安装关系。

二、实际排查与设计步骤

执行systemctl status xxx.service，记录Active状态、退出码、Main PID和最近错误信息。
执行journalctl -u xxx.service -b --no-pager，按时间查看服务本次启动的详细日志；必要时增加-p err或--since筛选。
执行systemctl cat xxx.service检查实际加载的Unit配置，逐项核对ExecStart、User、WorkingDirectory、Environment、After、Requires等字段。
修正配置或权限后执行systemctl daemon-reload，再systemctl restart xxx.service，并检查状态、日志和开机自动启动配置。