The MySQL Server Is Currently Offline - DBCACHE Exit 11

When cPanel displays "The MySQL server is currently offline" and the logs show admin/bin/Cpanel/cpmysql/DBCACHE: exit 11, the MySQL/MariaDB service has either crashed, was killed by the OOM killer, or can't start due to a configuration or corruption issue. This guide walks through diagnosis and recovery.

01. Quick Service Check

# Check if MySQL is running
systemctl status mysql

# Try to restart
systemctl restart mysql

# If restart fails, check what systemd says
journalctl -u mysql --no-pager -n 50

The DBCACHE exit 11 message means cPanel's internal MySQL caching process received a segfault (signal 11). This is a symptom, not the root cause - it happens because the MySQL server isn't responding to cPanel's queries.

02. OOM Killer

The most common cause of sudden MySQL death is the Linux OOM (Out of Memory) killer terminating the mysqld process to free RAM:

# Check if OOM killed MySQL
grep -i "killed process" /var/log/messages | grep -i mysql
dmesg | grep -i "killed process" | tail -20

If you find OOM entries, the server doesn't have enough RAM for the current MySQL configuration plus everything else running. Solutions:

Reduce MySQL memory usage - Lower innodb_buffer_pool_size in /etc/my.cnf. On a shared hosting server with 32GB RAM, keep it at 25-40% of total RAM. Check current usage with mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Identify memory hogs - Run ps aux --sort=-%mem | head -20 to see what else is consuming RAM. PHP-FPM, Apache, and LiteSpeed workers are common offenders.

Add swap if needed - Temporary measure: fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile

03. Checking the MySQL Error Log

# Find and read the error log
tail -200 /var/lib/mysql/*.err | less

Look for the last entries before the crash. Common patterns:

"InnoDB: Unable to lock ./ibdata1" - Another MySQL instance is already running, or a stale lock file exists. Check with ps aux | grep mysql and kill any orphaned processes.

"InnoDB: Corruption in the InnoDB tablespace" - See the InnoDB tablespace error guide for recovery steps.

"[ERROR] Can't start server: Bind on TCP/IP port: Address already in use" - MySQL is already running or the port is held by a zombie process. Kill it with fuser -k 3306/tcp then restart.

"Too many open files" - Increase the file descriptor limit. Add LimitNOFILE=65535 to the MySQL systemd service file.

04. InnoDB Recovery

If the error log shows InnoDB corruption, you may need force recovery mode to get MySQL running enough to dump data:

# Add to /etc/my.cnf under [mysqld]
innodb_force_recovery = 1

# Restart
systemctl restart mysql

# If it starts, dump everything immediately
mysqldump --all-databases --single-transaction > /root/all_databases_recovery.sql

# Remove force_recovery and restart normally
# Edit /etc/my.cnf to remove innodb_force_recovery
systemctl restart mysql

If level 1 doesn't work, increase to 2, then 3, up to 6. See our InnoDB recovery guide for details on each level.

05. Disk Space Issues

MySQL will crash or refuse to start if the disk is full:

# Check disk space
df -h

# Check inode usage
df -i

# Find large MySQL files
du -sh /var/lib/mysql/*/  | sort -rh | head -20

# Check for binary logs consuming space
ls -lh /var/lib/mysql/mysql-bin.*

If binary logs are consuming space and you're not using replication, you can purge them:

mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;"

Or disable binary logging in /etc/my.cnf by commenting out log-bin if replication isn't needed.

06. Fixing Restart Loops

If MySQL starts and immediately crashes again, cPanel's monitoring (Tailwatchd/ChkServd) may be rapidly restarting it, creating a loop:

# Temporarily disable cPanel's MySQL monitoring
whmapi1 configureservice service=mysql enabled=1 monitored=0

# Fix the underlying issue without interference
# ...

# Re-enable monitoring when stable
whmapi1 configureservice service=mysql enabled=1 monitored=1

Quick Recap: MySQL Server Offline

1. Try restarting - systemctl restart mysql fixes most transient issues
2. Check OOM killer - grep "killed process" /var/log/messages
3. Read the error log - tail -200 /var/lib/mysql/*.err
4. Check disk space - df -h to make sure the disk isn't full
5. Force recovery if needed - Set innodb_force_recovery=1 and dump data immediately

Last updated March 2026 · Browse all Server Maintenance articles