systemd隐式依赖需分层排查：用systemctl show查单元关联，ldd查共享库，strace捕获启动时文件访问，journalctl日志反向验证；无法全自动猜出，但组合命令可逼近全景。
直接查隐式依赖不能靠一条命令“全自动猜出全部”，因为 systemd 本身不记录运行时动态行为（比如程序启动后读哪个配置、加载哪个 .so、连接哪个 socket）。但你可以用一条组合命令快速逼近真实依赖全景，关键在于分层抓取：单元声明 + 启动行为 + 日志证据。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
查 systemd 层面的完整隐式关联单元
运行这条命令：systemctl show --property=WantedBy,RequiredBy,Also,Triggers,Conflicts,BindsTo --all 服务名 | grep -v "^$" | sort -u
它会一次性列出所有可能拉起或绑定该服务的单元，包括 .wants/、.requires/ 目录下的软链接关系，以及 BindsTo=、Triggers= 等易被 list-dependencies 忽略的强耦合项。例如 sshd.service 可能被 multi-user.target.wants/ 链接，也可能被 dbus.socket 触发，这些都会暴露出来。
查二进制级隐式依赖（共享库与文件路径）
用一行命令定位主程序并检查：ldd $(systemctl show -p ExecStart 服务名 | grep -o '/[^[:space:]]*' | head -n1 2>/dev/null) 2>/dev/null | grep "not found\|=> /"
如果输出含 not found，说明缺共享库；如果路径异常（如指向 /usr/local/lib 但该目录不存在），就是运行时隐式依赖断裂点。
查启动瞬间的真实文件访问行为
执行：strace -e trace=openat,openat2,stat,connectat -f systemctl start 服务名 2>&1 | grep -E "(No such|Permission denied|failed|->.*\.so|/etc/|/var/)" | head -20
它能捕获服务刚启动时试图打开的配置文件、证书路径、socket 地址等——这些从 unit 文件里完全看不到，却是实际失败的根源。
结合日志反向验证依赖链是否生效
运行：journalctl -u 服务名 --since "1 hour ago" -n 50 | grep -E "(fail|error|cannot|refused|No such|denied)"
若日志出现 Failed to connect to /run/dbus/system_bus_socket，就说明它隐式依赖 D-Bus，但 unit 文件里没写 Wants=dbus.service，这就是典型的“漏声明”型隐式依赖。
不复杂但容易忽略
