openEuler 系统 systemctl 启动服务失败排查指南：从报错到解决

1. 问题现场：一条报错背后的连锁反应

1.1 报错到底长什么样

先说最常见的现象。你在 openEuler 22.03 LTS 上写完一个服务单元文件，执行：

bash复制systemctl start mydemo

结果屏幕上弹出：

code复制Job for mydemo.service failed because the control process exited with error code.
See "systemctl status mydemo.service" and "journalctl -xeu mydemo.service" for details.

这种错误很让人着急，因为它不说具体是哪一步出的问题。还有一类更直接的：

code复制Failed to start mydemo.service: Unit mydemo.service not found.

明明文件就在眼前，systemctl 却说找不到。除了这些，还有 Unit mydemo.service has a bad unit file setting、Failed with result 'exit-code'、Failed to enable unit: Unit file mydemo.service does not exist 等等。虽然提示文案各不相同，但本质上都是 systemd 没有按预期加载或执行服务单元。我见过不少同事在遇到这些报错时，第一反应是去改文件权限或者重新安装服务，结果折腾了半天，原因只是配置里多了个空格或路径写错。

1.2 先别急着改配置，确认四件事

我的经验是，报错出现以后，不要马上动手改 unit 文件。先把下面四件事确认完，能省掉一半的无效操作。

第一，确认 systemd 版本。执行 systemd --version，openEuler 22.03 LTS 默认的 systemd 版本一般在 250 附近。不同版本对 unit 文件语法的容忍度不同，比如某些较新的配置项在旧版本里会直接报 unrecognized，如果从 CentOS 7 迁移过来，这一点尤其明显。

第二，确认服务单元文件的位置。用户自建的服务单元通常放在 /etc/systemd/system/，软件包自带的放在 /usr/lib/systemd/system/。如果一个服务名在两个目录都有定义，/etc/systemd/system/ 的优先级更高。可以用 systemctl cat mydemo.service 看 systemd 实际加载的是哪个文件。

第三，确认系统状态。systemctl is-system-running 返回 running 是正常；如果返回 degraded，说明有单元启动失败，很可能会连带影响新服务的启动。例如一个服务依赖 mysql，而 mysql 之前启动失败，那么即使你的服务配置没问题，也会因为依赖失败而报错。

第四，确认服务名拼写。systemd 对名称大小写敏感，MyDemo.service 和 mydemo.service 是两个不同单元。systemctl status 后面如果跟错名字，看到的就是 Unit not found。

这四个确认做完，大部分问题已经缩小到具体方向了。

2. systemctl 启动服务的底层逻辑

2.1 systemd 是如何加载和执行服务的

要想真正解决启动报错，不能只靠反复试。systemd 执行一个服务时，并不是简单地把启动命令跑起来然后就放手不管。整个流程可以概括为：读入 unit 文件，解析各区块的指令，建立单元之间的依赖关系，检查前置条件，创建独立的环境和 cgroup，然后启动 ExecStart 指定的命令，并在后台持续追踪这个进程的状态。任何一个环节出了问题，start 命令都会返回失败。

拿一个典型的服务单元文件来说：

ini复制[Unit]
Description=My Demo Service
After=network.target

[Service]
Type=simple
ExecStart=/opt/demo/demo.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

[Unit] 区块里 After=network.target 只是启动顺序上的约定，它并不保证网络已经完全可用，只是说 network.target 这个单元要先进入启动流程。[Service] 区块里 Type=simple 表示服务直接以前台方式运行，ExecStart 启动的进程就是主进程。Restart=on-failure 意味着只有在异常退出时才自动重启，正常退出不会重启。[Install] 区块用来定义服务如何被启用，WantedBy=multi-user.target 是最常用的，表示开机进入多用户模式时启动它。

如果写成 Type=forking，含义就完全不同了。它要求启动命令自身在后台 fork 出子进程，原来的父进程退出，systemd 需要识别出真正的守护进程。如果没有配合 PIDFile= 指定 PID 文件，systemd 可能无法准确判断主进程是否存活，导致服务刚启动就被判定为失败。很多人遇到“服务状态一闪就变 failed”就是这个原因。

2.2 服务状态、依赖和重启策略的互相影响

systemd 对服务单元有一整套状态管理，常见的是 active、inactive、failed、activating、deactivating 等。执行 systemctl start 时，systemd 会先检查这个单元是否已经在运行，如果已经是 active，通常会直接返回成功；如果上次启动失败，则可能停留在 failed 状态，需要先 systemctl reset-failed 才能重新启动。

