When 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.
Quick answer
When MySQL or MariaDB will not start, read the error log (journalctl -u mariadb or the MySQL error log) — it names the cause. The usual ones are a full disk, wrong ownership of the data directory (it must belong to mysql), another process already using port 3306, corrupted InnoDB files, or an SELinux context problem.
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.