Resolving MySQL Service Startup Failure on CentOS 7 Due to SELinux Permission Denial

Background

OS: CentOS 7.9 MySQL: 5.7

When attempting to start a self‑installed MySQL instance on a foreign cloud VM, service mysqld start fails with an error indicating the control process exited.

Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

Diagnosis

Checking journalctl -xe reveals warnings about being unable to create a test file in /data/var/.lower-test and an error that ./err.log cannot be opened for error logging due to permission denied.

# ll -ld /data/var
drwxr-xr-x. 5 mysql mysql 4096 Oct 9 06:14 /data/var
# ll /data/var/err.log
-rw-r-----. 1 mysql mysql 33067 Oct 9 06:14 /data/var/err.log

The MySQL configuration itself is valid; the service starts successfully when invoked directly with mysqld --defaults-file=/etc/my.cnf , indicating the problem lies in the OS security settings.

Using strace -tt -T -f -e trace=file -o service.log service mysqld start shows socket communication with /run/systemd/private and SELinux context information, confirming SELinux involvement.

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
... 
connect(3, {sa_family=AF_UNIX, sun_path="/run/systemd/private"}, 22) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
getsockopt(3, SOL_SOCKET, SO_PEERSEC, "system_u:system_r:init_t:s0-s0:c"..., [64->40]) = 0
... 
recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)

The audit log ( /var/log/audit/audit.log ) contains an AVC denial:

type=AVC msg=audit(1665296076.671:726): avc: denied { append } for pid=3616 comm="mysqld" name="err.log" dev="sdb1" ino=5505026 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:unlabeled_t:s0 tclass=file permissive=0

This indicates that the SELinux domain mysqld_t lacks the append permission on the unlabeled file err.log .

Solution

The simplest remedy in this environment is to disable SELinux, as the machine was originally initialized with SELinux turned off but the overseas cloud instance did not run the initialization script.

# getenforce
Enforcing
# grep -v '^#' /etc/selinux/config
SELINUX=enforcing
SELINUXTYPE=targeted

Edit /etc/selinux/config and set SELINUX=disabled , then reboot the server. After the reboot, mysqld starts normally.