MySQL Plugin Not Starting

Checked the forum for similar threads but found no definitive solution, hoping I can get some help. This is on a fresh install just done today of OMV 3.0 beta.

MySQL plugin can be turned on, but when Data Directory is set, and saved, errors happen.

datadir = /media/3ed4d2b9-03c0-4b70-b850-82df1e1757f7/SQL

I figured I'd pull out all stops and make mysql the user and group owner of the above folder with full permissions and created an internal share. Didn't change anything.

GUI Interface Error:

Zitat

Error
#0:exception 'OMV\ExecException' with message 'Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; systemctl start mysql.service 2>&1' with exit code '1': Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.' in /usr/share/php/openmediavault/system/process.inc:175

Stack trace:
#0 /usr/share/php/openmediavault/system/systemctl.inc(83): OMV\System\Process->execute(Array, 1)
#1 /usr/share/php/openmediavault/system/systemctl.inc(101): OMV\System\SystemCtl->exec('start', NULL, false)
#2 /usr/share/openmediavault/engined/module/mysql.inc(107): OMV\System\SystemCtl->enable(true)
#3 /usr/share/openmediavault/engined/rpc/config.inc(189): OMV\Engined\Module\MySql->startService()#4 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
#5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
#6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(150): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
#7 /usr/share/php/openmediavault/rpc/serviceabstract.inc(528): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatusOT...', '/tmp/bgoutput8Z...')
#8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(151): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#9 /usr/share/openmediavault/engined/rpc/config.inc(208): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)#10 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, Array)#11 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
#12 /usr/share/php/openmediavault/rpc/rpc.inc(84): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
#13 /usr/sbin/omv-engined(516): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
#14 {main}

Alles anzeigen

Output of: "systemctl status mysql.service"

Zitat

* mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: failed (Result: exit-code) since Sat 2016-12-03 13:32:53 EST; 2min 11s ago
Process: 21209 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)

Dec 03 13:32:53 OMV mysql[21209]: Starting MySQL database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
Dec 03 13:32:53 OMV systemd[1]: mysql.service: control process exited, code=exited status=1
Dec 03 13:32:53 OMV systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
Dec 03 13:32:53 OMV systemd[1]: Unit mysql.service entered failed state.

Alles anzeigen

What obvious thing am I missing here?

I always thought I should store my databases on something other than the main OMV volume, especially since I am using an SSD. Should I just leave them where they are by default on the SSD OS drive? In that case would I still need to specify an alternate location or just leave that field blank? Because I think when I left it blank, I got an error as well (a different error, but an error all the same).

It's only being used for a Kodi database, which gets its share of use, but not all day and night type of stuff.

I left that field blank, and the plugin is turne don so I figured I'd just try and restart the service via ssh.

Here's the output of "service mysql start"

Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.

Output of: "systemctl status mysql.service"

* mysql.service - LSB: Start and stop the mysql database server daemon
   Loaded: loaded (/etc/init.d/mysql)
   Active: failed (Result: exit-code) since Sat 2016-12-03 15:54:18 EST; 11s ago
  Process: 13439 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
Dec 03 15:54:18 OMV mysql[13439]: Starting MySQL database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
Dec 03 15:54:18 OMV systemd[1]: mysql.service: control process exited, code=exited status=1
Dec 03 15:54:18 OMV systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
Dec 03 15:54:18 OMV systemd[1]: Unit mysql.service entered failed state.

Next thoughts? Total uninstall and reinstall? Pretty sure the first time I turned it on, even before I moved the path, it threw an error, so something else might be up here.

Check this out from mysql error.log

161203 15:53:50 [Note] - '127.0.0.1' resolves to '127.0.0.1';
161203 15:53:50 [Note] Server socket created on IP: '127.0.0.1'.
161203 15:53:50 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
161203 15:53:50 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
161203 15:56:30 mysqld_safe Starting mysqld daemon with databases from /media/3ed4d2b9-03c0-4b70-b850-82df1e1757f7/SQL
161203 15:56:30 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
161203 15:56:30 [Note] /usr/sbin/mysqld (mysqld 5.5.53-0+deb8u1) starting as process 14916 ...
161203 15:56:30 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
161203 15:56:30 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
161203 15:56:30 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
161203 15:56:30 InnoDB: The InnoDB memory heap is disabled
161203 15:56:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins
161203 15:56:30 InnoDB: Compressed tables use zlib 1.2.8
161203 15:56:30 InnoDB: Using Linux native AIO
161203 15:56:30 InnoDB: Initializing buffer pool, size = 128.0M
161203 15:56:30 InnoDB: Completed initialization of buffer pool
161203 15:56:30 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 48941
161203 15:56:30 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.

That did the trick sir! Not sure how I screwed it up the first time but much thanks!