journalctl -u 服务名.service 看不到日志需先确认服务已注册；启动失败无具体错误应加 -n 50 --no-pager 查最近日志；报错藏在 starting 后几行；优先用 -p err 过滤错误级日志；空日志时检查 execstart 路径、权限及 type 配置。
journalctl -u 服务名.service 看不到报错？先确认服务已注册
服务没被 systemd 认出来，journalctl -u 就查不到任何日志。运行 systemctl list-units --type=service | grep 服务名，如果没输出，说明 unit 文件没生效。常见原因包括：文件没放在 /etc/systemd/system/ 或 /usr/lib/systemd/system/；文件名不带 .service 后缀；没执行 systemctl daemon-reload。
启动失败时只看到 “Failed” 而无具体错误？必须加 -n 和 --no-pager
journalctl -u 服务名.service 默认从最老日志开始翻，失败瞬间的错误往往被埋在几百行之前。真正有用的组合是：
-
journalctl -u 服务名.service -n 50 --no-pager：只看最近 50 行，不翻页，错误通常就在顶部几行 -
journalctl -u 服务名.service --since "2 minutes ago" --no-pager：刚执行过systemctl start，就用这个锁定时间窗 - 重点盯紧以
Starting开头的行后面紧跟的那几行——真正的报错（比如Permission denied、cannot open shared object file、bind: address already in use）几乎都紧随其后
报错里有中文或乱码？优先级过滤比关键词更可靠
有些服务（如 Python 脚本、Node.js 进程）崩溃时 stderr 输出可能被截断或编码异常，grep -i error 容易漏。更稳的做法是按日志级别抓：
-
journalctl -u 服务名.service -p err：只显示错误级（level 3）及以上日志，排除干扰 -
journalctl -u 服务名.service -p 3..5：同时抓 error、warning、notice，覆盖常见启动提示（如配置加载成功但端口冲突） - 若看到
Failed with result 'exit-code'或Failed with result 'timeout'，立刻回看systemctl status里的status=值和ExecStart=命令，这两者必须一起解读
日志里啥都没有？可能是服务根本没运行起来
空日志 ≠ 没问题，很可能是 systemd 连进程都没拉起来。这时要检查：
-
systemctl cat 服务名.service：确认ExecStart=路径存在且可执行（ls -l /路径/到/命令） -
systemctl show 服务名.service --property=User,Group,WorkingDirectory,Environment：手动模拟环境，比如sudo -u 用户名 /path/to/exec --help，常暴露 PATH 缺失、工作目录不存在、配置文件权限不对等问题 - 若服务类型是
Type=forking，但程序没按预期 fork，systemd 会静默超时退出，此时日志为空——改用Type=simple+ExecStartPre=加个简单校验脚本，能快速验证是否卡在前置环节
journalctl 输出的第一行非 systemd 自身提示的内容里，而不是 systemctl start 那句 “failed”。很多人反复 reload、restart，却忘了日志末尾那行不起眼的 libpq.so.5: cannot open shared object file 才是根因。
