Introduction

Job for mysqld.service failed is only a systemd summary, not the actual diagnosis. It means MySQL failed to start, but the real cause is usually in the service logs, MySQL error log, or a recent configuration or filesystem change.

Start With the Real Error

The first commands should be:

sudo systemctl status mysqld.service
sudo journalctl -u mysqld.service -n 200 --no-pager

On some distributions the service name may be mysql.service instead of mysqld.service, so adjust accordingly.

These commands usually reveal the real problem class, such as:

• invalid configuration
• missing or inaccessible data directory
• port conflict on 3306
• permission problems
• disk-full conditions
• InnoDB recovery failure
• SELinux denials

Do not keep restarting blindly. Repeated restart attempts often bury the first useful error under later noise.

Validate the Configuration

If the problem started after editing my.cnf or a file in an included config directory, validate the configuration before trying again.

sudo mysqld --validate-config

This can catch:

• unknown options after an upgrade
• typos in config keys
• duplicate settings across included fragments
• invalid file paths for the socket, log, or data directory

If the failure clearly began after a config edit, rolling back to the last known-good version is often faster than guessing which line is wrong.

Check Ownership and Permissions

MySQL must be able to access its data directory, socket directory, and any configured log paths as the service user.

Example checks:

sudo ls -ld /var/lib/mysql
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysql

If the data directory was moved, restored from backup, or copied manually, ownership is a common reason startup fails.

Also check parent directories. The datadir itself can look correct while one parent directory still blocks traversal.

SELinux Can Block Startup Even When Permissions Look Fine

On Red Hat family systems, Unix permissions are not the whole story. If the files were moved or restored, SELinux labels may be wrong even though ownership appears correct.

A common repair step is:

sudo restorecon -Rv /var/lib/mysql

If MySQL still refuses to start after file ownership fixes, look for SELinux messages before assuming the database itself is corrupt.

Check Port and Disk State

A correct config can still fail if the host cannot support the process.

Check disk space and inode exhaustion:

df -h
df -i

Check whether another process is already using the MySQL port:

sudo ss -lntp | grep 3306

A second MySQL instance, an orphaned process, or another service on the same port can all cause a startup failure that looks mysterious at first.

Corruption Is a Different Type of Problem

If the logs mention InnoDB corruption, failed crash recovery, or damaged redo files, stop treating the issue as a normal service startup bug.

At that point the safer workflow is:

1. preserve the current data directory
2. save the logs
3. try the least destructive recovery steps first
4. export recoverable data if possible
5. restore from backups if needed

When the real issue is data damage, random “try things and restart again” behavior can make recovery harder.

Verify With a Real Query

After fixing a concrete issue, restart once and then verify more than just the service status:

sudo systemctl restart mysqld.service
sudo systemctl status mysqld.service
mysql -uroot -p -e "SELECT VERSION();"

A green systemd state is useful, but an actual SQL query confirms the server is accepting connections and functioning normally.

Common Pitfalls

The biggest mistake is treating the systemctl summary line as the diagnosis instead of reading the logs that explain the failure.

Another issue is restarting repeatedly before saving the first useful error output.

People also often fix Unix ownership and forget SELinux labels, especially on Red Hat-like systems.

Finally, do not stop at “service is active.” Always verify with a real client connection after the restart.

Summary

• 'Job for mysqld.service failed is a symptom, not the root cause.'
• Start with systemctl status and journalctl, not repeated restarts.
• Validate configuration if the issue followed a config change.
• Check ownership, SELinux labels, port conflicts, and disk state.
• After fixing something concrete, verify recovery with an actual SQL query.