Fix MySQL / MariaDB Won't Start
Job for mariadb.service failedFailed to start MySQLcan't connect to local MySQL serverWhen MySQL/MariaDB won't start, the service status is vague but the error log is precise. Here's how to read it and fix the usual causes, including permissions and SELinux issues that get overlooked.
Read the error log first
The log says exactly why it died. Check the service status and the log:
systemctl status mariadb
journalctl -u mariadb --no-pager | tail -40
tail -50 /var/log/mysql/error.log # or /var/log/mariadb/The log line points straight at the cause — match it here, then jump to the fix:
| Log says something like… | Cause | Fix |
|---|---|---|
| "No space left" / can't write | Disk full | Free space, then restart (Cause 1) |
| "unknown variable" / bad option | A typo or bad value in my.cnf | Fix/revert the last config change (Cause 2) |
| "Address already in use" / port 3306 | Another instance already running | Stop the other process holding 3306 |
| "Permission denied" on the data dir | Wrong ownership / SELinux | chown the datadir to mysql; check SELinux |
| "Table is marked as crashed" / InnoDB | Corruption after an unclean stop | Recover with innodb_force_recovery (carefully) |
Cause 1: the disk is full
MySQL won't start if it can't write. Check space — if full, free some and try again (see no space left on device):
df -hCause 2: a bad config
A typo or bad value in my.cnf (e.g. an oversized buffer the box can't allocate) stops startup. The log names the bad directive — fix or revert your last config change.
Cause 3: port already in use
If 3306 is held by a stuck old instance, the new one can't bind. Find and stop it (see address already in use):
ss -tlnp | grep 3306Cause 4: corrupted tables / crash recovery
After an unclean shutdown, InnoDB may fail recovery. The log will mention InnoDB; in serious cases an innodb_force_recovery value in my.cnf gets it up long enough to dump data. Back up first.
Before any forced-recovery or table-repair action, copy the data directory. Recovery options can be one-way — a backup is your safety net.
The error log names the cause: disk full, bad config, port clash or InnoDB recovery. Read it before changing anything.
Cause 5: permissions or SELinux/AppArmor
If the data directory ownership changed (e.g. after a manual copy or restore), MySQL can't read its own files and refuses to start — restoring ownership to the mysql user and group on /var/lib/mysql usually clears it. On distros with SELinux/AppArmor enforced, a security policy denial can silently block startup even when file permissions look correct — check ausearch -m avc -ts recent on SELinux systems, or the audit log, for a denial around the failed start time.
Cause 6: a bad upgrade
A version upgrade that didn't run mysql_upgrade (or the MariaDB equivalent) against the existing data directory can leave the server unable to start against tables from the old version. Check the log for a version-mismatch message and run the upgrade tool if so.
How to prevent this
- Test config changes with
mysqld --validate-configbefore restarting the live service. - Take a full backup (or filesystem snapshot) before any major version upgrade.
- Monitor disk space and connection counts so you're not firefighting a full disk mid-incident — see fixing "too many connections".
Related errors
If the service starts but logins fail, see fixing MySQL "Access denied for user" (error 1045). WordPress sites affected by the same outage are covered in fixing "Error establishing a database connection".
MySQL is a trademark of Oracle Corporation. MariaDB is a trademark of MariaDB Foundation. ESAGAMES is an independent hosting provider, not affiliated with or endorsed by Oracle.
Managed databases that stay up
Our managed hosting runs and monitors MySQL/MariaDB for you, so game panels and sites keep their database.
Frequently asked questions
Why won't MariaDB/MySQL start?
Common causes are a full disk, a bad my.cnf value, port 3306 already in use, or InnoDB crash-recovery after an unclean shutdown. The error log (in /var/log/mysql or via journalctl) names the exact reason.
Where is the MySQL error log?
Usually /var/log/mysql/error.log or /var/log/mariadb/mariadb.log, and also via journalctl -u mariadb. It records precisely why startup failed.
My database crashed and won't recover — what now?
Back up the data directory first. Then read the InnoDB messages in the log; a controlled innodb_force_recovery value can bring it up long enough to dump your data. Get a backup before attempting repairs.
Can SELinux or AppArmor stop MySQL from starting even if permissions look fine?
Yes — a security policy denial can block startup silently, showing as a generic failure in systemctl status while the real reason sits in the audit log. Check ausearch -m avc -ts recent on SELinux systems.
How do I test a my.cnf change without risking downtime?
Run mysqld --validate-config (or the mariadbd equivalent) to check the config file before restarting the live service — it catches syntax and value errors without taking the database down.
Does upgrading MySQL/MariaDB ever break the start-up?
It can, if the data directory isn't upgraded to match the new version (mysql_upgrade / mariadb-upgrade). Always back up before a major version upgrade and run the upgrade tool afterward if the log mentions a version mismatch.
Related articles
Fix SSH "Connection refused" / "Connection timed out"
SSH "connection refused" vs "timed out" — what each means and the exact steps to fix them.
Read fix Linux & VPSFix "Permission denied" on Linux (chmod & chown Explained)
"Permission denied" on a script or file? Understand chmod/chown and fix it the right way.
Read fix Linux & VPSHow to Check CPU, RAM & Disk Usage on a Linux Server
The essential commands to check CPU, RAM and disk on Linux — and find what's eating them.
Read fix
