systemctl 服务启动失败排查指南（openEuler）

如果你在 openEuler 22.03 LTS 上执行 systemctl start xxx 的时候，看到的是“Job for xxx.service failed because the control process exited with error code”，先不用急着卸载重装。这类提示并不是错误的完整答案，systemd 只是礼貌地告诉你：服务进程确实尝试启动过，但结果不符合预期。真正的原因藏在它下面几层日志里。这篇内容就围绕 openEuler 22.03 LTS 的 systemctl 启动服务报错展开，覆盖 docker、MySQL、vsftpd 这类常见服务，也包含自己写的 service 文件为什么会失败。适合刚把服务从别的发行版迁到 openEuler、或者还在学习和 systemd 打交道的读者，先建立一套能复用、能排查、不靠瞎猜的排错方法。

1. 服务启动失败，先分清“系统认为没起来”和“进程起来又被杀死”

很多人一看到 Job for xxx.service failed 就开始翻业务程序日志，实际上漏掉了 systemd 给的状态机信息。systemd 维护的不是“二进制的进程活着吗”这么简单，它还要验证服务进程有没有按预期退出、有没有生成主 PID、有没有在超时时间内完成启动。不同失败模式下，systemd 在状态里打点的方式完全不同。先把这个分清，之后的排查方向才不会跑偏。

1.1 一条 systemctl status 命令能告诉你的，比报错正文多得多

报错正文一般只给结果，不给你过程。建议先用这条命令看全状态：

bash复制systemctl status your-service -l --no-pager

-l 是关键，它的作用是禁止 systemd 把长行截断。很多输出默认会在 80 列左右断行，一旦日志行含有较长路径或完整启动命令，直接断到看不出来。--no-pager 则避免进入 less 翻页状态，适合在服务器上快速滚动。

输出里重点看这几个字段：

• Loaded：这里会标出 unit 文件的绝对路径，比如 /etc/systemd/system/xx.service 还是 /usr/lib/systemd/system/xx.service。如果你发现自己改的文件根本不在 systemd 读取范围内，那等于没改。
• Active：看到 active (running) 不代表问题结束，服务可能“口头上活着”，但业务端口没起来；看到 failed (Result: exit-code) 则说明已经走到了失败态。
• Process：当行里出现 ExecStart=/usr/bin/xxx (code=exited, status=1/FAILURE)，这行比报错正文更重要，它表示 systemd 确实帮你执行了启动命令，但该命令自身以某个退出码结束了。
• Main PID：如果服务是 daemon 型进程，系统会记录主进程 PID；一旦这一行缺失或显示为 Main PID: 0，往往意味着启动命令还没跑完或已经退出。

同时可以配合：

bash复制systemctl list-units --failed

这条命令会把当前处于失败状态的所有 unit 列出来。如果你刚登录一台不熟悉的 openEuler 机器，先跑它，比一个一个去试要快得多。

1.2 code=exited 和 code=killed 代表两种完全不同的死法

在 systemctl status 的进程信息里，systemd 会注明进程退出方式。最常见的是这两类：

• code=exited：进程自己调用了 exit()，也就是主动退出。此时 status=1/FAILURE 中的 1 是程序返回码。程序主动退出，通常意味着它认为自己“启动条件不满足”，需要继续看业务日志。
• code=killed：进程是被信号杀掉的。比如 signal=KILL，可能涉及 OOM，也就是内存被 cgroup 或内核回收；signal=SEGV 则多半是程序崩溃。

还有一种很典型的状态码，status=203/EXEC。这个 203 不是业务程序返回的，而是 systemd 在执行 ExecStart 阶段就失败了，最常见的直接原因是可执行文件路径不存在、没有执行权限，或者脚本第一行解释器写错。例如 unit 文件里写 ExecStart=/opt/myapp/run.sh，但这个脚本没 chmod +x，systemd 会直接拒绝执行，业务日志一句话都不会留下。

另外，如果 unit 文件里配置了 User=someuser，而系统里根本没有这个用户，可能看到类似 status=217/USER 的失败状态。这种其实是 systemd 在切换身份阶段就失败了，程序本身都还没开始跑。

1.3 journalctl 是还原“死亡现场”最重要的入口

systemctl status 能看结论，要看启动过程中发生了什么，就得去看日志。systemd 下所有由 unit 启动的服务，标准输出和标准错误默认都会进 journald：

bash复制journalctl -u your-service -n 200 --no-pager

-u 指定 unit，-n 200 表示只看最近 200 行。如果服务启动失败，通常最后几行就是原因。但要注意一点：journal 默认可能只存本次开机后的内容，如果你的排查跨了多次重启，最好先确认日志是否持久化，否则上一条命令可能什么都查不到。这个问题我在后面第 5 节单独说。

