MySQL Failed to Start: How to Diagnose and Fix It Fast

Quick Answer: When your database won't come up, don't guess and don't reinstall. Run systemctl status mysql, then read the real error log at /var/log/mysql/error.log. As of 2026, four causes explain almost every case: a full disk, wrong permissions on /var/lib/mysql, InnoDB corruption, and a broken line in my.cnf. Read the log, match the message, and you're usually back up in minutes.

Your phone buzzes. Every site on the server is throwing a database connection error at the same moment, and the terminal shows the same blunt line: MySQL failed to start. It's one of the most stomach-dropping messages a site owner or sysadmin can see, because when the database is down, everything is down.

The reassuring part is that the data is almost always fine. Your tables are sitting safely on disk. Something is simply blocking the service from booting, and once you read the right log, the cause is usually obvious.

We work through 20-30 of these server incidents a day at Hostaccent, and a database that refuses to boot is one of the classics we see. This guide is the exact process our engineers use, written so you can run it yourself, in order, without making the situation worse.

When MySQL Failed to Start, Read the Log Before Anything Else

The single biggest mistake people make is reacting before reading. They reinstall the package, delete files in the data directory, or reboot on repeat. Every one of those can turn a five-minute fix into permanent data loss. Read first.

Here is what we call the 3-Command Triage, and it answers the question almost every time:

1. sudo systemctl status mysql (or mariadb) shows whether the service failed and gives you the last few log lines.
2. sudo journalctl -xeu mysql.service shows the systemd view of the crash.
3. The real answer lives in the MySQL error log, usually /var/log/mysql/error.log on Ubuntu/Debian, /var/log/mysqld.log on RHEL/CentOS/AlmaLinux, or /var/log/mariadb/mariadb.log for MariaDB. If it isn't there, check /var/lib/mysql/<hostname>.err.

In the cases that land in our queue, the true cause is almost always in the last 20 lines of that error log, not in the systemd output. Systemd only tells you the process exited. The error log tells you why: a permission denial, an InnoDB assertion, a config parse error, or "no space left on device."

One line trips everyone up. When you see mysql.service: start request repeated too quickly or Failed with result 'exit-code', that is not the cause. It just means systemd tried five times, failed fast each time, and gave up. Scroll up (or open the error log) to find the message from the very first failed attempt. For a full walkthrough of what each field means, the MySQL official server-startup troubleshooting docs are worth a bookmark, and the journalctl man page explains the log flags.

Pro Tip: Run sudo journalctl -u mysql.service --since "10 minutes ago" to see only this incident. It cuts the noise and puts the first real error right at the bottom of your screen, where you can actually read it.

The Real Causes, Ranked by How Often They Take a Database Down

Most "MySQL won't start" incidents fall into a short list of repeat offenders. Match your log message to the table below, then jump to the matching fix section. According to Hostaccent's own support-queue data, Linux server problems like this account for roughly 25% of the tickets we handle each month, so these patterns are well worn.

| Cause | Typical log clue | How common | Fix section | |---|---|---|---| | Disk or inodes full | No space left on device, Can't create/write to file | Very common | Full Disk | | Wrong permissions/ownership | error 13, Permission denied, Operation not permitted | Very common | Permissions | | InnoDB corruption | InnoDB: ... assertion failure, Database page corruption | Common | InnoDB/Config | | Broken my.cnf line | unknown variable, error in config file | Common | InnoDB/Config | | Port/socket in use or stale | Address already in use, socket/PID errors | Occasional | InnoDB/Config | | Out of memory (OOM) | mysqld killed in dmesg, buffer pool too big | Occasional | Prevention |

A common trigger sits underneath several of these: a reboot or a package upgrade. A server gets restarted (sometimes after a billing pause), a MySQL update was left half-finished, and the service can't come up cleanly on boot. If your incident began right after apt upgrade or a hard reset, note that, because it points you straight at config, permissions, or a half-configured package.

If the database died specifically because the box ran out of memory, the pattern and the fix overlap heavily with a starved server generally. Our guide on Why Is My VPS Running Out of RAM? How to Diagnose and Fix It covers the OOM-killer side in detail, and the MariaDB Knowledge Base has engine-specific notes if you run MariaDB rather than MySQL.

Fix a Full Disk or Exhausted Inodes

A full disk is the quietest killer on this list. The database was running fine, the partition filled up, and the next time MySQL tried to write, it couldn't. Everything on the server goes down at once, which is exactly why this feels like a catastrophe when it's really a cleanup job.

Check space first. df -h shows disk usage by percentage, and df -i shows inodes (you can have free gigabytes but zero free inodes if millions of tiny files piled up). If either the data partition or /tmp reads 100%, that's your answer.

