A practical walkthrough for diagnosing and resolving MySQL and MariaDB startup failures on Ubuntu, covering service status checks, log analysis, permission issues, and configuration repairs.
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:
- Check for pending upgrades: Run
sudo apt update && sudo apt upgradeto make sure MySQL packages are current. Sometimes a half-applied upgrade leaves things broken. - Reinstall the package:
sudo apt install --reinstall mysql-serverreplaces binaries without touching your data files. - Run mysqlcheck: Once MySQL is up,
mysqlcheck --all-databases --repaircan 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.
Frequently asked questions
Why won't MySQL start on Ubuntu?
Most MySQL startup failures on Ubuntu come down to a full disk, wrong permissions on the data directory, corrupted InnoDB log files or a bad setting in my.cnf. A port conflict on 3306 or an AppArmor restriction can also block startup. Begin with sudo systemctl status mysql and the error log, then work through the causes in order.
Where is the MySQL error log on Ubuntu?
The MySQL error log is at /var/log/mysql/error.log, and MariaDB writes to /var/log/mariadb/error.log. Open it with sudo less /var/log/mysql/error.log and search for lines containing ERROR or FATAL, which usually point straight at the problem. For the service state, sudo systemctl status mysql (or mariadb) shows the Active line and recent error snippets.
Can a full disk stop MySQL from starting?
Yes. When the disk is full, MySQL cannot write temp files or logs and gives up. Run df -h and look at the partition holding /var/lib/mysql. If it is at 100%, clear out old logs, temp files or unused packages, and set up disk usage monitoring with alerts so it does not get there again.
How do I fix MySQL data directory permissions on Ubuntu?
Restore ownership with sudo chown -R mysql:mysql /var/lib/mysql and set the directory mode with sudo chmod 755 /var/lib/mysql. Wrong ownership typically follows a chown run on the wrong path or files restored as root, after which MySQL cannot read its own data and the service will not start.
How do I recover MySQL from corrupted InnoDB log files?
Corrupted InnoDB log files stop MySQL from finishing its recovery sequence on startup. If the error log mentions redo log issues, stop MySQL with sudo systemctl stop mysql, move /var/lib/mysql/ib_logfile0 and /var/lib/mysql/ib_logfile1 aside to .bak copies with sudo mv, and start MySQL again so it recreates them. Back up these files before removing them.
What my.cnf mistakes stop MySQL from starting?
A single typo in /etc/mysql/my.cnf can keep MySQL from starting. Common culprits are an invalid innodb_buffer_pool_size, such as a value higher than the available RAM, a wrong socket path, or a reference to a plugin that is not installed. Fix the setting, then run sudo systemctl restart mysql.
Does reinstalling mysql-server on Ubuntu delete the databases?
No. Running sudo apt install --reinstall mysql-server replaces the binaries without touching the data files. Before that, sudo apt update && sudo apt upgrade makes sure the MySQL packages are current, since a half-applied upgrade can leave things broken. Once MySQL is running again, mysqlcheck --all-databases --repair can fix damaged tables.
Can AppArmor block MySQL from starting on Ubuntu?
AppArmor on Ubuntu can silently block MySQL from accessing paths it needs. Run sudo aa-status to see what is being enforced. If MySQL is in the enforced list and the logs mention permission denials, switch its profile to complain mode for testing, which shows whether AppArmor is the culprit.
Or read how we handle it in Infrastructure Management.
Related Articles
How to Troubleshoot and Fix Cloudflare Error 521 on Ubuntu
A practical Ubuntu-focused guide to diagnosing and resolving Cloudflare Error 521, covering origin server checks, web service restarts, firewall rules, resource monitoring, and prevention strategies.
Server & DevOpsHow to Set Requests and Limits From Real Usage Instead of Guesses
Copied resource blocks cause two expensive problems at once, pods killed for memory they never used and latency nobody can explain. This shows how to read what your workloads actually consume, how CPU throttling shows up in metrics, and why a CPU limit and a memory limit are completely different decisions. The result is a set of numbers you can defend in a review instead of numbers that were inherited from a tutorial.
Server & DevOpsHow to Keep a Build Cache That Survives Ephemeral Runners
Throwing away the runner after every job is the right call, and it costs you the build cache unless the cache lives somewhere else. On GitHub Actions it already does, which means the real work is writing keys that hit instead of keys that always miss. This guide covers restore-keys and how partial matching actually resolves, the hidden part of a cache key that nobody sets, why a cache saved on a feature branch is invisible to main, and what to do when a bad cache entry starts poisoning every run.