journalctl -u 服务名查不到日志，首要确认服务是否启用并产生日志：检查 systemctl is-active 和 status，确保已由 systemd 启动且日志未被轮转清空；时间过滤必须用 --since/--until，推荐 ISO 8601 或相对时间格式；查失败原因需关注 _PID、UNIT、MESSAGE 字段，配合 -o json-pretty 或 grep 错误关键词；日志丢失可能因 journald 未启用持久化或系统时间不同步。
journalctl -u 服务名查不到日志？先确认服务是否启用并产生日志
直接运行 journalctl -u nginx 却返回空，大概率不是命令写错，而是该服务根本没启动过、没输出日志，或者日志被轮转清空了。systemd journal 默认只保留最近的若干天（通常 1–2 周），且仅记录由 systemd 启动的服务——手动用 ./nginx 启动的进程不会进入 journal。
- 先用
systemctl is-active nginx确认服务当前状态（active或inactive） - 再用
systemctl status nginx查看最近一次启动/失败时间，比对 journal 时间范围是否覆盖 - 若服务刚启用但无日志，尝试
sudo systemctl restart nginx触发一次完整生命周期，再查
按时间段过滤必须加 --since 和 --until，不能只靠 -u
journalctl -u sshd 默认查全部历史，想限定“昨天下午 3 点到今天上午 9 点”，必须显式指定时间边界。journalctl 不支持自然语言（如 --since="yesterday" 虽然能用，但精度低、易歧义），推荐用 ISO 8601 格式或相对时间戳。
- 查最近 2 小时：
journalctl -u crond --since "2 hours ago" - 查某天整日：
journalctl -u docker --since "2024-05-20 00:00:00" --until "2024-05-21 00:00:00" - 注意：--until 默认不含末尾时刻，
--until "2024-05-21"实际截止到当天 00:00:00，如需包含全天，设为"2024-05-21 23:59:59"
查服务启动失败原因，重点看 _PID= 和 MESSAGE 字段
服务启动失败时，journal 日志里往往混着内核、systemd、服务自身多层输出。journalctl -u mysql --since "1 hour ago" -n 50 只是看尾巴，容易漏关键线索。真正有用的字段是 _PID（进程 ID）、UNIT（单元名）、MESSAGE（原始日志内容），配合 -o json-pretty 或 --output-fields 可定位源头。
- 快速筛选错误行：
journalctl -u mariadb --since "30 minutes ago" | grep -i "fail\|error\|exit\|cannot" - 看完整启动上下文（含 systemd 的 ExecStart 记录）：
journalctl -u mariadb --since "2024-05-20 14:00:00" -n 100 --no-pager - 若日志量大卡顿，加
--no-pager避免 less 占用终端；想导出分析，重定向到文件：journalctl -u nginx --since "2024-05-19" > nginx-log-20240519.log
journalctl 时间不准？和系统时钟、时区、journald 配置强相关
如果发现 --since "10 minutes ago" 查到的日志时间戳显示是 3 小时前，别急着怀疑命令，先检查系统时间同步状态和 journald 是否启用持久化存储。journal 默认把日志存在 /run/log/journal/（内存临时目录），重启后丢失，且时间戳基于本地时钟，不自动转 UTC。
- 检查时间同步：
timedatectl status看System clock synchronized: yes是否为 true - 确认 journald 持久化：
ls /var/log/journal/应有子目录；若为空，编辑/etc/systemd/journald.conf，取消注释Storage=persistent并重启systemd-journald - 时区影响显示但不影响查询逻辑：
journalctl输出的时间默认按本地时区格式化，但--since解析时始终以系统本地时间为基准，无需手动换算
journalctl -u --since "" --until "" -n 200 --no-pager，再配合 grep 或逐行翻看 MESSAGE。时间范围宁可宽一点，也别漏掉前置上下文——很多失败根源在启动前的依赖加载阶段，不在报错那一秒。 
