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 看实时反馈 —— 别跳步。
