journalctl -u 服务名 不显示日志或丢失最近条目的常见配置坑

journalctl -u 服务名查不到日志的四大原因：一是journald未持久化，日志仅存内存；二是服务启动过快或闪退，日志未被捕获；三是日志被截断或轮转策略过严；四是服务输出被重定向或后台运行绕过journal。

journalctl -u 服务名 查不到日志或看不到最新记录，多数不是命令用错，而是 systemd-journald 的配置或服务自身行为导致的。下面几个坑最常见、最容易忽略。

journal 未持久化存储（默认只存内存）

systemd-journald 默认把日志写在 /run/log/journal（tmpfs 内存文件系统），重启后全部清空，服务刚启动的日志可能还没刷到磁盘就丢了。

• 检查是否启用持久化：ls /var/log/journal/ —— 若目录不存在或为空，说明没开启
• 启用方法：创建目录并赋权：
  sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
• 重启 journald：sudo systemctl kill --signal=SIGUSR1 systemd-journald（或 sudo systemctl restart systemd-journald）

服务启动太快、日志来不及捕获（尤其 Type=oneshot 或 ExecStartPre 失败）

如果服务进程启动后立即退出（如配置错误、依赖未就绪），journal 可能根本没来得及接管 stdout/stderr，或者只记了极短生命周期内的少量输出。

• 用 systemctl status 服务名 看 “Main PID” 和 “State” —— 如果显示 “exited” 或 “failed”，但 journalctl -u 没内容，大概率是进程闪退太快
• 加调试手段：在 service 文件里临时加上 StandardOutput=journal+console 和 StandardError=journal+console，强制所有输出进 journal
• 对 Type=oneshot 服务，确保 RemainAfterExit=yes（否则 unit 状态变 inactive 后，journal 可能不关联后续日志）

journald 日志截断或轮转策略太激进

即使开启了持久化，journald 仍可能因空间限制自动删旧日志，导致“最近条目丢失”——其实是被删了，不是没生成。

• 查当前限制：journalctl --disk-usage 和 cat /etc/systemd/journald.conf | grep -E "^(SystemMaxUse|SystemMaxFileSize|MaxRetentionSec)"
• 常见问题配置：
  • SystemMaxUse=50M（默认值较小）→ 建议调大，如 200M
  • MaxRetentionSec=1week → 若服务日志量大，一周内就填满，旧日志被强制清理
• 改完记得重启 journald：sudo systemctl restart systemd-journald

服务日志被重定向或绕过 journal（常见于自定义启动脚本）

如果 service 文件中 ExecStart= 调用了 shell 脚本，且脚本里用了 > /dev/null 2>&1 或 nohup ... &，stdout/stderr 就不会进入 journal。

• 检查 service 定义：systemctl cat 服务名，重点看 ExecStart= 行是否含重定向、后台符号（&）、exec -a 等绕过方式
• 安全写法示例：
  ExecStart=/usr/bin/myapp --config /etc/myapp.conf
  避免：ExecStart=/bin/sh -c '/usr/bin/myapp > /var/log/myapp.log 2>&1 &'
• 若必须重定向，至少保留 journal 接口：ExecStart=/bin/sh -c '/usr/bin/myapp 2>&1 | systemd-cat -t myapp'