Why MySQL Fails to Start: A Guide to Common Errors and Solutions on Ubuntu

Diagnosing and Resolving MySQL/MariaDB Startup Issues on Ubuntu

MySQL won't start. Your app is down. Everyone's asking what happened. Sound familiar? I've dealt with this more times than I can count, and it's almost always one of a handful of causes. This post walks through the most common reasons MySQL (or MariaDB) refuses to start on Ubuntu and how to fix each one.

1. Checking MySQL/MariaDB Service Status

First things first -- check what systemd thinks is going on.

sudo systemctl status mysql

For MariaDB installations:

sudo systemctl status mariadb

The output tells you whether the process is running, dead, or stuck in a failed state. Pay attention to the "Active" line and any error snippets at the bottom.

2. Analyzing Log Files

Logs are your best friend here. MySQL and MariaDB write detailed error info that usually points straight at the problem.

The error log lives at /var/log/mysql/error.log (or /var/log/mariadb/error.log for MariaDB):

sudo less /var/log/mysql/error.log

For MariaDB:

sudo less /var/log/mariadb/error.log

Search for lines containing ERROR or FATAL -- that's where the answer usually is.

3. Common Startup Failures and Fixes

3.1 Insufficient Disk Space

This one bites people all the time. A full disk means MySQL can't write temp files or logs, and it just gives up. Check with:

df -h

Look at the partition holding /var/lib/mysql. If it's at 100%, clear out old logs, temp files, or unused packages.

3.2 Incorrect File Permissions

MySQL needs specific ownership on its data directory. If someone ran a chown on the wrong path or restored files as root, the service won't be able to read its own data.

sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 755 /var/lib/mysql

3.3 Corrupted InnoDB Log Files

InnoDB log corruption stops MySQL from finishing its recovery sequence on startup. If the error log mentions redo log issues, you can move the log files aside and let MySQL recreate them:

sudo systemctl stop mysql
sudo mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
sudo mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak
sudo systemctl start mysql

Important: Always back up these files before removing them.

3.4 Configuration Errors in my.cnf

A single typo in the config file will keep MySQL from starting. Open it up and look for anything obviously wrong:

sudo nano /etc/mysql/my.cnf

I've seen this caused by invalid innodb_buffer_pool_size values (like setting it higher than available RAM), wrong socket paths, or references to plugins that aren't installed. Fix the issue, then:

sudo systemctl restart mysql

3.5 Port Conflicts

If something else is already sitting on port 3306, MySQL can't bind to it. Quick way to check:

sudo lsof -i :3306

Kill the conflicting process or change the MySQL port in the config.

3.6 AppArmor or SELinux Restrictions

On Ubuntu, AppArmor can silently block MySQL from accessing paths it needs. Check what's being enforced:

sudo aa-status

If MySQL shows up in the enforced list and your logs mention permission denials, try switching the profile to complain mode for testing. That'll tell you if AppArmor is the culprit.

4. Recovery Steps

Still stuck? Here are some deeper recovery options:

1. Check for pending upgrades: Run sudo apt update && sudo apt upgrade to make sure MySQL packages are current. Sometimes a half-applied upgrade leaves things broken.
2. Reinstall the package: sudo apt install --reinstall mysql-server replaces binaries without touching your data files.
3. Run mysqlcheck: Once MySQL is up, mysqlcheck --all-databases --repair can fix damaged tables.

5. Preventive Measures

• Set up disk usage monitoring with alerts -- don't wait until you're at 100%
• Automate backups of both the data directory and config files
• Test config changes in staging before touching production
• Keep packages updated so you're not hit by known bugs

The bottom line: most MySQL startup failures come down to disk space, permissions, corrupted logs, or bad config. Work through them in order, check the logs at each step, and you'll usually have it sorted in minutes.