最权威方法是用journalctl -b查systemd服务日志，辅以dmesg查内核硬件初始化、/var/log/boot.log等传统日志交叉验证，并先用systemctl list-unit-files --state=enabled确认服务确已启用。
排查开机启动项，关键不是找“一个日志文件”，而是分层查三类来源：systemd 服务单元的日志（最权威）、内核与硬件初始化日志（底层原因）、传统文本日志（辅助验证）。现代 Linux（Ubuntu 22.04+、CentOS 7+、Debian 11+）默认用 systemd，所以 journalctl -b 是第一入口，不是可选项。
查 systemd 管理的开机服务（含自定义 .service）
所有通过 systemctl enable 设置的开机启动项，其执行过程都会被 journalctl 完整捕获：
-
journalctl -b：查看本次开机从内核加载到服务就绪的全部记录，时间准、服务名明确、错误上下文完整 -
journalctl -b -p err：只显示错误级及以上日志（err/crit/alert/emerg），快速定位失败点 -
journalctl -u your-service-name.service -b：聚焦某个具体服务，比如mjpg.service或nginx.service -
journalctl -b --no-pager | grep -E "(failed|timeout|denied)"：避免卡在 less 分页器里，同时高亮关键线索
查内核与硬件层面的启动障碍
如果服务根本没开始启动（比如连 “Starting…” 都没出现），问题可能出在更早阶段——内核加载驱动、挂载根文件系统、initramfs 解包失败等。这时 dmesg 不可替代：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
dmesg：输出内核环形缓冲区原始内容，从 GRUB 交权那一刻起，包括 CPU/内存/PCIe/磁盘识别全过程 -
dmesg -l warn,err：按内核定义的日志等级过滤，比grep error更精准（不会误匹配模块名里的 “error”） -
dmesg | grep -i "nvme\|ata\|usb\|failed"：针对性查存储或外设初始化失败 - 若
dmesg输出极短或为空，说明内核可能根本没跑起来，需检查 GRUB 参数或 initrd 镜像
查传统日志文件（仅作交叉印证）
/var/log/ 下的文本日志已非主力，但仍有价值，尤其当 journald 持久化未启用或需对比时：
-
/var/log/boot.log：记录 init 进程启动服务的简要顺序（部分发行版仍写入） -
/var/log/messages（RHEL/CentOS）或/var/log/syslog（Debian/Ubuntu）：可能包含 SELinux 拦截、权限拒绝、挂载失败等补充信息 -
/var/log/secure或/var/log/auth.log：若启动项涉及 sudo、su 或 ssh-key 加载，这里会有认证失败记录 -
/var/log/journal/：若启用了 journald 持久化，结构化日志就落在此目录，按机器 ID 子目录存放
顺带确认启动项是否真被激活
日志再全，前提是服务确实被 systemd 认为该启动。先快速过一遍基础状态：
-
systemctl list-unit-files --state=enabled：列出所有标记为开机启用的服务 -
systemctl is-enabled your-service.service：确认某服务是否启用 -
systemctl list-dependencies --after your-service.service：看它依赖哪些 target（如network.target），若依赖未就绪，服务会被跳过 -
systemctl cat your-service.service：检查 Unit 文件里WantedBy=是否写对（常见错写成multi-user.target却漏掉After=网络）
