# /etc/init.d/mysql start - fails [SOLVED]

## dufeu

mysql no longer starts at boot time. When I try to start it manually, I get only this message in /var/log/messages: *Quote:*   

> mysql[1579]: ERROR: mysql failed to start

 

These are the terminal messages displayed when I try to manually start mysql using /etc/init.d/mysql: *Quote:*   

> # /etc/init.d/mysql start
> 
>  * Caching service dependencies ...                                                                                                                   [ ok ]
> 
>  * Checking mysqld configuration for mysql ...
> ...

 

According to MYSQL SERVER ERROR CODES AND MESSAGES 1550 - 1599, message 1579 is: *Quote:*   

> Error: 1579 SQLSTATE: HY000 (ER_UNSUPORTED_LOG_ENGINE)
> 
> Message: This storage engine cannot be used for log tables"

 

I'm not a mysql DB guru and I've always accepted the defaults in my Gentoo installations. I've followed the advice provided during 'emerge' upgrades and mail notices. i.e. The point is that I run a vanilla install of mysql.

As per previous notices I'm currently running 'mariadb': *Quote:*   

> # eix mariadb
> 
> [I] dev-db/mariadb
> 
>      Available versions:  (~)5.5.46^d 10.0.21(0/18)^td (~)10.0.21-r1(0/18)^td{tbz2} 10.0.22(0/18)^td (~)10.0.22-r1(0/18)^td (~)10.1.8(0/18)^td{tbz2} {bindist client-libs cluster +community cracklib debug embedded extraengine galera innodb-lz4 innodb-lzo innodb-snappy jemalloc latin1 libressl max-idx-128 minimal mroonga odbc +openssl oqgraph pam +perl profiling selinux +server sphinx ssl sst-rsync sst-xtrabackup static static-libs systemd systemtap tcmalloc test tokudb +tools xml yassl ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
> ...

 

I obviously can't run 

```
mysql_upgrade -u root -p
```

 if I can't get a running instance of 'mysqld'. For the same reason, I can't run any mysqkl admin tasks.

Some pointers would be very much appreciated.

----------

## khayyam

 *dufeu wrote:*   

> 
> 
> ```
> [Warning] No argument was provided to --log-bin and neither --log-basename or --log-bin-index where used;  This may cause repliction to break when this server acts as a master and has its hostname changed! Please use '--log-basename=pyrogyro' or '--log-bin=mysqld-bin' to avoid this problem.
> ```
> ...

 

dufeu ... given these parameters were introduced in 10.1.6 I imagine the init script and/or conf.d/mariadb currently installed isn't addapted for them ... and your mysql.cnf doesn't define them. That would be the most obvious reason ... 10.1.x all being ~arch.

See, log-bin, log-bin-basename, etc.

ps. please fix the the line breaks in the above.

HTH & best ... khay

----------

## dufeu

 *khayyam wrote:*   

> dufeu ... given these parameters were introduced in 10.1.6 I imagine the init script and/or conf.d/mariadb currently installed isn't addapted for them ... and your mysql.cnf doesn't define them. That would be the most obvious reason ... 10.1.x all being ~arch.
> 
> See, log-bin, log-bin-basename, etc.
> 
> ps. please fix the the line breaks in the above.
> ...

 

Thank you for pointers. In and of themselves, they weren't 'the answer' but they did start me thinking in other tangents rather than getting stuck on error messages and wondering what was going on. I'm not certain what the 'mariadb' package is supposed to install in terms of scripts, but the only relavent scripts in /etc/init.d/ and etc/conf.d/ are 'mysql', 'mysql-s6' and 'mysqlmanager'. There were no 'mariadb' scripts. 

I checked to see what depended directly on 'mariadb':

```
# equery d mariadb

 * These packages depend on mariadb:

virtual/libmysqlclient-18 (dev-db/mariadb:0[client-libs(+),static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])

virtual/mysql-5.6-r6 (embedded ? =dev-db/mariadb-10.1*[client-libs(+),embedded,static=])

                     (embedded ? =dev-db/mariadb-10.0*[client-libs(+),embedded,static=])

                     (!embedded ? =dev-db/mariadb-10.1*[-embedded,static=])

                     (!embedded ? =dev-db/mariadb-10.0*[-embedded,static=])
```

Since 'mariadb' is a drop in replacement for 'mysql', the 'virtual/mysql' tells us everything we need to know about 'mariadb' version requirements. Basically, I wanted to confirm if and how far downards I could push the version of 'mariadb' I had installed. The above told me version 10.0.22-r1 was acceptable so I installed this version instead and tried to start 'mysql' again.

```
# /etc/init.d/mysql start

 * Caching service dependencies ...                                                                 [ ok ]

 * Checking mysqld configuration for mysql ...                                                      [ ok ]

 * Starting mysql ...

 * start-stop-daemon: caught an interrupt

 * start-stop-daemon: /usr/sbin/mysqld died                                                         [ !! ]

 * ERROR: mysql failed to start
```

Again, the service failed to start, but the fact that this previous version of 'mariadb' had been working at one point suggested it was perhaps time to replace the existing database.

I move the existing /var/log/mysql directory to another location and ran:

```
emerge --config  =dev-db/mariadb-10.0.22-r1
```

I then tried to start the service and it stated with no failure messages.

I finally updated to 'mariadb-10.1.8' and restarted the 'mysql' service and it successfully restarted.

In theory, I understand one doesn't really want to 'blow' away one's databases and restart them from nothing. After thinking about it, in my case, my only  current uses for 'mysql' are for embedded databases as required by a few installed packages which are for their internal uses only.  As such, it dosn't hurt me to clear the DB files. They'll get rebuilt as needed anyway.

Thanks again for your reply. It really did get me out of the rut I was in and into thinking more about other approaches.

----------

