MariaDB slow log permissions on cPanel: the quick reference

The symptom is always the same. slow_query_log = ON in /etc/my.cnf, long_query_time set to something sane, and yet cpanel-host-slow.log is empty. The error log says exactly why, but only if you tail it at the right moment.

The symptom

tail -n 5 /var/log/mariadb/mariadb.log
# [Warning] Could not open file '/var/lib/mysql/cpanel-host-slow.log' for slow log: Permission denied

ls -l /var/lib/mysql/*-slow.log
# -rw-r----- 1 root root 0 May 10 03:14 /var/lib/mysql/cpanel-host-slow.log

The file is owned by root instead of mysql. MariaDB runs as the mysql user, so it cannot open its own slow log for writing. No crash, no chkservd alert, just silently zero rows of slow-query data when you actually need it.

The cause

cPanel's MariaDB updater (/scripts/upcp or a manual /usr/local/cpanel/scripts/check_cpanel_rpms) reinstalls the MariaDB RPMs. Reinstall sometimes touches the slow log path with the upgrade process's own UID, and the file ends up root:root. The same thing happens after a mysql_upgrade rerun.

It is not a bug we can patch. It is a side effect of how package-driven MariaDB upgrades interact with files MariaDB itself created. The fix is on us.

The one-liner fix

chown mysql:mysql /var/lib/mysql/*-slow.log && \
  chmod 660 /var/lib/mysql/*-slow.log

No restart required. MariaDB picks the file up on its next slow-log write attempt because it reopens lazily.

Verify with the next slow query (or just lower long_query_time to 0 for ten seconds, run any SELECT, and tail):

tail -F /var/lib/mysql/cpanel-host-slow.log

If lines are landing, you are done.

A weekly cron that re-asserts permissions

Because we cannot stop the MariaDB updater from running, we make the correction idempotent. Drop this in /etc/cron.weekly/mysql-slow-log-perms:

#!/bin/bash
# Re-assert slow log ownership weekly. cPanel's MariaDB updater
# resets it to root:root after package upgrades; mysql cannot write
# its own slow log when that happens.
 
set -euo pipefail
 
shopt -s nullglob
for f in /var/lib/mysql/*-slow.log; do
  chown mysql:mysql "$f"
  chmod 660 "$f"
done

chmod +x /etc/cron.weekly/mysql-slow-log-perms

Anacron runs cron.weekly jobs in the early hours, so the next upcp window almost always lands inside a day of the next permission-restore pass.

Verifying it actually runs

run-parts --test /etc/cron.weekly | grep slow-log
# /etc/cron.weekly/mysql-slow-log-perms

ls -l /var/lib/mysql/*-slow.log
# -rw-rw---- 1 mysql mysql 4096 May 10 03:14 cpanel-host-slow.log

Related reading

This permissions trap shows up in two longer postmortems where the slow log was the missing diagnostic:

• MySQL OOM on cPanel and the innodb_buffer_pool_size trap
• 86 CPU spikes in 24 hours: a multi-cause cascade postmortem

The ChkServd alert field guide covers the alert that usually arrives a few minutes after a slow log permission failure escalates into a real outage.

How ServerGuard uses this

Our MariaDB-down use case checks slow log ownership as part of the diagnostic pass and re-applies chown mysql:mysql before escalating to a human. ServerGuard catches this scenario automatically.