DirectAdmin MySQL/MariaDB Not Starting After Reboot? Complete Fix Guide (2026)

You reboot your DirectAdmin server for a routine kernel update and come back to find MySQL (or MariaDB) hasn't come back up. Every website on the server returns a database connection error. This is one of the most critical failures a hosting sysadmin can face — and it's more fixable than it looks if you work through the causes methodically.

This guide covers every reason MySQL/MariaDB fails to start on a DirectAdmin server, with exact commands to diagnose and fix each one.

Step 1: Check the MySQL Service Status and Error Logs

Before attempting any fixes, you need to know exactly why MySQL failed to start. The error logs will tell you.

1. Check service status:

# For systemd-based systems (CentOS 7+, AlmaLinux, Ubuntu):
systemctl status mysqld
systemctl status mariadb

# For older init systems:
service mysqld status

2. Check MySQL error log — this is the most important diagnostic step:

# Default MariaDB log:
tail -100 /var/lib/mysql/$(hostname).err

# Alternative locations:
tail -100 /var/log/mysqld.log
tail -100 /var/log/mysql/error.log

# Search for the actual error:
grep -E "ERROR|FATAL|Aborting" /var/lib/mysql/*.err | tail -30

3. Check system journal (systemd servers):

journalctl -u mysqld -n 100 --no-pager
journalctl -u mariadb -n 100 --no-pager

Key error patterns to look for:

• InnoDB: Corruption in the InnoDB tablespace — corrupted InnoDB data
• Can't start server: Bind on TCP/IP port — port 3306 already in use
• Fatal error: Can't open and lock privilege tables — permissions issue
• Table 'mysql.user' doesn't exist — MySQL system tables missing
• InnoDB: redo log file ./ib_logfile0 — InnoDB log file mismatch

Step 2: Fix Stale Lock Files and Stuck Processes

A previous unclean shutdown can leave lock files and zombie mysqld processes that prevent MySQL from starting again.

1. Kill any stuck mysqld processes:

ps aux | grep mysqld
killall -9 mysqld
# Verify all are gone:
ps aux | grep mysqld

2. Remove stale lock and PID files:

# Remove lock file:
rm -f /var/lock/subsys/mysql
rm -f /var/lock/subsys/mysqld

# Remove PID file (path varies by system):
rm -f /var/run/mysqld/mysqld.pid
rm -f /tmp/mysql.sock

3. Try starting MySQL:

service mysqld start
# or:
systemctl start mysqld

If this works, your server was shutting down uncleanly — consider enabling innodb_fast_shutdown=0 for safer shutdowns.

Step 3: Fix InnoDB Log File Mismatch

This is one of the most common causes of MySQL not starting after a version upgrade or configuration change on DirectAdmin. If the InnoDB log file size in my.cnf doesn't match the actual ib_logfile0 on disk, MySQL refuses to start.

Error in log: InnoDB: Error: log file ./ib_logfile0 is of different size

1. Stop MySQL completely:

service mysqld stop
killall -9 mysqld

2. Back up and remove the old InnoDB log files:

cd /var/lib/mysql/
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

3. Start MySQL — it will recreate the log files at the correct size:

service mysqld start

4. Verify MySQL started successfully:

mysql -u root -p -e "SHOW STATUS LIKE 'uptime';"

5. Once confirmed working, delete the old backups:

rm /var/lib/mysql/ib_logfile0.bak /var/lib/mysql/ib_logfile1.bak

Step 4: Fix InnoDB Corruption

If the error log shows InnoDB corruption, you need to recover the data before MySQL can start normally.

Error pattern: InnoDB: Database page corruption or InnoDB: Tablespace is corrupted

1. Enable InnoDB recovery mode by editing /etc/my.cnf (or /etc/mysql/my.cnf):

[mysqld]
innodb_force_recovery = 1

Start with level 1. If MySQL still won't start, increment up to 6 (each level bypasses more recovery checks but risks more data loss).

2. Start MySQL with recovery mode enabled:

service mysqld start

3. Once started, dump all databases immediately:

mysqldump --all-databases --single-transaction > /backup/emergency_full_dump_$(date +%Y%m%d).sql

4. Stop MySQL, remove the corrupted InnoDB files, and reimport:

service mysqld stop
# Remove the innodb_force_recovery line from /etc/my.cnf
# Then start fresh:
service mysqld start
mysql -u root < /backup/emergency_full_dump_$(date +%Y%m%d).sql

Step 5: Fix Port 3306 Already in Use

Error pattern: Can't start server: Bind on TCP/IP port: Address already in use

1. Find what's using port 3306:

lsof -i :3306
netstat -tlnp | grep 3306

2. If it's a zombie mysqld process:

kill -9 $(lsof -t -i:3306)
service mysqld start

3. If another process is legitimately using the port: identify it and either stop it or configure MySQL to use a different port in /etc/my.cnf:

[mysqld]
port = 3307

Step 6: Fix File Permissions on MySQL Data Directory

Error pattern: Fatal error: Can't open and lock privilege tables or Can't create/write to file

1. Check ownership of the MySQL data directory:

ls -la /var/lib/mysql/

All files should be owned by mysql:mysql.

2. Fix ownership if incorrect:

chown -R mysql:mysql /var/lib/mysql/
chmod 750 /var/lib/mysql/

3. Fix the MySQL run directory:

mkdir -p /var/run/mysqld/
chown mysql:mysql /var/run/mysqld/
chmod 755 /var/run/mysqld/

4. If SELinux is enforcing (common on AlmaLinux/CentOS), check for denials:

ausearch -m avc -ts recent | grep mysql
# If found, restore SELinux context:
restorecon -Rv /var/lib/mysql/

Step 7: Fix MySQL Not Auto-Starting After Reboot on DirectAdmin

Even if MySQL starts manually, it may not start automatically on reboot if the systemd service isn't enabled.

1. Enable MySQL to start on boot:

systemctl enable mysqld
# or for MariaDB:
systemctl enable mariadb

2. Verify it's enabled:

systemctl is-enabled mysqld

3. Ensure DirectAdmin's service monitor will restart MySQL if it crashes: In DirectAdmin, go to Admin Level > Service Monitor and verify MySQL is listed and "On" is selected.

4. Run DirectAdmin's MySQL startup script if MySQL was installed via DirectAdmin's CustomBuild:

service mysqld start
# or the DA-specific script:
/usr/local/directadmin/scripts/mysqld start

Run Database Integrity Check After Recovery

Once MySQL is running again, check all databases for corruption before letting sites go live.

# Check and repair all tables:
mysqlcheck --all-databases --auto-repair -u root -p

# Check DirectAdmin's internal databases:
mysqlcheck --databases da_roundcube roundcube -u root -p

# Verify all databases are accessible:
mysql -u root -p -e "SHOW DATABASES;"
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables;"

After MySQL is stable, check the sites that were down by refreshing them. If any show database errors, the database user permissions may need to be re-linked to cPanel accounts — run /usr/local/directadmin/scripts/fix_da_db.sh if available, or remap users manually in DirectAdmin's database manager.

Keeping MySQL reliably available on a DirectAdmin server requires proactive monitoring, not just reactive fixes. If you're managing multiple DirectAdmin servers and want to eliminate surprise downtime, CloudHouse's managed server management service includes 24/7 MySQL monitoring, automatic service restart on failure, and root-cause analysis for every outage.

FAQs