journalctl -xe 是排查服务启动失败最直接的命令，它聚焦当前会话最新日志、自动跳至末尾并显示结构化解释性信息，呈现完整启动上下文及依赖失败链路。
journalctl -xe 是排查服务启动失败最直接的命令，它默认聚焦于当前终端会话中最近的系统日志，并自动跳转到最新条目，适合实时观察服务启动过程中的单元加载、依赖解析和执行失败细节。
理解 -xe 参数的真实作用
其中 -x 表示显示带解释性文本的结构化日志（如 systemd 单元状态变更、依赖缺失提示），-e 表示“跳至日志末尾并启用滚动模式”，相当于进入“实时追尾”状态。它不是只看某个服务，而是呈现整个启动上下文——包括被依赖单元（如 network.target、dbus.socket）的失败链路。
精准定位失败服务及其依赖报错
- 启动前先运行
systemctl status your-service.service，记下失败时间戳（如Mar 12 10:23:45） - 立即执行
journalctl -xe --since="2024-03-12 10:23:40"，把时间窗口缩窄到失败前后 10 秒内，避免被无关日志淹没 - 重点查找含
Failed to start、Dependency failed、Unit xyz.service not found、Timed out waiting for的行，这些往往是底层调用中断点 - 向上翻看同一时间戳附近的
Starting...和Started...记录，确认哪些前置单元根本没触发或卡在中间
结合单元依赖图辅助判断
仅靠日志有时难以理清依赖顺序。可同步运行：systemctl list-dependencies --reverse --all your-service.service
查看哪些单元声明了对它的依赖；再用systemctl list-dependencies your-service.service
确认它自身 Requires/Wants/After 的单元是否就绪。若某依赖单元在 journalctl -xe 中无任何日志输出，大概率是它根本未被触发（例如因 ConditionPathExists= 不满足而被跳过）。
常见底层报错类型与对应线索
-
“Unit xyz.service failed to load: No such file or directory.” → 检查
/usr/lib/systemd/system/或/etc/systemd/system/下文件是否存在且权限为 644 -
“Failed to start xyz.service: Unit xyz.service is masked.” → 运行
systemctl unmask xyz.service后重试 -
“Dependency failed. Refusing to start.” → 日志中必有前一行指出具体哪个 Required 单元处于
inactive (dead)或failed状态 -
“Timed out waiting for /dev/xxx” → 可能是 udev 规则未就绪、设备未识别，或
Wants=dev-xxx.device但该 device 单元超时
