journalctl --sync 不存在，确保日志落盘需通过 systemd-journald 的 SIGUSR1 信号触发 flush、配置 SyncIntervalSec 及必要时执行 sync 命令。
journalctl --sync 并不存在，也不是 journalctl 的合法选项。
journalctl 是 systemd 日志系统的查询工具，它不负责写日志，也不控制日志刷盘行为。日志的持久化由 journald 守护进程本身管理，而 journalctl 只是读取和显示已落盘（或内存中）的日志数据。
你真正想问的，其实是：
如何确保 systemd-journald 已将内核缓冲区或内存中的日志强制写入物理磁盘？
答案不是靠 journalctl，而是通过以下三类机制协同实现：
✅ journald 自身的同步策略
journald 默认启用 Storage=persistent（需 /var/log/journal 存在且可写），此时：
- 日志会先写入内存缓冲（ring buffer），再异步刷入
/var/log/journal/*/system.journal - 刷盘时机由
SyncIntervalSec=（默认 5s）和RateLimitIntervalSec=等配置控制 - 关键操作（如关机、服务停止）会触发
fsync()，确保日志落盘
你可以检查当前配置：
systemctl show --property=JournalStorage /etc/systemd/journald.conf # 或直接查看 grep -E "^(Storage|SyncIntervalSec)" /etc/systemd/journald.conf
✅ 手动触发日志刷盘：用 systemctl kill --signal=SIGUSR1 systemd-journald
这是官方支持的“强制 flush”方式：
-
SIGUSR1信号会通知 journald 将所有内存日志立即写入磁盘并fsync() - 不重启服务，不影响日志采集
- 执行后可立刻用
journalctl -n1验证最新条目是否已可见（尤其对刚写入但未刷盘的日志）
示例：
sudo systemctl kill --signal=SIGUSR1 systemd-journald # 等待返回后，确认日志已落盘 journalctl -n1 --no-pager
✅ 确保底层文件系统同步：仍需 sync 配合
即使 journald 调用了 fsync()，若存储设备开启 write-back 缓存（如多数 SATA SSD/机械盘默认）、或使用了 noatime,nobarrier 挂载选项，日志仍可能卡在设备缓存中。
这时，在关键操作后执行 sync 是最后一道防线：
sudo systemctl kill --signal=SIGUSR1 systemd-journald sync # 强制刷所有挂载点（含 /var/log/journal 所在分区）
⚠️ 注意：sync 不针对日志，而是刷整个文件系统；但它能确保 journald 写入的 .journal 文件真实抵达物理介质。
❌ 常见误区澄清
-
journalctl --sync：命令报错，无此选项（journalctl 80+ 版本均未定义） -
journalctl --flush：不存在；--flush是旧版systemd-cat的参数，与 journalctl 无关 -
echo 3 > /proc/sys/vm/drop_caches：清的是 page cache（读缓存），对 journald 的写缓冲无效 - 单纯
systemctl restart systemd-journald：会丢弃内存中未刷盘日志，不推荐用于“保日志”
不复杂但容易忽略。真正起作用的是 journald 的信号机制 + 底层 sync 配合，而不是一个虚构的 journalctl 参数。
