日志写入失败八成是权限没配对，需依次检查目录及文件属主权限、运行用户是否在adm组、SELinux/AppArmor限制、父目录执行权限。

日志写入失败，八成是权限没配对——不是用户没权限，而是目录或文件的属主、组、权限位卡住了，再或者被 SELinux 拦了。下面几块直接对应常见堵点，照着查基本能定位。

检查日志路径的属主与权限

先看日志目录和文件本身是否允许当前进程写入：

• 用 ls -ld /var/log/myapp/ 查目录权限，确保服务运行用户（如 www-data、myuser）有写权限；典型安全配置是 drwxr-s---（属组可写），此时需确认用户在对应组内
• 用 ls -l /var/log/myapp/app.log 查日志文件权限，640 或 644 较稳妥；若为 444 或 600 且非 root 运行，普通服务进程必然写不进
• 注意：目录必须有执行权限（x）才能进入。例如路径 /var/log/myapp/，需确保 /var、/var/log、/var/log/myapp 每一层对运行用户都有 x 权限；否则报 “Permission denied” 其实是进不去，不是写不了

确认服务实际运行身份

不能只看配置文件写的用户，要查真实进程：

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• 用 ps aux | grep myapp 或 ps -eo pid,user,comm,args | grep myapp 查进程 UID 和启动命令
• 若使用 systemd，执行 systemctl show --property=User,Group myapp.service 看配置，再用 systemctl status myapp 确认当前是否按预期用户启动
• 某些服务（如 nginx、rsyslog）默认以特定用户（www-data、syslog）运行，但配置中可能误设为 root，或未同步调整日志路径权限

验证用户是否在必要系统组中

很多日志目录（如 /var/log/）默认只允许 root 和 adm 组成员读写：

• 运行 groups your_user 看是否含 adm；不含就加：sudo usermod -aG adm your_user
• 某些发行版还依赖 syslog 组，可一并检查
• 加完别忘了重启服务，让新组权限生效；也可临时切用户测试：sudo -u your_user touch /var/log/test.log

排查 SELinux 或 AppArmor 干预

即使传统权限全对，也可能被安全模块静默拦截：

• RHEL/CentOS/Fedora 系统运行 sestatus 看状态；若为 Enforcing，先临时切宽容模式验证：sudo setenforce Permissive，再试写日志
• 查看拒绝记录：sudo ausearch -m avc -ts recent | grep denied | grep log；或用 audit2why 解析
• Ubuntu/Debian 系统运行 sudo aa-status，确认是否拒绝写日志路径；可用 sudo aa-logprof 自动补全策略
• 修复建议优先生成合规策略模块，不要长期禁用安全模块

不复杂但容易忽略