journalctl -u 必须带 .service 后缀，否则报“no journal files”；查日志应加 -b 锁定本次启动，配合 -p err、--since/--until 精准定位，并关联依赖单元与 selinux 日志综合排查。
journalctl -u 服务名.service 必须带 .service 后缀
直接写 journalctl -u nginx 或 journalctl -u sshd 会报错 No journal files were found，因为 systemd 单元名严格区分类型。nginx 对应的单元是 nginx.service，sshd 是 sshd.service，漏掉 .service 就查不到任何日志。
常见错误现象：命令执行后空输出、提示“no logs”，但 systemctl list-units | grep nginx 明明显示 active。这时第一反应不是服务没启，而是后缀写错了。
- 用
systemctl list-unit-files --type=service | grep yourname确认真实单元名 - 通配符可用但不推荐：
journalctl -u "nginx*"可能匹配到nginx.service和nginx-debug.service，干扰判断 - 若服务由 socket 激活（如
sshd.socket），查sshd.service才能看到连接处理日志；查 socket 单元只看到监听行为，看不到实际失败原因
加 -b 查本次启动日志，避免被历史记录干扰
服务刚重启失败，却在 journalctl -u nginx.service 里翻到三天前的成功记录，白白浪费时间。必须加 -b 锁定当前启动周期——journalctl -u nginx.service -b 只显示这次开机以来该服务的所有日志，从 Starting nginx.service 到 Failed to start nginx.service 全链路都在里面。
如果想看上次启动（比如刚重装完系统，怀疑是配置残留导致失败），用 journalctl -u nginx.service -b -1；先运行 journalctl --list-boots 确认可用的 boot ID，避免 -2 指向错误周期。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
-b是排查“为什么刚改完就起不来”的黄金参数，不加它等于在日志海洋里盲捞 - 配合
-p err过滤错误：journalctl -u nginx.service -b -p err直接聚焦失败关键行 - 若服务启动极快又失败（如语法错误），
journalctl -u nginx.service -b -n 50查最后 50 行比全量更高效
用 --since 和 --until 缩小时间窗，避开无关日志
重启后等了两分钟才查日志，结果 journalctl -u nginx.service -b 输出上千行，真正出错的只有开头几行。时间范围筛选不是锦上添花，而是刚需。
例如服务在 20:02:15 启动失败，运行：journalctl -u nginx.service -b --since "2026-09-20 20:02:10" --until "2026-09-20 20:02:25"，精准捕获那 15 秒内的所有动静。注意 --until 不支持 "30 seconds ago" 这类相对写法，只能用绝对时间或 "now"。
- 相对时间仅
--since支持：--since "1 minute ago"安全，--since "yesterday"自动补为 00:00:00 - 跨时区协作务必加
--utc，否则本地时间显示可能和实际日志时间差 8 小时 - 大量日志下加
--no-pager避免卡在 less 分页器里，尤其配合| head -n 20快速定位
查失败原因不能只盯服务本身，要拉上下游依赖一起看
很多服务启动失败根本不在自己日志里，而在前置依赖单元中。比如 myapp.service 依赖网络，但 network.target 一直没就绪，myapp 日志里只会显示 “dependency failed”，真正原因藏在 journalctl -u network.target -b 或 journalctl -u systemd-networkd.service -b 里。
另一个高频陷阱是 SELinux 拦截：服务日志里看不到明确拒绝信息，但 journalctl -b | grep avc 会爆出 avc: denied { read } for pid=1234 comm="myapp" 这类线索。还有挂载点未就绪导致服务跳过启动，查 journalctl -u local-fs.target -b 就能确认。
- 先用
systemctl list-dependencies myapp.service --reverse看谁依赖它，再用--all看完整依赖树 -
journalctl -b -p err全局扫一遍错误，常能发现被忽略的底层问题（如内核模块加载失败） - 若服务由用户级 systemd 实例管理（非系统级），需加
--user参数，否则查不到
