Error plugin innodb registration as a storage engine failed

Webmasters usually face “[ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed” while migrating the website or during configuration tweaks.

An unoptimized MySQL configuration entry is the most common reason for this error.

As part of MySQL Support Services, our experts routinely resolve errors such as this. Today we will go through the top causes we have seen for this error, and how we resolve them.

Causes for ‘innodb’ registration as a storage engine failed error

It is common for webmasters or web admins to tweak the parameters of MySQL configuration file. This is primarily to improve the performance of the server.

However, performing tweaks without considering the server resources can adversely affect the server performance. It may even lead to the MySQL service failure.

For instance,innodb_log_file_size is the size of the commit log files which impact the performance of MySQL. Updating the value to a very high level that the server cannot handle leads to MySQL failure with this error.

MySQL upgrade may also trigger this error. The new version of MySQL may not support some of the parameters in the old version. For instance, innodb_log_checksum_algorithm is an experimental feature in 10.0-10.1, which was deprecated in 10.2 and removed in 10.3. Thus there is a chance for the error to be invoked during the upgrade.

A typical error message looks like

110831 21:20:00 [ERROR] Plugin ‘InnoDB’ init function returned error.
110831 21:20:00 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
110831 21:20:00 [ERROR] Unknown/unsupported storage engine: INNODB
110831 21:20:00 [ERROR] Aborting

110831 21:20:00 [Note] /usr/sbin/mysqld: Shutdown complete

How to fix the plugin ‘innodb’ registration as a storage engine failed error?

The first step to fix the error is to find the exact parameter that triggers the error. A closer look at the MySQL configuration file will provide us the details of the configuration.

For instance, one of the requests we recently handled had this line on top of the error message

150206 4:42:12 [ERROR] /usr/sbin/mysqld: unknown variable 'local-inline=0'

Obviously the parameter local-inline=0 in MySQL configuration file is triggering the error. To fix the issue, first, we opened the file using an editor

#vi /etc/my.cnf

Then we removed the conflicting entry from the configuration file. Next step is to move the redo log files ib_logfile0 and ib_logfile1 to another directory.

#cd /var/lib/mysql

#mv ib_logfile0 ib_logfile1 /tmp/

Finally, we can restart the MySQL service.

#service mysqld restart
[root@tech mysql]# service mysqld restart
Stopping mysqld:                                           [  OK  ]
Starting mysqld:                                           [  OK  ]

[Need help to Fix the ‘innodb’ registration as a storage engine failed error? We are available 24×7.]

Conclusion

In short, the error message plugin ‘innodb’ registration as a storage engine failed is caused due to incorrect entries in the MySQL configuration file. Today we discussed how our Support Engineers find the exact conflicting entry from the error logs and fix the error easily.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

It happens countless times for many reasons. You attempt to start or restart your MySQL server after a small configuration change and MySQL stubbornly refuses to start. Or, if it does start, some important functionality, such as InnoDB support, is missing.

Most Linux users will be familiar with the following pleasant response:

Problem Statement

MySQL service is stopped.

Sometimes the cause can be difficult to track down, especially if you don’t know where to look for clues.

MySQL Logging

MySQL has many types of logs… a general query log, a connection log, an error log, a binary log, a slow query log, etc. And then there are the Linux system logs.

In the case of a failed MySQL start due to a configuration error or MySQL problem, details are usually output to the error log. The default location of the error log is the data directory (usually /var/lib/mysql). The log is normally named based on the hostname of the server. For example, database.example.com.err.

If this file doesn’t seem to exist in your MySQL data directory, MySQL has probably been configured to log elsewhere. Check your my.cnf file, which is normally at /etc/my.cnf. The my.cnf file can contain a log-error option in the [mysqld] section which specifies a different location of the log. If no such option exists and you can’t find the log, try specifying a location for the log yourself, such as log-error = /var/lib/mysq/mysql_error.log

InnoDB Log Files

A common configuration change which can prevent MySQL from starting involves the InnoDB log file size. The InnoDB log file is the ‘redo’ or recovery log for the InnoDB storage engine. It contains transactions which have been committed to a MySQL table, but which have not yet been written to disk. Should MySQL crash and lose the contents of its buffer pool, the log file can be used to recover any data changes which were in the buffer pool. These recovered data changes can then be written to disk.

The my.cnf file contains a few options which affect the InnoDB log files. In this instance, the key one is innodb_log_file_size. This option sets the size of the InnoDB log file.

Frequently individuals decide to make changes to the innodb_log_file_size option. Generally, they attempt to increase the value, and restart the MySQL server. Unless the proper procedure is followed, MySQL will fail to start (or start without support for InnoDB). The individual may be confused about why MySQL suddenly decided not to start. A quick check of the MySQL error log will usually reveal the cause.

In the case of changing the innodb_log_file_size, one will often find an error similar to the following:

110509 12:04:27 InnoDB: Initializing buffer pool, size = 384.0M 110509 12:04:27 InnoDB: Completed initialization of buffer pool InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes InnoDB: than specified in the .cnf file 0 157286400 bytes! 110509 12:04:27 [ERROR] Plugin ‘InnoDB’ init function returned error. 110509 12:04:27 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed. 110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb 110509 12:04:27 [ERROR] Aborting   110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete

Or Error Message:

150206 4:42:12 [ERROR] Plugin 'InnoDB' init function returned error.
150206 4:42:12 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
150206 4:42:12 [ERROR] /usr/sbin/mysqld: unknown variable 'local-inline=0'
150206 4:42:12 [ERROR] Aborting

How to Fix MySQL Error “Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed”?

There are 3 solutions to this particular problem:

• Edite file my.cnf
• Restore the my.cnf file to its original state, with an innodb_log_file_size equal to the actual size of the existing InnoDB log files.
• Rename or move both the ./ib_logfile0 and ./ib_logfile1 files, and then start the MySQL server.

Solution 1 

We fixed this error by modifying /etc/my.cnf file and removing the statement “local-inline=0“.

Solution 2

Restore the my.cnf file to its original state, with an innodb_log_file_size equal to the actual size of the existing InnoDB log files.

Solution 3

One of the common possible causes of this error is my.cnf file has been modified and saved with incorrect structure.

1. Login to server via SSH with root access.
2. Navigate to /var/lib/mysql.
3. If you see log files like, ib_logfile0 and ib_logfile1, rename or move them to some other folder.
4. Stop and start the MySQL service.

It happens countless times for many reasons. You attempt to start or restart your “MySQL server”:http://dev.mysql.com/ after a small configuration change and MySQL stubbornly refuses to start. Or, if it does start, some important functionality, such as “InnoDB”:http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html support, is missing.

Most Linux users will be familiar with the following pleasant response:

In the case of a configuration change, MySQL clearly fails to start because of the change, but why? Some changes, such as the size of a log file, seem trivial.

Sometimes the cause can be difficult to track down, especially if you don’t know where to look for clues.

h2. MySQL Logging

MySQL has “many types of logs…”:http://dev.mysql.com/doc/refman/5.0/en/server-logs.html a general query log, a connection log, an error log, a binary log, a slow query log, etc. And then there are the Linux system logs.

In the case of a failed MySQL start due to a configuration error or MySQL problem, details are usually output to the “error log”:http://dev.mysql.com/doc/refman/5.0/en/error-log.html. The default location of the error log is the “data directory”:http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html (usually /var/lib/mysql). The log is normally named based on the hostname of the server. For example, database.example.com.err.

If this file doesn’t seem to exist in your MySQL data directory, MySQL has probably been configured to log elsewhere. Check your my.cnf file, which is normally at /etc/my.cnf. The my.cnf file can contain a log-error option in the [mysqld] section which specifies a different location of the log. If no such option exists and you can’t find the log, try specifying a location for the log yourself, such as log-error = /var/lib/mysq/mysql_error.log

h2. InnoDB Log Files

A common configuration change which can prevent MySQL from starting involves the InnoDB log file size. The “InnoDB log file”:http://www.pythian.com/news/1242/innodb-logfiles/ is the ‘redo’ or recovery log for the InnoDB storage engine. It contains transactions which have been committed to a MySQL table, but which have not yet been written to disk. Should MySQL crash and lose the contents of its buffer pool, the log file can be used to recover any data changes which were in the buffer pool. These recovered data changes can then be written to disk.

The my.cnf file contains a few options which affect the InnoDB log files. In this instance, the key one is innodb_log_file_size. This option sets the size of the InnoDB log file.

h2. Failed Registration of InnoDB as a Storage Engine

Frequently individuals decide to make changes to the innodb_log_file_size option. Generally, they attempt to increase the value, and restart the MySQL server. Unless the “proper procedure”:http://dev.mysql.com/doc/refman/5.0/en/innodb-data-log-reconfiguration.html is followed, MySQL will fail to start (or start without support for InnoDB). The individual may be confused about why MySQL suddenly decided not to start. A quick check of the MySQL error log will usually reveal the cause.

In the case of changing the innodb_log_file_size, one will often find an error similar to the following:

110509 12:04:27  InnoDB: Initializing buffer pool, size = 384.0M
110509 12:04:27  InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 157286400 bytes!
110509 12:04:27 [ERROR] Plugin 'InnoDB' init function returned error.
110509 12:04:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb
110509 12:04:27 [ERROR] Aborting

110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete

While the cause of MySQL’s failure to start is obvious from the log file, this is often overlooked.

There are two solutions to this particular problem:

* Restore the my.cnf file to its original state, with an innodb_log_file_size equal to the actual size of the existing InnoDB log files.

* Rename or move both the ./ib_logfile0 and ./ib_logfile1 files, and then start the MySQL server.

The ./ib_logfile0 and ./ib_logfile1 files are located in the InnoDB data directory (usually /var/lib/mysql). Both files must be moved or renamed for the above procedure to work. When starting MySQL, new InnoDB log files of the appropriate size will be created.

The original InnoDB log files only need to be kept as long as they may be needed for data recovery. If the MySQL server successfully starts after the above procedure, and all data is intact, the original InnoDB log files can be discarded.

NOTE: There are two ways to run multiple instances of a MariaDB on the same server. You can use the mariadb@.service unit file to start independent instances, or you can use the mysqld_multi sections of the /etc/my.cnf file. This document applies to the former case only.

When attempting to configure multiple MariaDB instances using the mariadb@.service unit file, the instances fail to start. The same applies when a non-default MariaDB configuration file is used. A MariaDB instance configuration file was placed in /etc/my.cnf.d/mynode1.cnf.

$ sudo systemctl start mariadb@node1.service
Job for mariadb@node1.service failed because the control process exited with error code. See "systemctl status mariadb@node1.service" and "journalctl -xe" for details.

$ sudo journalctl -xe
$ sudo systemctl status mariadb@node1.service
...
Jun 06 15:08:35 sles12sp4 mysql-systemd-helper[2363]: Could not open required defaults file: /etc/mynode1.cnf
Jun 06 15:08:35 sles12sp4 mysql-systemd-helper[2363]: Fatal error in defaults handling. Program aborted

After moving /etc/my.cnf.d/mynode1.cnf to /etc/mynode1.cnf, the error log shows:

Jun 04 14:30:44 sles12sp4 mysql-systemd-helper[1179]: 2019-06-04 14:30:44 140137018382464 [Warning] Can't create test file /var/lib/mysql/node1/databases/sles12sp4.lower-test
Jun 04 14:30:44 sles12sp4 mysql-systemd-helper[1179]: 2019-06-04 14:30:44 140137018382464 [ERROR] Aborting
Jun 04 14:30:44 sles12sp4 systemd[1]: mariadb@node1.service: Main process exited, code=exited, status=1/FAILURE
Jun 04 14:30:44 sles12sp4 systemd[1]: Failed to start MySQL server - node1 instance.

$ cat /etc/mynode1.cnf
[client]
[mysqld]
port       = 3310
datadir    = /var/lib/mysql/node1/databases
pid-file   = /var/lib/mysql/node1/databases/mysqld.pid
socket     = /run/mysql/node1mysql.sock
bind-address    = 127.0.0.1
log-error       = /var/log/mysql/node1/mysqld.log
secure_file_priv = /var/lib/mysql-files
innodb_file_format=Barracuda
innodb_file_per_table=ON
server-id    = 1
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
[mysqld_multi]
mysqld     = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
log        = /var/log/mysqld_multi.log
!includedir /etc/my.cnf.d

$ sudo ls -l /var/lib | grep mysql
drwxr-x--- 1 mysql   mysql     0 Jun  4 00:55 mysql-files
drwx------ 1 mysql   root    242 Jun  6 15:08 mysql-node1

If the default single instance of MariaDB was started first, the /var/lib/mysql directory was created with the resulting errors.

$ sudo ls -l /var/lib | grep mysql
drwxr-xr-x 1 mysql   root    346 Jun  6 15:32 mysql
drwxr-x--- 1 mysql   mysql     0 Jun  4 00:55 mysql-files
drwx------ 1 mysql   root    242 Jun  6 15:08 mysql-node1

[Warning] Can't create test file /var/lib/mysql/node1/databases/sles12sp4.lower-test
[ERROR] Aborting

If you first create /var/lib/mysql/node1/databases directory and attempt to start the instance, you get system log errors.

[ERROR] mysqld: Can't create/write to file '/var/lib/mysql/node1/databases/aria_log_control' (Errcode: 13 "Permission denied")
[ERROR] mysqld: Got error 'Can't create file' when trying to use aria control file '/var/lib/mysql/node1/databases/aria_log_control'
[ERROR] InnoDB: Operating system error number 13 in a file operation.
[ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
[ERROR] InnoDB: Cannot open datafile './ibdata1'
[ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_da
[ERROR] InnoDB: Database creation was aborted with error Cannot open a file. You may need to delete the ibdata1 file before trying to start up again.
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting

Engineering is aware of the issue and a PTF is available from support.

Configuration

MariaDB on SUSE only looks for instance configuration files in /etc, not /etc/my.cnf.d, so make sure your configuration files are saved in /etc. The resolution is based on the following configuration file examples.

Values included in /etc/mynode1.cnf

[mysqld]
port       = 3310
datadir    = /var/lib/mysql/node1/databases
pid-file   = /var/lib/mysql/node1/databases/mysqld.pid
socket     = /run/mysql/node1mysql.sock
log-error       = /var/log/mysql/node1/mysqld.log
secure_file_priv = /var/lib/mysql-files

Values included in /etc/mynode2.cnf

[mysqld]
port       = 3315
datadir    = /var/lib/mysql/node2/databases
pid-file   = /var/lib/mysql/node2/databases/mysqld.pid
socket     = /run/mysql/node2mysql.sock
log-error       = /var/log/mysql/node2/mysqld.log
secure_file_priv = /var/lib/mysql-files

Steps to Resolve

1. Install the updates when/if available in the update channel or apply the PTF received from support.

2. Stop all MariaDB instances:

$ sudo systemctl stop mariadb@node1.service
$ sudo systemctl stop mariadb@node2.service

3. Remove old datadirs:

$ sudo rm -rf /var/lib/mysql-node1 /var/lib/mysql/node1 /var/lib/mysql-node2 /var/lib/mysql/node2

4. Create the directories for the instances with the correct permissions:

$ sudo mkdir -p /var/lib/mysql/node1
$ sudo mkdir -p /var/lib/mysql/node2
$ sudo chown mysql:root /var/lib/mysql/node1
$ sudo chown mysql:root /var/lib/mysql/node2

5. Start the MariaDB instances:

$ sudo systemctl start mariadb@node1.service
$ sudo systemctl start mariadb@node2.service

6. Check the running services

$ sudo ss -nlp | grep mysql
u_str  LISTEN 0 80 /run/mysql/node2mysql.sock 150930  * 0       users:(("mysqld",pid=7356,fd=20))
u_str  LISTEN 0 80 /run/mysql/node1mysql.sock 150771  * 0       users:(("mysqld",pid=7211,fd=20))
tcp    LISTEN 0 80 127.0.0.1:3310                     0.0.0.0:* users:(("mysqld",pid=7211,fd=19))
tcp    LISTEN 0 80 127.0.0.1:3315                     0.0.0.0:* users:(("mysqld",pid=7356,fd=19))
$ sudo systemctl status mariadb@node1.service
$ sudo systemctl status mariadb@node2.service

In general, the directories in the path to datadir should have 755 root:root while the datadir itself is created as 700 mysql:root. For example,

If

datadir = /var/lib/mysql/node1/databases

then

/var/lib/mysql/node1 directories will have 755 root:root, and
/var/lib/mysql/node1/databases directory will have 700 mysql:root
 

About

MySQL process fails to start.

Looks like this:

 [root@hostname ~]# service mysqld restart
 Stopping mysqld:                                           [  OK  ]
 MySQL Daemon failed to start.
 Starting mysqld:                                           [FAILED]

Step 0 (reboot)

Restart the server:

reboot

Check after restart if mysql is working:

 service mysqld status

Step 1 (check free HDD space)

Check if there is left free space on disk.
If disk is full, remove unnecessary files and start MySQL service again.

Example which shows full (100%) /dev/md2:

[root@hostname]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md2        204G  204G   16G  100% /
tmpfs            16G     0   16G   0% /dev/shm
/dev/md1        496M   59M  412M  13% /boot

Step 2 (check log)

Check if there is any information in log file /var/log/mysqld.log

If there is no NEW information in this log file, do:

/etc/init.d/mysqld restart

and recheck. If still there is no NEW information in this log file, set such permissions with chmod:

• /var/lib/mysql — 755
• files within /var/lib/mysql — 660
• and its subdirectories — 700

Check if you set permissions correctly:

find /var/lib/mysql -printf '%m %pn'

Do again:

/etc/init.d/mysqld restart

MySQL can start. If not — check log file again, some new info should appear in it (usually error 13)

Step 3 (error 13)

If you see such error in log:

InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ib_logfile0
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

Then execute:

chown -R mysql:mysql  /var/lib/mysql

And start MySQL again:

/etc/init.d/mysqld restart

If MySQL still fails to start do:

chmod 777 /var/lib/mysql/*
/etc/init.d/mysqld restart

If MySQL still fails to start, check if there are any information in log.

Step 4 (error 13 /tmp)

If you get this error:

Can't create/write to file '/tmp/ib0iEPXa' (Errcode: 13)
InnoDB: Error: unable to create temporary file; errno: 13
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting

Do:

mkdir -p /tmp
chmod 1777 /tmp

Restart mysql, if fails — check log.

Step 5 (messed up root permissions)

ERROR 1044 (42000): Access denied for user 'root'@'localhost'

Run:

mysqld_safe --skip-grant-table

And give all privileges to the root.

Step 6 (crashing)

Log file looks like this:

/usr/libexec/mysqld() [0x787c3d]
/usr/libexec/mysqld(recv_recover_page+0x34f) [0x7896ff]
/usr/libexec/mysqld(buf_page_io_complete+0x548) [0x74aab8]
/usr/libexec/mysqld(fil_aio_wait+0xfa) [0x762c6a]
/usr/libexec/mysqld() [0x7c8ce0]
/lib64/libpthread.so.0() [0x3386807aa1]
/lib64/libc.so.6(clone+0x6d) [0x33864e8bcd]

Make DB file backups and reinstall or proceed here: https://dev.mysql.com/doc/refman/8.0/en/crashing.html

Step 7

Try to remove ib_logfile0 and ib_logfile1, (with backups):

mv -fr /var/lib/mysql/ib_logfile* /home/

And start MySQL again:

/etc/init.d/mysqld restart

If MySQL still fails to start, check if there any information in log (/var/log/mysqld.log).

Step 8

Run this command to check more information when MySQL starts:

sh -x /etc/init.d/mysqld start

Example:

[root@CentOS-69-64-minimal ~]# sh -x /etc/init.d/mysqld start
+ . /etc/rc.d/init.d/functions
++ TEXTDOMAIN=initscripts
++ umask 022
++ PATH=/sbin:/usr/sbin:/bin:/usr/bin
++ export PATH
++ '[' -z  ']'
++ COLUMNS=80
++ '[' -z  ']'
+++ /sbin/consoletype
++ CONSOLETYPE=pty
++ '[' -f /etc/sysconfig/i18n -a -z  -a -z  ']'
++ . /etc/profile.d/lang.sh
++ unset LANGSH_SOURCED
++ '[' -z  ']'
++ '[' -f /etc/sysconfig/init ']'
++ . /etc/sysconfig/init
+++ BOOTUP=color
+++ RES_COL=60
+++ MOVE_TO_COL='echo -en 33[60G'
+++ SETCOLOR_SUCCESS='echo -en 33[0;32m'
+++ SETCOLOR_FAILURE='echo -en 33[0;31m'
+++ SETCOLOR_WARNING='echo -en 33[0;33m'
+++ SETCOLOR_NORMAL='echo -en 33[0;39m'
+++ PROMPT=yes
+++ AUTOSWAP=no
+++ ACTIVE_CONSOLES='/dev/tty[1-6]'
+++ SINGLE=/sbin/sushell
++ '[' pty = serial ']'
++ __sed_discard_ignored_files='/(~|.bak|.orig|.rpmnew|.rpmorig|.rpmsave)$/d'
+++ cat /proc/cmdline
++ strstr 'ro root=/dev/md/2 rd_NO_LUKS rd_NO_DM nomodeset   consoleblank=0 crashkernel=131M@48M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de' rc.debug
++ '[' 'ro root=/dev/md/2 rd_NO_LUKS rd_NO_DM nomodeset   consoleblank=0 crashkernel=131M@48M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de' = 'ro root=/dev/md/2 rd_NO_LUKS rd_NO_DM nomodeset   consoleblank=0 crashkernel=131M@48M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de' ']'
++ return 1
+ . /etc/sysconfig/network
++ NETWORKING=yes
++ HOSTNAME=CentOS-69-64-minimal
+ exec=/usr/bin/mysqld_safe
+ prog=mysqld
+ STARTTIMEOUT=120
+ STOPTIMEOUT=60
+ MYOPTIONS=
+ '[' -e /etc/sysconfig/mysqld ']'
+ . /etc/sysconfig/mysqld
++ STARTTIMEOUT=120
++ STOPTIMEOUT=60
++ MYOPTIONS=
+ lockfile=/var/lock/subsys/mysqld
+ get_mysql_option mysqld datadir /var/lib/mysql
++ /usr/bin/my_print_defaults mysqld
++ sed -n 's/^--datadir=//p'
++ tail -n 1
+ result=/var/lib/mysql
+ '[' -z /var/lib/mysql ']'
+ datadir=/var/lib/mysql
+ get_mysql_option mysqld socket /var/lib/mysql/mysql.sock
++ /usr/bin/my_print_defaults mysqld
++ sed -n 's/^--socket=//p'
++ tail -n 1
+ result=/var/lib/mysql/mysql.sock
+ '[' -z /var/lib/mysql/mysql.sock ']'
+ socketfile=/var/lib/mysql/mysql.sock
+ get_mysql_option mysqld_safe log-error /var/log/mysqld.log
++ /usr/bin/my_print_defaults mysqld_safe
++ sed -n 's/^--log-error=//p'
++ tail -n 1
+ result=/var/log/mysqld.log
+ '[' -z /var/log/mysqld.log ']'
+ errlogfile=/var/log/mysqld.log
+ get_mysql_option mysqld_safe pid-file /var/run/mysqld/mysqld.pid
++ /usr/bin/my_print_defaults mysqld_safe
++ sed -n 's/^--pid-file=//p'
++ tail -n 1
+ result=/var/run/mysqld/mysqld.pid
+ '[' -z /var/run/mysqld/mysqld.pid ']'
+ mypidfile=/var/run/mysqld/mysqld.pid
+ case "$1" in
+ start
+ '[' -x /usr/bin/mysqld_safe ']'
++ /usr/bin/mysqladmin --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping
+ RESPONSE='/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!'
+ '[' 1 = 0 ']'
+ echo '/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!'
+ grep -q 'Access denied for user'
+ touch /var/log/mysqld.log
+ chown mysql:mysql /var/log/mysqld.log
+ chmod 0640 /var/log/mysqld.log
+ '[' -x /sbin/restorecon ']'
+ /sbin/restorecon /var/log/mysqld.log
+ '[' '!' -d /var/lib/mysql/mysql ']'
+ chown mysql:mysql /var/lib/mysql
+ chmod 0755 /var/lib/mysql
+ '['  = sos ']'
+ safe_pid=18744
+ ret=0
+ TIMEOUT=120
+ '[' 120 -gt 0 ']'
+ /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
++ /usr/bin/mysqladmin --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping
+ RESPONSE='/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!'
+ mret=1
+ '[' 1 -eq 0 ']'
+ '[' 1 -ne 1 -a 1 -ne 11 ']'
+ echo '/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!'
+ grep -q 'Access denied for user'
+ /bin/kill -0 18744
+ sleep 1
+ let TIMEOUT=120-1
+ '[' 119 -gt 0 ']'
++ /usr/bin/mysqladmin --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping
+ RESPONSE='/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!'
+ mret=1
+ '[' 1 -eq 0 ']'
+ '[' 1 -ne 1 -a 1 -ne 11 ']'
+ echo '/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!'
+ grep -q 'Access denied for user'
+ /bin/kill -0 18744
+ echo 'MySQL Daemon failed to start.'
MySQL Daemon failed to start.
+ ret=1
+ break
+ '[' 119 -eq 0 ']'
+ '[' 1 -eq 0 ']'
+ action 'Starting mysqld: ' /bin/false
+ local STRING rc
+ STRING='Starting mysqld: '
+ echo -n 'Starting mysqld:  '
Starting mysqld:  + shift
+ /bin/false
+ failure 'Starting mysqld: '
+ local rc=1
+ '[' color '!=' verbose -a -z  ']'
+ echo_failure
+ '[' color = color ']'
+ echo -en '33[60G'
                                                           + echo -n '['
[+ '[' color = color ']'
+ echo -en '33[0;31m'
+ echo -n FAILED
FAILED+ '[' color = color ']'
+ echo -en '33[0;39m'
+ echo -n ']'
]+ echo -ne 'r'
+ return 1
+ '[' -x /bin/plymouth ']'
+ /bin/plymouth --details
+ return 1
+ rc=1
+ echo
+ return 1
+ return 1
+ exit 1
[root@CentOS-69-64-minimal ~]#

See also

• https://dev.mysql.com/doc/refman/5.7/en/starting-server-troubleshooting.html
• https://dev.mysql.com/doc/refman/5.5/en/error-creating-innodb.html