systemctl 启动失败主因是服务未注册、进程未前台运行或 unit 文件路径错误；需依次检查 systemctl list-unit-files、which 命令、execstart 前台参数、daemon-reload 及 wantedby target 是否存在。

systemctl 启动失败，八成不是权限问题，而是服务根本没注册、进程没前台运行、或 unit 文件路径不对。

查服务是否存在：先过 systemctl list-unit-files 这关

报 Unit not found，别急着改权限或加 sudo。先确认服务名有没有被 systemd 认出来：

• 运行 systemctl list-unit-files | grep nginx（把 nginx 换成你要的服务名），没输出 = 没注册
• 再查二进制是否存在：which nginx，有返回才说明程序装了；没返回就得先装包或编译
• nginx 和 nginx.service 在多数发行版里等价，但自己编译安装的通常不带 .service 文件，得手动补
• 别输 systemctl start nginx.conf —— .conf 是配置文件，不是 unit 名，systemd 会直接报错

启动后秒退：检查 ExecStart= 是否带前台参数

运行 systemctl status nginx 看到 inactive (dead)，大概率是进程 fork 后主进程退出，systemd 误判为“执行完就结束”：

• 用 systemctl cat nginx 查 ExecStart= 行，确认是否含前台运行控制
• nginx 要求 daemon off; 写在 nginx.conf 里，否则默认后台运行，systemd 拦不住
• redis-server 需加 --daemonize no 参数，或改 redis.conf 中的 daemonize no
• 别在 ExecStart= 里写 nohup xxx & —— systemd 不吃这套，反而可能引发 cgroup 冲突

enable 失败提示 Unit file xxx.service does not exist

这不是路径写错或权限不够，而是 systemd 根本没扫描到你的 service 文件：

• systemd 只认两个位置：/usr/lib/systemd/system/（系统级，包管理器写入）和 /etc/systemd/system/（管理员级，推荐放这里，不被覆盖）
• 新建的 xxx.service 必须放在这两个目录之一，然后立刻执行 systemctl daemon-reload，否则 enable 找不到它
• systemctl enable xxx 实际是建软链接到 /etc/systemd/system/multi-user.target.wants/，所以目标文件必须存在且可读
• 如果 .service 里写了 WantedBy=graphical.target，但服务器没装桌面环境，enable 仍成功，但开机不会启动 —— 因为 target 没激活

非 root 用户想操作服务：sudoers 比 Polkit 更直接可靠

给普通用户开 systemctl 权限，优先走 sudoers，别一上来就配 Polkit：

• 用 visudo 编辑，加一行：username ALL=(ALL) NOPASSWD: /bin/systemctl start nginx, /bin/systemctl stop nginx
• 只放开必要子命令（如 status、start、stop），避免 NOPASSWD: ALL 带来的安全风险
• 服务文件本身不需要额外 chmod，systemd 不校验 service 文件的执行位，只关心内容是否合法
• 用户执行时必须带 sudo systemctl …，不能省略 sudo；Polkit 方案虽免密码，但规则文件出错难调试，新手容易卡住

真正卡住人的地方，往往不是语法写错，而是 daemon-reload 忘了执行，或者 WantedBy= 写的 target 在当前系统压根不存在。每次改完 service 文件，先 daemon-reload，再 cat 确认内容，最后 status 看实时反馈 —— 别跳步。