linux日志无法写入最常见的原因是权限不匹配，其次为selinux/apparmor限制、磁盘或inode耗尽、文件被占用或损坏；排查应按磁盘状态→文件属性→归属权限→安全模块顺序进行。
Linux日志无法写入，最常见的原因是权限不匹配——日志文件或其所在目录的属主、属组或权限设置不满足服务进程的写入要求。
日志文件或目录归属错误
很多服务（如 nginx、rsyslog、custom daemon）以非 root 用户身份运行（如 www-data、syslog、daemon），但日志路径可能被 root 创建且未开放写入权限。
- 检查日志路径归属：
ls -ld /var/log/myapp/和ls -l /var/log/myapp/app.log - 确保目录对服务用户可写：若服务以 myuser 运行，目录应属 myuser:mygroup 或至少有 g+w 且用户在该组中
- 避免直接用
chown root:root后忘记调整——这是典型误操作
SELinux 或 AppArmor 强制限制
即使传统权限正确，启用 SELinux（RHEL/CentOS/Fedora）或 AppArmor（Ubuntu/Debian）时，策略可能禁止服务写入特定路径。
- RHEL系检查：运行
ausearch -m avc -ts recent | grep denied，或临时设为 permissive 模式测试：setenforce 0 - Ubuntu系检查：
sudo aa-status，查看是否拒绝写日志路径；可用sudo aa-logprof自动补全策略 - 不要长期禁用安全模块，应生成并加载合规策略
磁盘满或 inode 耗尽
日志写入失败有时与权限无关，而是底层存储异常。
- 检查磁盘空间：
df -h——特别注意/var或日志所在挂载点 - 检查 inode 使用：
df -i——小文件大量堆积（如轮转残留）易耗尽 inode - 常见诱因：logrotate 未生效、应用疯狂打日志未限速、临时文件未清理
日志文件被其他进程占用或损坏
某些情况下，日志文件处于不可写状态并非权限问题，而是文件本身异常。
- 用
lsof /var/log/myapp.log查看是否被其他进程（如 tail -f、cat、编辑器）独占打开 - 确认文件未被设为不可修改：
lsattr /var/log/myapp.log，若输出含 i（immutable），需chattr -i解除 - 极端情况：文件系统只读挂载（
mount | grep ro）、NFS 服务端拒绝写入、ext4 journal 错误等
排查时建议按「磁盘状态 → 文件属性 → 归属与权限 → 安全模块」顺序进行，多数问题集中在前两项。定位后，优先用最小权限修复，避免过度开放（如 chmod 777）引入安全隐患。