依赖关系也是一个大坑。使用 systemctl list-dependencies mydemo 可以列出启动时依赖的单元树。如果依赖的单元是 failed，而且没有设置 IgnoreOnFailure=yes，那么你的服务也会启动失败。我在实际排查时见过一个场景：服务单元里写了 Requires=mysql.service，mysql 因为磁盘空间满而挂掉，于是一整个服务组全部跟着失败。用 systemctl list-dependencies 一看就明白了。

重启策略上，Restart=always 和 Restart=on-failure 的区别经常被忽略。前者无论退出码怎么停止，都会自动拉起；后者只在异常退出时拉起。生产环境中一些脚本自身有 bug，循环退出，如果用了 always 就会造成无限重启，systemctl status 里会显示 activating (auto-restart) 状态，系统负载也会异常升高。所以写重启策略前，想清楚这个服务是常驻进程还是临时任务。

2.3 日志是定位问题的主线

报错之后，最忌讳的是猜。我见过有人根据经验去改权限，结果改了半天依然失败，最后用 journalctl 一看，根本不是权限问题。正确的做法是直接看日志：

bash复制journalctl -xeu mydemo.service

-x 让 systemd 补充说明日志中包含的错误代码，-e 直接跳到日志末尾，-u 指定 unit 名称。这条命令能显示出和这个服务相关的全部日志，包括标准输出、错误输出和 systemd 自身的错误信息。如果这条命令输出为空，可以试试 journalctl -u mydemo.service -b，只看本次启动的日志。

如果服务进程很快退出，日志行数特别少，可以临时给 service 文件加一行：

ini复制StandardOutput=journal+console

然后在控制台直接启动，看看脚本有没有报错输出。注意 systemd 会把 stdout 和 stderr 默认发往 journal，但如果你在脚本里故意用重定向把输出丢到 /dev/null，那就什么也看不到了。很多服务的启动脚本在手动执行时能打印一堆信息，一旦被 systemd 接管就沉默了，就是因为脚本里写的重定向路径或者环境变量问题，检查日志时要从执行结果往前倒推。

3. 高频报错分类与快速定位

3.1 Unit not found / bad unit file setting

这类报错最常见也最好定位。Unit not found 就是 systemd 在默认搜索路径里没有找到对应的 unit 文件。默认路径包括 /etc/systemd/system、/run/systemd/system、/usr/lib/systemd/system。可以用 systemctl cat mydemo.service 查看实际加载路径，如果提示 No such file，那就是文件没放对位置。

还有一种情况是文件放了，但语法有问题。bad unit file setting 看起来像语法错误，实际上可能是拼写错误、键值之间缺了 =、某个段落名写错、或者引号不匹配。比如把 [Service] 写成 [service]，systemd 会当作未知段落直接忽略，后面的 ExecStart 全都不生效。最保险的做法是写完服务文件后，用静态检查工具验证：

bash复制systemd-analyze verify /etc/systemd/system/mydemo.service

它会直接告诉你哪个配置项有问题，比反复 start 省事得多。还有个小细节：文件名的后缀也很重要。一个叫 mydemo 的文件，systemd 默认不会认为它是服务单元，必须叫 mydemo.service 才符合规则。

3.2 进程启动失败，但脚本手动执行没问题

这种问题我遇到得最多。在终端里敲 /opt/demo/demo.sh 一切正常，但 systemctl 启动就是失败。原因通常集中在几个地方。

第一个是环境变量。systemd 启动服务时不继承登录用户的环境变量，比如 $PATH、$JAVA_HOME、$PYTHONPATH 都是空的。如果脚本里用到了这些变量，启动时就会报“command not found”或者找不到库。解决办法是在 service 文件中通过 Environment= 或 EnvironmentFile= 显式声明。

第二个是工作目录。systemd 默认把当前目录设置为 /，如果你在脚本里使用相对路径，实际访问的就是根目录下的相对路径，文件自然找不到。手动执行时，当前目录通常是脚本所在目录，所以没问题。解决方式是使用绝对路径，或者在 service 文件里指定 WorkingDirectory=/opt/demo。

