How to Troubleshoot MariaDB Not Starting

When your mariadb not starting, the fastest diagnosis is the log. journalctl -u mariadb -n 100 --no-pager almost always contains the exact reason — a config typo, a port already in use, an OOM kill, a stale PID file, or a corrupt InnoDB. This guide walks through the six things worth checking before reaching for a reinstall.

Contents

TL;DR — the triage sequence
1. Read the service log
2. Check the MariaDB log file
3. Validate the config
4. Check for port conflicts
5. Check disk space
6. Clear stale PID and socket files
Last resort — restore from backup
Frequently asked questions
Related guides
References

Last verified: 2026-04-23 on Ubuntu 22.04 with MariaDB 10.11 and AlmaLinux 9 with MariaDB 10.5. Originally published 2022-12-31, rewritten and updated 2026-04-23.

TL;DR — the triage sequence

Read the log: journalctl -u mariadb -n 100 --no-pager.
Check the MariaDB log file: sudo tail -n 100 /var/log/mysql/error.log (path varies — see below).
Validate config: sudo mariadbd --validate-config.
Check port 3306: sudo ss -tlnp | grep :3306.
Check disk space: df -h and df -i.
Clean stale PID/socket: sudo rm /var/run/mysqld/mysqld.pid /var/run/mysqld/mysqld.sock, then restart.

1. Read the service log

# systemd's view — includes both service-level and server-process output
journalctl -u mariadb.service -n 100 --no-pager

# Or just the service status with its last few log lines
systemctl -l status mariadb.service

Look for keywords: Failed, Error, fatal, aborting. The line above them usually names the problem. If the log says something like Binding on unix socket: /var/run/mysqld/mysqld.sock failed, that’s step 6 material. If it says Invalid or ignored variable: innodb_buffer_pool_size_max, that’s step 3. The log tells you which path to take.

2. Check the MariaDB log file

Path depends on distribution:

Ubuntu/Debian — /var/log/mysql/error.log.
CentOS/RHEL/AlmaLinux — /var/log/mariadb/mariadb.log.
Custom — grep log_error /etc/mysql/my.cnf (or wherever your config lives) to find where it’s writing.

sudo tail -n 100 /var/log/mysql/error.log

If MariaDB started to boot and crashed mid-way, the detailed error (InnoDB corruption, invalid schema, bad character set) usually lands here.

mariadb not starting — six triage steps from logs to port conflict to stale PID

3. Validate the config

sudo mariadbd --validate-config

# Older MariaDB / MySQL:
sudo mariadbd --help --verbose 2>&1 | head -40

A syntax error in /etc/mysql/my.cnf (or /etc/my.cnf) makes the server refuse to start. --validate-config prints the offending line and exits non-zero. Recent changes are the usual culprit — did you edit the config right before it stopped working? Diff against a recent backup.

4. Check for port conflicts

# Who's listening on 3306?
sudo ss -tlnp | grep :3306
sudo lsof -iTCP:3306

If another mysqld is already there (usually an orphan from a killed previous instance), kill it and restart:

sudo kill <orphan_pid>
sudo systemctl restart mariadb

If something else is on 3306 (a second MySQL install, a proxy), either change MariaDB’s port in my.cnf or remove the competitor.

5. Check disk space

df -h    # bytes
df -i    # inodes (yes, you can run out of these separately)

A full disk is a classic cause of “won’t start” because MariaDB can’t write its InnoDB logs. Free up space in /var/log, /tmp, or wherever’s maxed out. For a persistent fix, rotate logs and move /var/lib/mysql to a larger disk.

6. Clear stale PID and socket files

sudo rm -f /var/run/mysqld/mysqld.pid /var/run/mysqld/mysqld.sock
sudo systemctl restart mariadb

After a hard kill (kill -9, power loss, OOM), the PID file from the dead process can stay behind and convince the new MariaDB that another copy is already running. Deleting both the PID and the socket file, then restarting, usually resolves the “already running” lie.

Last resort — restore from backup

If InnoDB is corrupt beyond what innodb_force_recovery can handle, the data directory itself may be broken. In that case:

Take a cold snapshot of /var/lib/mysql before trying anything else.
Restore your most recent mysqldump backup into a fresh install — see exporting and importing all MySQL databases.
If you have no backup, innodb_force_recovery=1 (up to =6) in the config can sometimes bring the server up read-only long enough to dump the data, then start clean.

This is where regular backups pay off. mysqldump --all-databases nightly (plus an offsite copy) is the difference between a 10-minute recovery and a multi-day incident.

Frequently asked questions

Where should I start when mariadb not starting?

The logs — always the logs. journalctl -u mariadb -n 100 --no-pager shows the last 100 service log lines, which usually include the exact reason startup failed (config typo, port conflict, disk full, corrupted innodb). Don’t guess; read the error first.

What’s the difference between /var/log/mariadb/mariadb.log and journalctl?

mariadb.log is MariaDB’s own log, written by the server itself. journalctl is systemd’s log, which captures both systemd’s messages about the service (started, failed, OOM-killed) and stdout/stderr from the server process. On a failed start, journalctl often has more context than the MariaDB log because the server may have crashed before writing anything to its own file.

My config file has a typo — how do I find it?

sudo mariadbd --help --verbose | head -40 (or mysqld --help --verbose). If the config has a syntax error, MariaDB prints the exact file and line number. For a more targeted check: sudo mariadbd --validate-config returns 0 on success, non-zero with an error on a broken config.

How do I check if another service is holding port 3306?

sudo ss -tlnp | grep :3306 (or sudo lsof -iTCP:3306). If another PID is listening, MariaDB can’t bind. Common culprits: an orphaned mysqld from a killed previous instance (restart the host or sudo kill the PID), or a different DB on the same port (check for a second MySQL/MariaDB package — you can only run one per port).

Is reinstalling MariaDB a last resort?

Yes. Reinstall removes the package files but leaves /var/lib/mysql — the actual data — untouched, so it’s not as dangerous as it sounds. But before reinstalling, exhaust the targeted fixes: log triage, config validation, port check, disk check, PID cleanup. If the server is corrupt enough that nothing works, restoring from a recent backup (see export/import) beats a reinstall.