日志写不进去八成是权限问题，需逐层检查：先用ls -ld /data/logs查目录权限与归属，确认属主/属组匹配服务用户、末位有w且group/other位有x；再验证服务真实运行身份（ps/pgrep）、SELinux状态（getenforce/ausearch）及挂载选项。
日志写不进去，八成是权限卡住了。先别急着 chmod 777，得顺着权限链一层层查清楚谁在拦路。
看日志目录的权限和归属
重点不是日志文件本身，而是它所在的目录。服务启动用户（比如 app）必须对目录有写权限，才能在里面创建或追加日志文件。
- 运行 ls -ld /data/logs 查目录权限，确认末位是否有 w（写权限），且第三列属主、第四列属组是否匹配服务运行用户
- 如果属主是 root，而服务用 app 用户跑，那即使目录权限是 755，app 也没法写——因为只有属主才有 w 权限
- 正确做法是：sudo chown -R app:app /data/logs，再设合理权限如 750（属主全权，属组可读可进，其他人无权）
确认服务实际运行身份
别只看配置文件写的用户名，得看进程真正在用谁的身份跑：
- 执行 ps -u app -o pid,user,comm 或 pgrep -u app -f java 确认服务进程 UID 和 GID
- 再用 id -u app 和 id -Gn app 查该用户所属组，比对目录属组是否在其中
- 如果服务用 systemd 启动，检查 systemctl show myapp.service | grep -E "(User|Group)"
检查目录执行权限（x）是否缺失
很多人忽略：对目录来说，x 权限 = 能进入 + 能访问里面文件。没 x，连 open() 都会失败，报 Permission denied。
- 运行 ls -ld /data/logs，看权限串第三位（others 位）或第二位（group 位）有没有 x；如果属组是 app，但权限是 750，而 group 位是 5（r-x），那就没问题；如果是 740（r--），那就缺 x，得补上
- 补权限命令：chmod g+x /data/logs（给属组加执行）或 chmod 750 /data/logs（重设整套）
排除 SELinux 或挂载限制干扰
标准权限没问题？可能是更底层的策略在拦截：
- 运行 getenforce，如果是 Enforcing，再查日志：ausearch -m avc -ts recent | grep logs，看是否有 AVC 拒绝记录
- 临时测试是否 SELinux 导致：运行 sudo setenforce 0（切到 Permissive），再试写日志；若恢复，说明需调整策略，例如 sudo semanage fcontext -a -t var_log_t "/data/logs(/.*)?"，然后 restorecon -Rv /data/logs
- 检查挂载选项：mount | grep $(df . | tail -1 | awk '{print $1}')，确认没挂成 noexec 或 nosuid（虽不影响写，但有时连带限制）