第三个是解释器路径。有些脚本第一行写的是 #!/usr/bin/env python3，在登录 shell 里 env 能通过 PATH 找到 python3，但 systemd 环境下 PATH 被重置后可能就找不到了。改成 /usr/bin/python3 绝对路径，或者把 PATH 加进去，问题就消失。

3.3 权限、SELinux 和资源限制

openEuler 默认启用 SELinux，很多看似权限问题的报错，其实是 SELinux 策略拦下来的。当服务启动时报 Permission denied，但 ls -l 看文件所有者、权限都没问题，就要检查 SELinux 上下文。

用 ls -Z 查看文件的 SELinux 标签。如果服务文件在自定义目录，标签可能是 default_t，systemd 启动的进程域没有权限读取这类文件。临时验证是不是 SELinux 的问题：

bash复制setenforce 0
systemctl start mydemo

如果 setenforce 0 后服务能启动，那基本就是 SELinux 策略导致。但别把 setenforce 0 当最终方案，生产环境会把 SELinux 设回 enforcing。正确的做法是用 chcon 修改上下文，或者用 semanage fcontext 添加规则，把目录标签改成 etc_t 或 bin_t 等合适的类型。

另外还有资源限制。systemd 默认对打开文件数没有特别的限制，但继承自系统的 limits 配置可能会影响服务。如果服务需要大量文件句柄，可以在 unit 里配置 LimitNOFILE=65535。如果是服务占用内存过大导致被杀，检查 MemoryMax= 或 cgroup 限制。openEuler 默认内核参数里 kernel.pid_max 也可能限制并发进程数，但这种情况比较少见。

3.4 启动超时与循环等待

有些服务启动报错是因为超时。systemd 默认 TimeoutStartSec=90s，如果服务在 90 秒内没有完成启动，就会被判定为失败。Type=oneshot 在执行一个耗时较长的初始化命令时尤其容易触发这个限制。处理方法是在 service 里调大超时时间，或者优化启动脚本，减少不必要的等待。

循环等待也经常导致假死。比如服务 A 依赖服务 B，服务 B 又依赖服务 A，形成循环依赖。systemd 在构建依赖图时通常会直接拒绝，但有些循环是通过 WaitFor 或 socket 激活间接产生的，启动时会一直卡在 activating 状态，直到超时。这时候用 systemctl list-dependencies 查看依赖树，把多余的依赖去掉，问题就能解决。

4. 从实战角度还原一次完整排查过程

4.1 环境准备与待启动服务描述

为了把前面的理论串起来，我用一个例子说明。最近我在一台 openEuler 22.03 LTS SP4 的虚拟机里部署了一个 Python 写的告警服务，目录在 /opt/alert-agent，启动脚本是 /opt/alert-agent/start.sh。我用 systemd 管理它，systemctl status alert-agent 显示 inactive，但执行 systemctl start alert-agent 就报 job failed。

按照第一节说的流程，我先跑了 systemctl is-system-running，发现系统状态是 degraded。用 systemctl --failed 查看，发现 mysql.service 之前启动失败。我先处理 mysql：systemctl reset-failed mysql，然后 systemctl start mysql，等它变成 active 后，系统状态变成 running。这个操作很重要，因为如果忽略这个 degraded 状态，后面排查 alert-agent 时会被系统里其他失败单元干扰。

4.2 逐步执行与参数解读

接着看 alert-agent 的 unit 文件：

bash复制systemctl cat alert-agent.service

文件内容如下：

ini复制[Unit]
Description=Alert Agent
After=network.target

[Service]
Type=simple
ExecStart=/opt/alert-agent/start.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

从语法上看没有明显问题。systemd-analyze verify 也没有报错。于是看日志：

bash复制journalctl -xeu alert-agent.service

日志里只有一行：start.sh: line 3: python3: command not found。问题定位到了：脚本依赖 python3，但 systemd 环境下 PATH 没有包含 python3 所在路径。手动执行脚本时，当前 shell 的 PATH 里有 /usr/local/bin 或者 /usr/bin，所以正常；但 systemd 的默认 PATH 是 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin，其实应该能覆盖到，最后检查发现 python3 是后来装在 /usr/local/python3/bin 下的，这个路径不在默认 PATH 里。

我在 unit 文件里加了一行环境变量：

ini复制Environment=PATH=/usr/local/python3/bin:/usr/bin:/bin

保存后执行：

bash复制systemctl daemon-reload
systemctl start alert-agent

