systemctl启动失败主因有三：服务未安装或.service文件缺失；进程未前台运行导致systemd误判退出；unit文件路径错误或未重载。需依次检查存在性、前台参数、路径与重载。
systemctl start 启动服务失败，提示 Unit not found
服务名写错了，或者服务文件根本没装。systemctl 不会自动猜服务名，nginx 和 nginx.service 在多数情况下等价，但有些包（比如自己编译安装的）压根没提供 .service 文件。
- 先查服务是否存在：
systemctl list-unit-files | grep nginx，没输出就说明没注册 - 确认服务是否已安装二进制：
which nginx，有返回才说明程序存在 - 若只有二进制没有 service 文件，得手动写一个
/etc/systemd/system/nginx.service，再systemctl daemon-reload - 别用
systemctl start nginx.conf——.conf是配置文件，不是 unit 名
启动后立刻退出，systemctl status 显示 inactive (dead)
常见于后台进程被 systemd 当成普通命令执行完就结束了。systemd 默认期望服务进程“不退出”，而很多传统服务（如 redis-server、nginx）默认是前台运行还是后台运行，取决于启动参数或配置项。
-
nginx必须在nginx.conf里设daemon off;，否则它 fork 后主进程退出，systemd 就认为服务挂了 -
redis-server要加--daemonize no参数，或改redis.conf中的daemonize no - 检查
systemctl cat <code>服务名看ExecStart=行，确认有没有带前台运行参数 - 别依赖
nohup或&—— systemd 有自己的进程管理逻辑，这些 shell 语法会被忽略或引发 cgroup 冲突
想开机自启，但 enable 失败：Failed to enable unit: Unit file xxx.service does not exist
不是权限问题，也不是路径错，而是你还没把 service 文件放进 systemd 能扫描到的位置。systemd 只认 /usr/lib/systemd/system/（系统级）和 /etc/systemd/system/（管理员级），其他路径一概无视。
- 新建的 service 文件必须放在上述两个目录之一，推荐用
/etc/systemd/system/（不会被包管理器覆盖） - 放好后必须运行
systemctl daemon-reload，否则enable找不到它 -
systemctl enable xxx实际是创建软链接到/etc/systemd/system/multi-user.target.wants/，所以目标文件得先存在且可读 - 如果 service 文件里写了
WantedBy=graphical.target，但系统是 server 版（没装桌面），enable也能成功，但开机不会启动 —— 因为 target 没激活
systemctl stop 后再 start，提示 Job for xxx failed because the control process exited with error code
这通常不是服务本身的问题，而是 systemd 记录了上次失败状态并做了保护性拦截。尤其当服务启动时因配置错误崩溃过一次，systemd 会缓存失败原因，后续 start 会直接拒绝，避免反复拉起失败进程。
- 先看详细错误：
journalctl -u <code>服务名--since "1 hour ago"，重点找第一行 crash 前的日志 - 常见诱因：端口被占（
Address already in use）、配置路径不存在（No such file or directory）、权限不足（Permission denied） - 临时绕过失败状态限制：
systemctl reset-failed <code>服务名，但只解决“不能启”，不解决“为啥崩” - 修改配置后，别只
systemctl restart—— 先systemctl daemon-reload，否则 systemd 还在用旧 unit 定义
真正麻烦的是那些没日志、没报错、但就是起不来的情况：往往卡在 socket 激活、SELinux 上下文、或 cgroup v2 的资源限制里。这时候得关掉 systemd 的“安静模式”，加 --log-level=debug 启动看底层行为。
