Linux日志丢失主因是数据滞留内核页缓存未落盘，写入路径含用户态缓冲、page cache、异步回写及磁盘写缓存；journald默认延迟刷盘，需调优SyncIntervalSec等参数；应用应使用O_SYNC或显式fsync保障可靠性。
Linux日志丢失，往往不是程序没写，而是写入后卡在内核缓冲区里没落盘——尤其在系统崩溃、断电或强制重启时，缓冲区中尚未刷出的日志就彻底消失了。
日志写入路径：从应用到磁盘的多层缓冲
大多数日志（如 syslog、journal、自定义文件）默认走 libc 的 stdio 缓冲机制 或直接调用 write() 系统调用，但无论哪种，数据通常先到用户态缓冲区（如 fopen + fprintf），再进内核页缓存（page cache），最后由内核异步刷到磁盘。这个过程存在多个“滞留点”：
- 用户态 FILE 流默认是行缓冲（终端）或全缓冲（文件），不显式 fflush() 就不会触发 write()
- 即使调用了 write()，数据只是进入内核 page cache，不调用 fsync() / fdatasync()，就不保证落盘
- 内核通过 pdflush/kswapd/bdi-writeback 等机制批量回写，间隔通常为 30 秒（受 dirty_expire_centisecs 控制）
- 块设备层和磁盘固件还可能启用写缓存（Write Cache），进一步延迟物理写入
systemd-journald 的刷盘行为与配置要点
journal 日志看似“自动持久”，实则默认采用 延迟刷盘策略：日志写入内存 ring buffer 后，仅在以下任一条件满足时才刷入 /var/log/journal：
- 收到 sync 请求（如 systemctl kill --signal=SIGUSR1 systemd-journald）
- journal 文件达到大小阈值（SystemMaxUse，默认约 10% /var）
- 空闲超时（默认 5 分钟，由 RuntimeMaxUse / SystemMaxUse 间接影响）
- 服务重启或正常 shutdown（此时会强制 flush）
若想降低丢失风险，可修改 /etc/systemd/journald.conf：
- Storage=persistent（确保日志存到磁盘，而非 volatile）
- SyncIntervalSec=10s（主动触发刷盘频率，最小支持 1s）
- FlushLevel=info 或更低（控制哪些级别日志强制同步，慎用，影响性能）
- 禁用磁盘写缓存：echo 0 > /sys/block/sdX/queue/diskseq（需硬件支持且谨慎操作）
应用程序日志的可靠写入实践
开发者不能依赖“写了就等于落盘”。关键动作包括：
- 使用 O_SYNC 或 O_DSYNC 标志打开日志文件（open(..., O_WRONLY|O_APPEND|O_SYNC)），让每次 write() 都等待落盘
- 若用 stdio（如 fprintf + fclose），务必在关键日志后调用 fflush(fp)；对重要错误，建议再加 fsync(fileno(fp))
- 避免频繁小写：可启用缓冲 + 定期 flush（如每 10 条或 1 秒），平衡可靠性与性能
- 考虑用 sync_file_range() 或 posix_fadvise(POSIX_FADV_DONTNEED) 精细控制缓存行为
验证日志是否真正落盘
不能只看文件 size 或 mtime 变化。有效手段有：
- 用 strace -e trace=write,fsync,fdatasync your_app 观察系统调用是否发出 fsync
- 检查 page cache 占用：cat /proc/meminfo | grep -i dirty，关注 Dirty 和 Writeback 字段
- 模拟断电前手动触发：sync && echo 3 > /proc/sys/vm/drop_caches（后者仅清 page cache，不影响已 sync 数据）
- 用 hdparm -I /dev/sdX | grep "Write cache" 确认磁盘写缓存是否启用