2. openEuler 22.03 LTS 上三个典型的真实启动失败：docker、MySQL、vsftpd

服务名不同，失败的套路却高度相似。我拿 openEuler 22.03 LTS 环境里最常出现的三个服务举例。这三个案例并不脱离 systemctl 的范畴，相反，它们正好能说明同一个道理：看到 systemctl 报错后，下一步一定是看 journal，而不是先去怀疑服务软件本身坏了。

2.1 docker.service 起不来，先查内核模块和转发设置

在 openEuler 22.03 LTS 上安装完 Docker 后，执行 systemctl start docker 可能看到：

text复制docker.service: Main process exited, code=exited, status=1/FAILURE

此时用 journalctl -u docker -n 100 --no-pager 查看，如果日志里出现 “Error starting daemon: Error initializing network controller: Error creating default "bridge" network” 或者和 iptables/nftables 有关的报错，这通常不是 Docker 包坏了，而是主机的网络环境没准备好。

openEuler 默认使用 firewalld 管理防火墙，底层已经切换到 nftables，Docker 虽然会尝试自动适配，但内核里负责 bridge netfilter 的模块如果没有加载，NAT 规则就建立不起来。可以先做这几步：

bash复制modprobe br_netfilter
lsmod | grep br_netfilter

如果能加载但一重启又没了，可以写成持久化模块：

bash复制echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf

然后重启 Docker：

bash复制systemctl restart docker
systemctl status docker --no-pager

我遇到过不少把 Docker 卸载重装好几遍，最后问题却出在 br_netfilter 没加载的情况。在 openEuler 这种内核配置偏保守的发行版上尤其常见。排查时先看日志，能避开大量无效操作。

2.2 MySQL 启动后马上退出，多半是目录权限和数据目录初始化问题

systemctl start mysqld 失败时，日志里经常出现这么几种情况：

• /var/lib/mysql 目录权限不对，MySQL 进程以 mysql 用户运行，但目录属主却是 root，导致无法创建临时文件或表空间。
• 数据目录是空的，没有完成初始化。MySQL 8.x 首次启动必须要有初始数据，否则服务会报 Table 'mysql.plugin' doesn't exist 或类似错误后退出。
• /var/run/mysqld 或 /var/log/mysql 目录不存在或权限不对，导致进程无法创建 pid 文件和日志。

处理顺序通常是：

bash复制mkdir -p /var/lib/mysql /var/run/mysqld /var/log/mysql
chown -R mysql:mysql /var/lib/mysql /var/run/mysqld /var/log/mysql

如果数据目录是空的，初始化一次：

bash复制mysqld --initialize-insecure --user=mysql

--initialize-insecure 会创建一个 root 空密码的初始账户，适合本机调试。生产环境建议用 --initialize，这样会生成临时密码。初始化完成后再启动：

bash复制systemctl start mysqld

如果还是失败，可以检查配置里实际使用的 datadir：

bash复制mysqld --defaults-file=/etc/my.cnf --verbose --help 2>/dev/null | grep datadir

这里想强调一个容易踩的坑：不管你在 /etc/my.cnf 里把 datadir 改到哪里，都要保证目标目录的属主是 mysql:mysql，并且 SELinux 的文件上下文也要匹配。比如数据目录在 /data/mysql，光改 chown 可能还不够，我后面会专门讲 SELinux 的处理方式。

2.3 vsftpd 启动失败：配置看起来没错，但日志和预期对不上

在 openEuler 上安装 vsftpd 后，执行 systemctl start vsftpd 可能看到类似 “failed to start vsftpd ftp daemon” 的提示。用 journal 看日志，如果出现监听地址相关的报错，最常见的原因之一就是配置里的 IPV6 选项和当前网络栈不匹配。

很多默认的 /etc/vsftpd/vsftpd.conf 里会有：

ini复制listen_ipv6=YES

这句的本意是让 vsftpd 监听 IPv6 通配地址。可如果你的虚拟机或容器里禁用了 IPv6，或者网络环境不支持 IPv6，vsftpd 在创建 socket 的阶段就会失败，然后整个服务启动失败。最直接的验证方式是把监听改回 IPv4：

ini复制listen=YES
listen_ipv6=NO

改完执行：

bash复制systemctl restart vsftpd
systemctl status vsftpd --no-pager

如果在日志里看到类似 “500 OOPS” 的内容，还要往配置里指定的路径、系统用户是否存在这个方向查，比如 anon_root 指向了一个不存在的目录，或者 PAM 配置里使用的用户文件有问题。这类报错有个共同特征：systemd 只是负责拉起进程，进程起来后自己检查配置不通过，然后主动退出。不要把锅都甩给 systemd。

3. unit 文件里的隐藏坑：不是程序报错，而是 systemd 读不懂你的意图

