Systemd服务启动失败需分层排查：先用systemctl status看Active状态、Main PID及错误提示，再用journalctl -u -n 50查Permission denied、No such file等关键词，接着用systemctl cat核对ExecStart路径、User/Group、Type等配置，最后验证解释器、配置、日志目录权限及ProtectHome等沙箱限制。
Systemd 服务启动失败，不能只盯着“failed”两个字，关键是要顺着日志和执行路径一层层往下挖——谁在跑、跑什么、想访问什么、被哪道门拦住了。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
先看状态和最近日志
运行 systemctl status your-service.service，注意三处信息： - “Active”行是否显示 failed 或 inactive (dead) - “Main PID”是否为空或已退出 - 最后几行错误提示，比如 Failed at step EXEC、USER spawning 或 CODE=exited, STATUS=1
再立刻查完整上下文：journalctl -u your-service.service -n 50 --no-pager。重点找带以下关键词的行： - Permission denied（文件/目录权限或沙箱限制） - Operation not permitted（缺 capability，如 bind、setuid） - No such file or directory（路径错、二进制缺失、动态库找不到） - Failed to load configuration（配置语法错或路径无效）
确认服务实际怎么跑
用 systemctl cat your-service.service 查看完整 unit 文件，重点关注： - ExecStart= 路径是否存在、是否可执行（ls -l /path/to/binary） - User= 和 Group= 是否真实存在（id username），家目录是否可访问（ls -ld /home/username） - Type= 是否匹配程序行为（例如脚本用 simple，后台进程用 forking） - 是否启用了 DynamicUser=yes，避免手动建用户出错
验证关键路径与权限
服务不是只读脚本，它会访问解释器、配置、日志、临时目录等。逐项检查： - 解释器（如 /usr/bin/python3）对运行用户是否可执行 - 配置文件（如 /etc/myapp/conf.ini）是否可读 - 日志目录（如 /var/log/myapp/）是否可写，且归属正确（chown user:group /var/log/myapp） - 若用到 ~/.ssh 或 /home/user/.config，确保家目录至少是 755 - 避免路径硬写 /root/xxx 却让普通用户去读
排除 systemd 沙箱和 capability 干扰
很多“权限不足”其实是安全策略在起作用：
- ProtectHome=true → 家目录不可见，删掉或设为 read-only
- ProtectSystem=strict → /usr 变只读，可能连动态库都加载不了
- 绑低端口（80/443）需同时配置：
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
- NoNewPrivileges=true（默认开启）会阻止 setuid 和 capability 继承，必要时设为 false
