The Geek Diary

MySQL Fails to Start Using systemctl On systemd Linux Distributions

by

Problem

When trying to start MySQL using systemctl fails to start, for example:

# systemctl status mysqld
● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
# systemctl start mysqld
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

Solution

There can be multiple causes for this. Some (but not limited to) examples are:

  • A typo in a configuration option in the MySQL configuration file.
  • Presence of a no longer used option in the MySQL configuration file.
  • Wrong file system level permission.

To investigate what error is causing MySQL not to start, there are several sources that can be used:

1. The MySQL error log

By default this is located in /var/log/mysqld.log but may be in a different location if the log-error option is set in the MySQL configuration file. This is the best place to start, however depending on the error, the startup process may not even have gotten far enough to write to the MySQL error log.

2. Check the output of “systemctl status mysqld”

The output of “systemctl status mysqld” can also be helpful to identify the cause of the failure.

# systemctl status mysqld

3. The systemd journal

The systemd journal can help to get to the root cause of failure. You can for example browse it interactively using:

# journalctl -xe

If you need to get the journal to be uploded to get it anlyzed by vendor, you need to determine where it is located. This is system specific. For example with the default configuration, the journal on CentOS/RHEL 7 can be found in a subdirectory below /run/log/journal/, for example /run/log/journal/1ffd55f216ea46bd82d0f144065cc29b/system.journal. Another location may be /var/log/journal.

Or you can export the journal like:

# journalctl > journal.log

Once the error message has been determined, use that to investigate the root cause.

You May Also Like