Free space from outside the data directory first. Safe wins include sudo apt clean, clearing old logs, and trimming the systemd journal with sudo journalctl --vacuum-size=200M. Old application caches and forgotten backups in your home directory are usually the fastest gigabytes to reclaim.

Pro Tip: Do not hand-delete files inside /var/lib/mysql to make room. Binary logs (mysql-bin.*) look like junk but deleting them by hand can break replication or recovery. Free space elsewhere, start MySQL, then purge binlogs the proper way with PURGE BINARY LOGS BEFORE NOW(); once you're back in.

Once you've freed a few gigabytes, start the service: sudo systemctl start mysql. If your sites host WooCommerce or WordPress, a chronically tight disk also shows up as slow pages long before it crashes the database. If you've been fighting sluggishness too, Shared Hosting Resource Limit Exceeded: Causes & Fix (2026) walks through spotting a resource ceiling before it takes you offline.

Fix Permission and Ownership Errors on the Data Directory

This is the fix that follows almost every migration, restore, or "I copied the data folder as root" moment. MySQL runs as the mysql user. If that user can't read and write its own data directory, the InnoDB engine fails to register and the whole service aborts on startup.

The tell in the error log is unmistakable: InnoDB: Operating system error number 13, Permission denied, or Operation not permitted. Error 13 literally means "access denied." Confirm the current ownership with ls -ld /var/lib/mysql. If it shows root root instead of mysql mysql, that's the bug.

The fix is one command, run carefully:

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

Then check the socket and run directories too, since these get missed: /var/run/mysqld (or /run/mysqld) must also be owned by mysql. If you recently moved the data directory to a new path, AppArmor or SELinux is the usual second culprit. On Ubuntu, the AppArmor profile at /etc/apparmor.d/usr.sbin.mysqld restricts which paths mysqld may touch; a moved data dir needs the profile updated or you'll keep getting denials even after chown.

Across the 4,000+ sites our team has migrated, a data directory that lost its correct ownership after a copy or restore is the single most common trigger we log for this error. It's boring, it's quick, and it fixes it.

Live site down and no time to experiment? Our engineers fix this exact failure for a small one-time fee, and you'll see the precise quote before we touch anything. Hosted with Hostaccent? Then a database that won't boot is simply covered by support, at no charge. Have an engineer fix it

Fix InnoDB Corruption, a Broken Config, or a Stuck Socket

If your log doesn't mention disk or permissions, the cause is usually one of these three. Work through them in order.

Recovering from InnoDB corruption

If the error log shows an InnoDB assertion failure, a page-corruption message, or a redo-log error (often after a hard power loss), the engine is refusing to start to protect your data. The recovery path is to bring it up read-only, dump everything, and rebuild.

Add this to the [mysqld] section of your config, then restart:

bashCopy
innodb_force_recovery = 1

Start MySQL. If it comes up, immediately dump your data with mysqldump --all-databases > /root/rescue.sql. If it still won't start, raise the value one step at a time (2, then 3). Stop there if you can. Values of 4, 5, and 6 can cause permanent, unrecoverable damage to your data files, so only go past 3 when you've accepted the tables may be lost. Once you have a good dump, remove the innodb_force_recovery line, restart clean, and reimport. The MySQL InnoDB forced-recovery reference documents exactly what each level disables.

A single bad line in my.cnf

One typo in a config file will stop the whole server. This is common right after someone tunes settings and restarts. The log will say something like unknown variable or error in config file. Your config usually lives at /etc/mysql/my.cnf, /etc/mysql/mysql.conf.d/mysqld.cnf, or /etc/my.cnf.

On MySQL 8, validate it without starting the server: sudo mysqld --validate-config. On MariaDB, run sudo mysqld --help --verbose 2>&1 | head to surface parse errors. The fastest real-world fix is to open the file you edited most recently and comment out (#) the last thing you added, then restart.

A stale socket, a busy port, or a half-finished upgrade

If the log says Address already in use, another process grabbed port 3306. Find it with sudo ss -tlnp | grep 3306. Sometimes it's a zombie mysqld from a crash; sudo systemctl stop mysql, then kill the stray process, then start once. A stale /var/run/mysqld/mysqld.sock or a leftover PID file can also block startup and is safe to remove while the service is stopped.

If your trouble started mid-upgrade, the package may be half-configured. Run sudo dpkg --configure -a and sudo apt --fix-broken install, which finishes the interrupted install and usually lets the service start. If a broken database then cascades into web errors, our 502 Bad Gateway Nginx: How to Fix It (Step-by-Step) guide covers the front-end symptom you'll see next.

Confirm the Fix and Stop the Next 2 a.m. Outage

Don't trust a silent prompt. Confirm the service is genuinely healthy: sudo systemctl status mysql should read active (running), and mysql -e "SELECT 1;" should return a result, not an error. Then load an actual site and click through a page that hits the database. Green across all three means you're back.

Now stop it from recurring, because most of these failures are preventable. Set a disk-space alert so you learn about a filling partition at 80%, not at 100% when it's already down. Keep real, tested, offsite backups (a backup you've never restored is a wish, not a backup). Size innodb_buffer_pool_size to leave headroom; a buffer pool set larger than available RAM invites the OOM killer to shoot MySQL on the next traffic spike. And never run a package upgrade on a production database server without a fresh snapshot first.

