systemctl list-dependencies 命令可查看服务依赖关系，需配合--all、--reverse、--type=after等参数精准分析正向/反向依赖、启动时序及状态验证。
直接用 systemctl list-dependencies 就能看清服务之间的启动依赖关系，关键是要选对参数——它不只显示“谁要谁”，更反映实际启动时的先后顺序和强弱约束。
正向查：这个服务启动前必须有哪些准备
运行 systemctl list-dependencies 服务名，比如 systemctl list-dependencies nginx.service，默认列出一级 Wants/Requires/After 关系。但真正影响启动成败的是完整链路：
- 加
--all展开全部层级：systemctl list-dependencies --all nginx.service，看到 network.target → systemd-networkd.service → local-fs.target 这类间接路径 - 聚焦启动阻塞点：用
--type=after，例如systemctl list-dependencies --type=after nginx.service，只显示 After= 字段定义的时序依赖，比如After=network-online.target，这才是真正决定“能不能开始启动”的顺序依据 - 限制深度防干扰：依赖树太深时加
--depth=2，快速定位核心前置项，避免被底层 target 冗余信息淹没
反向查：哪些服务靠它才能起来
停一个服务前，得知道会不会连带崩掉别的服务。用 --reverse 找出所有显式依赖它的单元：
-
systemctl list-dependencies --reverse sshd.service显示直接声明 Wants/Requires 的服务 - 加
--all补全未启用或未安装的依赖者：systemctl list-dependencies --reverse --all docker.service，尤其能捕获 WantedBy=multi-user.target 这类 target 级反向引用 - 注意：WantedBy 不会出现在正向输出里，只靠 --reverse 才能发现
看原始配置：确认依赖是否写对了
命令输出只是结果，源头在 .service 文件。用 systemctl cat 服务名 查看真实声明：
- 重点检查 [Unit] 段里的
Requires=（强依赖，缺失则本服务不启动）和Wants=（弱依赖，缺失不影响本服务） - 验证
After=是否配合 Requires/Wants 使用：单独写After=redis.service不触发依赖，必须同时有 Wants 或 Requires 才生效 - 若某行写
Requires=mysqld.service但系统实际叫mariadb.service，systemctl verify 服务名会直接报 not-found 错误
验证运行时是否真满足
配置写对了，不代表运行时就通——得看状态和日志：
-
systemctl status 服务名中的 Loaded 行提示 “not-found” 或 “masked”，说明依赖单元根本不存在或被禁用 - Active 行显示 failed due to dependency，再结合
journalctl -u 服务名 -n 20，常能看到 “Failed to start xyz.service: Unit xyz.service not found” 这类明确提示 - 对关键二进制，用
ldd $(systemctl show -p ExecStart 服务名 | cut -d= -f2 | awk '{print $1}')检查共享库依赖，避免 systemctl 启动成功但程序运行时报 cannot open shared object file