前面举的服务都是已有现成 unit 文件的场景。如果你是在 openEuler 22.03 LTS 上自己写 service 文件，或者是从别的发行版拷贝了一份 unit 文件过来，那启动失败的原因可能根本不在服务程序，而在于 unit 文件本身就没通过 systemd 的解析。

3.1 改了 service 文件不执行 daemon-reload，等于白改

systemd 在开机和每次 daemon-reload 时才会重新加载 unit 文件。很多人手动改了 /etc/systemd/system/xxx.service 后立刻执行 systemctl restart xxx，却发现没生效或者报错。

正确的顺序是：

bash复制systemctl daemon-reload
systemctl restart xxx

如果 unit 文件有语法层面的问题，daemon-reload 阶段可能不会有明显提示，但 restart 的时候 systemd 会告诉你分配失败。这时可以用 systemd 自带的校验工具：

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

这个命令能检查出不少低级问题，比如 ExecStart 行缺少参数、After 里写了不存在的单元、配置项拼写错误等。注意它检查的是静态语法和依赖关系，检查不出程序自身的运行错误，也不能替代 journal 日志。

3.2 ExecStart 不是 shell，不是你想怎么写就怎么写

这是写 service 文件最容易踩的坑。很多人平时在命令行里习惯写管道、重定向、多条命令，直接原样抄进 ExecStart，结果服务怎么都启动不了。

systemd 的 ExecStart= 默认不是用 /bin/bash -c 来执行的。它只负责直接启动一个命令，不支持 shell 的 >、|、&& 这些操作符。如果确实需要这些功能，你至少要把命令包一层：

ini复制ExecStart=/bin/sh -c 'cd /opt/myapp && ./start.sh > /var/log/myapp/stdout.log 2>&1'

不过在真实生产环境里，我不太推荐这种把所有逻辑塞进一行 sh -c 的写法。更好的做法是单独写一个启动脚本，然后在 service 里指向脚本。这样排障时直接手动执行脚本也能复现问题，定位会快很多。

还有一个常见的坑是路径里有空格或特殊字符时，systemd 的引号规则和命令行不太一样。如果你写的路径带空格，需要用 systemd 能识别的引号方式，而不是盲目加单引号。为了避免这种问题，最简单的办法就是在编写脚本时确保目录路径不含空格。

3.3 环境变量不会自动继承，依赖关系也不会自动成立

systemd service 启动时，并不会把你在 shell 里 export 过的环境变量带进去，也不会读取 /etc/profile。所以 service 文件里写 ExecStart=python /opt/xx/run.py，而 python 这个解释器在 systemd 的默认 PATH 里不存在，就会导致类似 203/EXEC 的报错。我在经验里更倾向于写解释器的绝对路径，比如 /usr/bin/python3。

如果程序本身需要读取环境变量，就要通过 unit 文件的 Environment= 或 EnvironmentFile= 显式传入。比如：

ini复制EnvironmentFile=/etc/sysconfig/myapp
Environment="APP_MODE=production"

EnvironmentFile 指向的文件路径如果不存在，某些 systemd 版本会因为加载失败而不启动服务。文件内容里也不要用 export 前缀，直接写 KEY=VALUE 就好。

依赖关系同理。看到 Requires=network.target 或者 After=mysql.service，别以为这样服务就一定能按顺序等到 MySQL 真正就绪。After= 只保证 systemd 在启动顺序上让某个单元先启动，并不会去检查 MySQL 的端口是否已经能连接。很多“微服务启动失败”的报错，本质上就是启动顺序和依赖 readiness 的问题。

4. openEuler 的 SELinux 经常是启动报错的“第三只手”

在 openEuler 22.03 LTS 上，还有一个非常隐蔽但出现频率很高的根因：SELinux。如果你已经把服务日志翻了个底朝天，发现程序就是因为 Permission denied 退出，但在终端手动用 root 执行同样命令却能成功，那优先怀疑 SELinux。

4.1 journal 里看似普通权限错误，其实藏着 AVC 审计日志

SELinux 拦截进程时，不会总是在业务日志里留下“SELinux denied”这么直白的字眼。很多程序的报错只是 Permission denied 或 Cannot bind，但真正原因不是 Unix 文件权限，而是 SELinux 的安全上下文不允许。

排查时优先查审计日志：

bash复制ausearch -m AVC -ts recent

如果能看到类似：

text复制type=AVC msg=audit(...): avc: denied { name_bind } for pid=... comm="xxx" scontext=system_u:system_r:xxx_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

那问题就很清楚了：进程试图绑定某个端口，但 SELinux 策略里允许该 domain 绑定的端口类型不包含你指定的端口。

对于快速验证，你可以临时把 SELinux 放到 permissive 模式：

bash复制setenforce 0
systemctl start your-service

如果这样服务就能正常启动，那基本可以判定与 SELinux 策略相关。验证完切记恢复：