Do I have to babysit MySQL forever?

Honestly, no, and this is where the choice of platform matters more than any single command. On a self-managed box, disk monitoring, backups, upgrade snapshots, and 2 a.m. recovery are all your job. On a managed host, they're the provider's job. A slow database also drags your whole site down, so if you're chasing speed as well as stability, How to Fix High TTFB in WordPress (2026 Guide) pairs well with everything above.

Your Next Step: Get the Database Back and Keep It Up

If you followed the triage and your sites are loading again, well done. Take the one prevention win that fits your setup (a disk alert, a tested backup, right-sized buffers) and move on with your day.

If you'd rather never get this alert again, that's the quiet advantage of a managed host like Hostaccent: a database that won't boot becomes support's problem, not yours, backed by a 99.9% uptime guarantee and in-house engineers (not outsourced ticket-closers) who've handled these since 2012. For a server you control with root, our Managed VPS and Cloud Hosting is built for exactly this class of work. Running a single small site and want to stop touching MySQL entirely? Then managed Shared Hosting at Economy — $1.99/mo takes the database off your plate completely, with a 30-day money-back guarantee if it isn't your fit. Prefer EU data locality? Our Amsterdam VPS Hosting: High-Performance EU Servers breakdown covers that region. Still stuck right now? Open a ticket and you'll get the exact quote before any work starts.

Frequently Asked Questions About MySQL Startup Failures

Why has MySQL failed to start after a reboot?

A reboot exposes problems that were hidden while the service was already running. The three usual reasons are a disk that filled up and blocked writes, a package upgrade that was left half-configured before the restart, or permissions that got changed and only matter at boot. Read the error log first, then check df -h, run sudo dpkg --configure -a, and confirm /var/lib/mysql is owned by the mysql user.

What does "Job for mysql.service failed" actually mean?

It's systemd's generic way of saying the MySQL process exited before it finished starting. The message itself tells you nothing about the cause, which is why so many forum threads go in circles. Treat it as a signpost, not a diagnosis: run sudo journalctl -xeu mysql.service and open /var/log/mysql/error.log, then read the first real error from the earliest failed attempt, above any "repeated too quickly" lines.

Where is the MySQL error log on Ubuntu?

On Ubuntu and Debian it's usually /var/log/mysql/error.log. On RHEL, CentOS, and AlmaLinux it's typically /var/log/mysqld.log, and if you run MariaDB it may be /var/log/mariadb/mariadb.log. If none of those exist, check inside the data directory for /var/lib/mysql/<hostname>.err. You can also confirm the configured path by grepping your config for log_error in the files under /etc/mysql/.

Is it safe to use innodb_force_recovery?

Levels 1 to 3 are relatively safe and are meant for exactly this: bringing a corrupted database up long enough to dump your data. Levels 4, 5, and 6 can permanently damage your data files, so avoid them unless you've already accepted the tables might be lost. Always take a mysqldump the moment the server starts, then remove the setting and rebuild from that dump rather than leaving it in place.

Why does MariaDB fail to start on Ubuntu but MySQL commands still work?

If MariaDB failed to start yet a command like mysql still opens, you're usually connecting to nothing, or getting a socket error such as Can't connect ... through socket '/var/run/mysqld/mysqld.sock'. The client exists, but the server never came up. The fix is the same as for MySQL: read /var/log/mariadb/mariadb.log, check ownership on /var/lib/mysql, and look for an InnoDB or config error. MariaDB and MySQL share this failure pattern almost exactly.

Can a managed host stop MySQL from failing to start?

It can't make the failure modes disappear, but it moves the burden off you. On a managed platform like Hostaccent, the database sits on monitored NVMe SSD storage with disk alerts, automated backups, and engineers who catch a filling partition or a bad config before it becomes a 2 a.m. outage. On a self-managed server, all of that prevention, and the recovery when it breaks, is your responsibility, which is the real trade-off to weigh.