业务起不来只会反复重启服务：openEuler上systemctl与journalctl把故障定位出来

服务器上业务起不来，很多人的第一反应是 systemctl restart 反复来几遍——重启十次，问题还在原地。服务起不来一定有原因，原因就写在 systemd 和 journald 的记录里。openEuler 上用好 systemctl 与 journalctl 这对组合，多数服务故障五分钟内就能定位到具体哪一行出错。下面按官方文档思路走一遍排查路径。

第一步，看服务状态，先读失败原因。

systemctl status 服务名

状态输出里最有价值的是两行：Active 后面的状态（failed、inactive、activating）和最后几行的日志片段——systemd 会自动附上该服务最近的日志，很多时候报错原因直接就写在这里，比如"address already in use"（端口被占）或权限被拒。

第二步，用 journalctl 调完整日志。

journalctl -u 服务名 -n 50 --no-pager
journalctl -u 服务名 --since "10 min ago"

-u 按服务单元过滤日志，-n 50 看最近 50 行，--since 按时间范围取。服务反复崩溃时，加上 -p err 只看错误级别，日志量立刻清爽。对比几次启动失败的日志，通常能发现共同的报错行——配置文件路径写错、依赖的目录不存在、数据库连不上，都是高频原因。

第三步，改完之后确认开机自启与依赖。

systemctl enable 服务名
systemctl list-dependencies 服务名

修好故障后别忘了 enable 让服务开机自启，systemctl is-enabled 服务名 可以确认。如果服务依赖网络或数据库，检查对应的依赖声明是否配好，否则重启服务器后又会"莫名"起不来。

三点提醒：一是改服务相关的 systemd 单元文件后要执行 systemctl daemon-reload 再重启服务，否则改的不生效；二是日志别只盯着自己服务，journalctl -xe 能看到前后时间线上系统级的事件（磁盘满、OOM 杀进程）往往是服务挂掉的真正推手；三是排查记录要留档，同类故障第二次出现时直接翻台账，比重新查一遍快得多。服务故障不可怕，可怕的是没有日志意识——systemd 时代，答案基本都在 journalctl 里。贵州诚鑫致达科技提供 Linux 服务器运维与故障处理服务，欢迎在各大平台搜索关注"贵州诚鑫致达科技"，了解我们的做法。

（约 880 字）

企业存储选型参考｜贵州诚鑫致达

做高可用与业务不间断保障，群晖机型参考：PAS7700 · RS2423RP+ · SA3410。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。

服务区域｜贵州诚鑫致达

贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。凯里（黔东南）、都匀（黔南）：企业存储方案与 IT 运维。