Linux 日志丢失主因是服务未运行、轮转误删、journald 非持久化、磁盘 /inodes 耗尽或权限 /SELinux 异常。需依次检查 rsyslog/journald 状态、logrotate 配置、Storage 设置、df -h/- i 结果及 /var/log 权限与 SELinux 上下文。
Linux 系统日志丢失可能影响故障排查与安全审计，通常并非日志从未生成，而是因配置、权限或存储机制异常导致日志未被写入、被覆盖或无法读取。以下是常见原因的详细说明：
一、rsyslog 或 journald 服务未运行
系统日志依赖后台服务持续收集和转发日志消息。若 rsyslog（传统 SysV 日志守护进程）或 systemd-journald（现代 systemd 日志服务）处于非活动状态，则内核、用户进程等产生的日志将不会被持久化保存。
1、执行 systemctl status rsyslog 检查 rsyslog 是否启用并正在运行。
2、若输出中显示 inactive (dead) 或 failed，则需启动该服务：sudo systemctl start rsyslog。
3、对 systemd 系统，同时检查 journald：systemctl status systemd-journald，确认其状态为 active (running)。
二、日志轮转配置错误导致日志被误删
logrotate 工具按周期压缩、归档或删除旧日志文件。若配置不当（如 rotate 数值过小、启用 removeold 且未保留足够副本），可能导致近期日志被强制清除。
1、查看主轮转配置：cat /etc/logrotate.conf，重点关注 rotate、daily/weekly、missingok 和 sharedscripts 设置。
2、检查应用专属配置，例如：ls /etc/logrotate.d/ | grep -E “(rsyslog|syslog|journal)”。
3、模拟轮转测试：sudo logrotate -d /etc/logrotate.conf，观察调试输出中是否包含意外的 removing old log 行。
三、journald 存储模式设为 volatile
systemd-journald 默认将日志存于内存（/run/log/journal），该路径在重启后清空。若未启用持久化存储，系统重启后所有 journal 日志将不可恢复。
1、检查当前存储类型：cat /etc/systemd/journald.conf | grep Storage=。
2、若返回 Storage=volatile，则说明日志仅驻留内存。
3、修改配置文件：sudo sed -i ‘s/^#Storage=auto/Storage=persistent/’ /etc/systemd/journald.conf，并确保 /var/log/journal/ 目录存在且属主为 root:systemd-journal。
四、磁盘空间耗尽或 inodes 耗尽
日志写入失败常表现为“无错误但无新增内容”，实际是由于目标文件系统无可用空间或 inode 资源枯竭，导致 write() 系统调用静默失败。
1、检查根分区使用率：df -h /，确认 Use% 未达 100%。
2、检查 inodes 使用情况：df -i /，若 IUse% 接近 100%，即使磁盘空间充足，日志也无法创建新文件。
3、定位高 inode 占用目录：sudo find /var/log -xdev -type f | cut -d/ -f1-4 | sort | uniq -c | sort -n，识别异常子目录。
五、日志文件权限或 SELinux 上下文异常
rsyslog 进程以 syslog 用户身份运行，若日志目标目录（如 /var/log/messages 所在路径）权限拒绝写入，或 SELinux 策略阻止 syslog_t 域访问文件，日志将被丢弃且不报错。
1、验证日志目录权限：ls -ld /var/log，应至少具备 drwxr-xr-x；检查日志文件属主：ls -l /var/log/messages，正常应为 root:syslog。
2、若启用 SELinux，检查上下文：ls -Z /var/log/messages，预期类型为 var_log_t；若为 unlabeled_t 或 default_t，需修复：sudo restorecon -v /var/log/messages。
3、临时验证 SELinux 影响：sudo setenforce 0 后观察日志是否恢复写入（注意：此操作仅用于诊断，勿长期禁用）。