bash复制setenforce 1

注意，setenforce 0 只适合临时测试，不要让生产环境长期处于 permissive 模式，否则排障时更难暴露真实问题。

4.2 改端口、挪数据目录后启动失败，别忘了给 SELinux 上下文打标签

最常见的 SELinux 相关启动失败，是服务没有按默认路径运行。例如 MySQL 数据目录被放在 /data/mysql，而不是 /var/lib/mysql。这种情况下，/data/mysql 里新创建的文件很可能带有 default_t 或其他不适合 MySQL 的上下文标签，MySQL 进程读取这些文件时会被拒绝。

标准服务一般都有对应策略。拿 MySQL 举例，移动目录后需要做两件事：

bash复制semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?"
restorecon -Rv /data/mysql

semanage fcontext 是告诉 SELinux，以后这个路径下创建的文件默认使用 mysqld_db_t 类型；restorecon 则把已经存在的文件上下文立刻修正过来。如果你看不到 semanage 命令，先安装对应工具包：

bash复制yum install -y policycoreutils-python-utils

同理，如果服务要监听非默认端口，可能需要给某类服务端口打标签。例如 Web 服务要监听 8443，但 SELinux 默认允许它的端口列表里没有 8443：

bash复制semanage port -a -t http_port_t -p tcp 8443

这里不展开每个服务的具体策略类型，思路是固定的：先用 ausearch 找到 AVC 记录，再看 scontext 和 tcontext，然后决定是给路径打标签还是给端口打标签。如果只是拿到一个简短的服务启动失败提示，而没有这条路排查，你很容易在 Unix 权限和配置文件之间反复横跳。

4.3 自定义服务放在 /opt 下，启动失败的策略处理要格外小心

自己写的守护进程如果放在 /opt/myapp，启动后可能需要读配置文件、写日志、监听端口。这种情况下 SELinux 默认不会为你的自定义进程开放足够权限，所以可能启动成功但访问时被打回，或者直接启动阶段就失败。

我不建议在还没有弄清策略类型之前乱用 chcon -R 或者 setenforce 0 来硬凑。比较稳妥的做法是：

1. 先在 permissive 模式下启动一次，确认程序本身没问题。
2. 保持 permissive，但记录下 AVC 日志，用 ausearch 收集运行期间需要的访问类型。
3. 根据 AVC 里的类型信息，为日志目录、配置目录打上匹配的 SELinux 上下文；如果是标准服务，优先使用发行版自带的 policy 类型。
4. 确认无误后再恢复 enforcing，重启服务验证。

整个过程有点繁琐，却是避免“改了能跑，但重启后毫无规律失败”的最有效方法。在 openEuler 上跳过 SELinux 不考虑，解决 systemctl 启动报错就只能算解决了一半。

5. 把排错过程收成一套固定命令组合，按顺序执行比直觉更快

当我面对一个“systemctl 启动服务报错”的故障时，已经很少凭感觉去猜了。我有一套固定的命令顺序，能在几分钟内把问题收敛到：unit 文件问题、进程环境问题、SELinux 问题或业务程序自身问题。

5.1 从服务状态到日志输出，五条命令按顺序跑

bash复制systemctl cat your-service
systemd-analyze verify your-service
systemctl status your-service -l --no-pager
journalctl -u your-service -n 200 --no-pager
ausearch -m AVC -ts recent

第一条看 service 文件到底生效成什么样，有时候你改的配置文件根本不是 systemd 当前读的那个，这条能直接暴露。第二条做语法和依赖关系静态检查，排除低级书写错误。第三条看进程退出代码和状态。第四条读取服务启动日志，找到业务层面报错。第五条查 SELinux 有没有在暗处拦截。

如果服务处于快速失败又自动重启的状态，第一次用 systemctl status 可能只看到 activating (auto-restart)，此时先跑：

bash复制systemctl reset-failed your-service

把 systemd 的失败计数清掉，再去启动，日志会干净很多。

5.2 状态码速查表：看见什么就该往哪里查

这张表不能覆盖所有情况，但覆盖了 openEuler 上 systemctl 启动服务报错的绝大多数起点。看到某种状态后，至少知道不要继续盲目卸载重装。

5.3 journald 不做持久化的话，日志丢了再排查就难了

openEuler 的 journald 默认日志是存放在内存中的 /run/log/journal 下，这意味着重启后历史日志可能被清空。如果你排查的是一个“每次重启才会失败”的服务，没有持久化日志几乎等于失去了一半线索。

开启持久化的方法很简单：

bash复制mkdir -p /var/log/journal
systemctl restart systemd-journald

之后服务日志会写入 /var/log/journal。建议在 openEuler 上装好基础服务后，第一时间做这个操作。很多疑难启动报错不是不能查，而是日志不够长，导致看不到上一次失败的具体