MySQL 8错误日志无法写入且文件所有者异常问题求助

我之前排查过类似的MySQL日志问题，结合你给出的配置和现象，分享几个实用的排查方向：

• 检查MySQL用户的组归属
  虽然你把error.log的所有者改成了mysql:adm，但得确认mysql用户本身是否属于adm组。可以用下面的命令查看：

  id mysql
  

  如果输出里没有adm组，把mysql加入adm组再重启服务：

  usermod -aG adm mysql
  systemctl restart mysql
  

• 验证日志目录的权限
  日志文件的权限没问题，但父目录/var/log/mysql的权限也可能影响写入。执行以下命令检查目录权限：

  ls -ld /var/log/mysql
  

  确保目录的所有者是mysql:adm且权限至少为750（允许所有者读写，组读）。如果不对，调整目录权限：

  chown mysql:adm /var/log/mysql
  chmod 750 /var/log/mysql
  

• 排查安全模块限制（AppArmor/SELinux）
  很多Linux发行版的安全模块会阻止进程写入特定文件。比如Ubuntu默认用AppArmor，你可以查看系统日志里有没有相关的拒绝记录：

  grep -i apparmor /var/log/syslog | grep mysql
  

  如果是SELinux环境，用下面的命令检查是否有访问控制拒绝：

  ausearch -m avc -ts recent | grep mysql
  

  临时关闭安全模块测试（setenforce 0 用于SELinux，systemctl stop apparmor 用于AppArmor），如果日志能正常写入了，再调整对应的安全规则。

• 确认配置是否被其他文件覆盖
  MySQL 8会加载多个配置文件，你的/etc/mysql/my.cnf设置可能被其他路径的配置（比如/etc/mysql/mysql.conf.d/mysqld.cnf）覆盖。执行以下命令查看实际生效的log_error配置：

  mysqld --help --verbose | grep -A 1 "log_error"
  

  确保输出的路径和你配置的/var/log/mysql/error.log一致。

• 手动触发错误日志测试
  登录MySQL控制台，先确认当前生效的日志路径：

  SELECT @@log_error;
  

  然后执行FLUSH ERROR LOGS;刷新日志，或者故意触发一个错误（比如查询不存在的表）：

  SELECT * FROM non_existent_table;
  

  之后查看error.log是否有更新，同时检查/var/log/syslog里有没有MySQL相关的报错信息，这能帮你定位是文件写入问题还是日志本身的配置问题。

内容的提问来源于stack exchange，提问作者MultiDev