Skip to main content

Mariadb 10.11.17 on ubuntu22.04 and cpanel failing with - Could not open required defaults file: /root/.my.cnf

stAn

Hello, last night our cpanel server had upgraded our mairadb10.11 installation and we ended up loading mariadb without our own configs (just using defaults)

The main issue is that when restarting mariadb with /scripts/restartsrv_mysql it also restores /etc/mysql/debian-start which tries to read /root/.my.cnf  BUT since it seems that mariadb runs as user "mysql", it does not have access to /root/.my.cnf and gives errors: 

May 19 09:49:31 <server-hostname> systemd[1]: Started MariaDB 10.11.17 database server.
May 19 09:49:31 <server-hostname> /etc/mysql/debian-start[<pid>]: Upgrading MariaDB tables if necessary.
May 19 09:49:31 <server-hostname> /etc/mysql/debian-start[<pid>]: Could not open required defaults file: /root/.my.cnf
May 19 09:49:31 <server-hostname> /etc/mysql/debian-start[<pid>]: Fatal error in defaults handling. Program aborted
May 19 09:49:31 <server-hostname> debian-start[<pid>]: Could not open required defaults file: /root/.my.cnf
May 19 09:49:31 <server-hostname> debian-start[<pid>]: Fatal error in defaults handling. Program aborted

The mariadb server is started, but with default configuration (using innodb buffer pool size of default 128Mb instead of configured 24G and disables replication by default... )

We use root socket auth with mariadb - and thus we do not need root password in /root/.my.cnf , however it is being used by WHM phpmyadmin

 

Please suggest a fix: 

- so that restarting mariadb via /scripts/restartsrv_mysql can work with /root/.my.cnf ensuring root execution while mariadb would NOT load the "defaults" but our own config

- currently restarting mariadb with "service mariadb restart" does work OK - but i guess upon next upgrade we will end up with the same issue

 

It seems that mariadb provided "/etc/mysql/debian-start" differs exactly in the paths for it's defaults and it is quite possible that debian-start does not really need root's password in .my.cnf while root socket auth is possibly default on mariadb 10.11 

 

Cpanel: 134.0 (build 28)

Ubuntu: Ubuntu 22.04.4 LTS

Mariadb: 10.11.17

Kernel: 6.8.0-111-generic #111~22.04.1

 

Thank you for any information in this matter, the issue above had happened to use serveral times in last 2 years (i.e mariadb not loading our config )

 

Best regards, Stan

 

 

 

Comments

5 comments

Date Votes
  • cPRex Jurassic Moderator

    Hey there!  I don't have any official recommendations on my end for this issue as I'm not seeing that specific error on my end in a previous tickets.

    Would you be able to create a ticket for this issue so this can be examined directly on your machine?

    0
  • Ioannis Liatis

    Hello, 
    I am having the same issue, Today after upcp mariadb service went down.
    I have opened a cPanel Support Ticket 96014431

    Thank you,

    0
  • cPRex Jurassic Moderator

    Ioannis Liatis - your server seems to be experiencing an issue with the disk as there are multiple failures happening on the machine that aren't specific to the MySQL service.

    0
  • Ioannis Liatis

    Hello,
    There is no issue with disk.
    this is my answer to ticket.

    Thank you for getting MariaDB running again — removing the stale /var/lib/mysql/mysql.sock symlink was exactly the right action for the immediate symptom. However, I'd like to respectfully challenge the conclusion that this points to a failing disk, because the evidence on the server doesn't support that diagnosis, and I want to make sure we address the actual root cause so this doesn't keep recurring.

    Disk diagnostics — all clean

    I ran a full disk and filesystem health check after your intervention:

    • dmesg -T | grep -iE "i/o error|ata|sata|nvme|sd[a-z]|ext4-fs error|journal|read error|bad block" — zero hits across the entire kernel ring buffer
    • smartctl -H /dev/sda → SMART Health Status: OK
    • df -h → /dev/sda2 (which holds /var/lib/mysql) at 13% used, 83 GB free
    • md5sum /var/lib/mysql/ibdata1 → completed without any read errors
    • InnoDB log files intact and the correct configured size (512 MB); buffer pool dumps and reloads cleanly on every restart attempt
    • No ext4-fs error, no journal aborted, no reallocated/pending sectors, no I/O retries

    A failing disk produces a very specific kernel-level signature, and none of it is present.

    The actual root cause based on your own stat output

    Your stat output showed:

    File: /var/lib/mysql/mysql.sock -> ../../../var/run/mysqld/mysqld.sock
Birth: 2026-05-28 07:45:19

    That symlink was created at 07:45:19 today, which aligns with the MariaDB 11.4.11 → 11.4.12 package upgrade that ran in this morning's upcp cron. The chronological pattern across the last 10 days is identical and lines up perfectly with each package upgrade:

    • 2026-05-19 04:23 — MariaDB upgrade 10.11.16 → 11.4.10 — same socket-bind failure
    • 2026-05-19 (later) — MariaDB upgrade 11.4.10 → 11.4.11 — same failure
    • 2026-05-28 — MariaDB upgrade 11.4.11 → 11.4.12 — same failure

    Each upgrade triggers a dpkg postinst restart, which races with a stale socket/symlink leftover at /var/lib/mysql/mysql.sock. Because the symlink's target (/var/run/mysqld/mysqld.sock) lives on tmpfs and the link itself persists across the restart, mariadbd finds the path occupied and aborts with "Address already in use." This is a well-documented dpkg/systemd race specific to Debian-family MariaDB packaging on hosts that use a symlinked socket path (which cPanel does by convention). It has nothing to do with the underlying storage.

    I appreciate you taking the time to investigate. I just want to make sure we're not chasing a hardware issue that the diagnostic data doesn't support. If you have any evidence to the contrary (specific dmesg lines, SMART attributes, syslog entries) I'd be very glad to see it — but otherwise I'm confident this is a software-level race condition that the drop-in resolves.

    Thank you

     

    0
  • cPRex Jurassic Moderator

    Thanks for that - we'll follow up in the ticket soon!

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post