这次启动成功了。记得修改 unit 文件后必须执行 daemon-reload，否则 systemd 使用的还是旧配置。这个 daemon-reload 不起眼，但真的经常被漏掉。

4.3 修改后的验证与开机自启设置

服务起来之后，我做了两个额外确认。第一个是确认主进程状态。systemctl status alert-agent 显示 active (running)，主进程 PID 是脚本进程。由于 start.sh 最后一行调用 python3 时用的是前台方式，systemd 会跟踪脚本进程，而脚本进程可能一直在等 python3 结束，状态虽然 active，但行为上不是最干净的。后来我把 start.sh 最后一行改成 exec /usr/bin/python3 /opt/alert-agent/app.py，用 exec 替换当前进程，这样 systemd 跟踪到的就是真正的服务进程。这个优化在停止服务时尤其重要，直接 kill 脚本进程可能留下孤儿 Python 进程。

第二个是开机自启。执行：

bash复制systemctl enable alert-agent

命令会在 /etc/systemd/system/multi-user.target.wants/ 下创建符号链接。之后用 systemctl list-unit-files | grep alert-agent 确认状态是 enabled。重启虚拟机后，服务能自动拉起，不再需要人工干预。到这里，问题才算彻底解决。

5. 常见问题速查表与避坑技巧

5.1 错误消息与对应处理

我把平时遇到最多的 systemctl 报错整理成一个速查表，方便你对照。

实际排查时，我一般会从表格的后两列反推，先看日志，再决定要不要看配置文件。不要一上来就改文件，否则容易陷入“改了 A 又报 B”的循环。

5.2 我踩过的几个坑

第一个坑：没有 daemon-reload。这是我的老毛病，修改 service 文件后直接 systemctl start，结果一直在报同样的错误，还以为是配置文件没生效，最后发现只是没让 systemd 重新加载配置。现在我已经养成习惯：只要动了 unit 文件，第一件事就是 daemon-reload。

第二个坑：Type 类型选错。有一次我写了一个常驻的前台脚本，却用了 Type=forking，结果 systemd 启动后立刻认为进程退出，服务状态直接变 failed。改成 Type=simple 后一切正常。Type 的选择取决于你的程序本身是前台还是 daemon，不是随便写。

第三个坑：脚本里的相对路径。手动执行脚本时，工作目录在 /opt/alert-agent，脚本能正常找到配置文件。但 systemd 默认把工作目录设在 /，于是脚本启动时找不到 ./config.yaml。花了一个小时才想到是相对路径问题，后来一律改成绝对路径，或者在 unit 里写 WorkingDirectory。

第四个坑：用 kill 命令测试 Restart 策略。我以为手动 kill 服务进程会触发 Restart=on-failure，但 systemd 会区分是管理员手动停止还是异常退出，直接 kill 并不会触发重启。想要测试重启策略，应该用 systemctl kill -s SIGKILL xxx.service，让 systemd 认为服务被非正常终止。

5.3 给新手的建议

在 openEuler 22.03 LTS 上使用 systemctl 管理服务，有几个习惯值得一开始就养成。第一，自建服务文件放到 /etc/systemd/system/，不要直接修改 /usr/lib/systemd/system/ 下的内容，因为系统升级时这些文件可能被覆盖。第二，写完 unit 文件后先用 systemd-analyze verify 做一遍静态检查，很多低级错误能提前发现。第三，看到报错先 journalctl -xeu，日志里通常有比 status 更具体的线索。第四，如果你在 /etc/init.d 里保留了旧脚本，注意 systemd 对 LSB init 脚本的兼容有限，部分语法可能不受支持，不如直接写 service 单元。

还有一个实用技巧：如果服务需要一堆环境变量，可以把它们写进 /etc/sysconfig/xxx，然后在 unit 文件里写 EnvironmentFile=-/etc/sysconfig/xxx。减号表示文件不存在也不报错，这个写法规避了“环境变量文件缺失导致启动失败”的情况，很多开源软件都这么用。

我个人在 openEuler 22.03 LTS 上处理 systemctl 启动服务报错，最深的体会是不要凭经验猜，一定要沿着 systemd 的加载链路去排查。先把系统状态和日志看清，再动配置文件，绝大多数问题都在几分钟内能定位。希望这篇记录能帮你少走弯路。如果你在 openEuler 里遇到更奇怪的 systemctl 报错，不妨按这个思路试试，很多时候问题的根源并没有想象中复杂。