MySQL problem continues

rhythmtone · Jun 6, 2014, 3:30 PM

Ubuntu 14.04 x64 FOG 1.1.0

Using the above software versions, MySQL continues to be a problem and just fails randomly. This command doesn’t help, but it does show the problem:

sudo /etc/init.d/mysql restart

Stopping MySQL database server mysqld [ OK ]
Starting MySQL database server mysqld [fail]

When this happens the web browser interface re-directs back to the Schema Updater:
[url]http://1.1.1.1/fog/[/url] ------> re-directs to -------->
[url]http://1.1.1.1/fog/commons/schemaupdater/index.php?redir=1[/url]

In FOG version 1.1.0, when you click “Install/Upgrade Now” it says “Update/Install Failed!” and “The following errors occurred”, followed by a huge text output of error messages.

My question is: Would it be useful to post this error log to the FOG forums, or is this just something that is a broken MySQL problem?

Thanks,
D.L.

Junkhacker · Jun 6, 2014, 4:11 PM

if you get a huge text of errors from an attempted schema update, the cause is usually an incorrect mysql password in your config.php file

rhythmtone · Jun 6, 2014, 4:20 PM

Hi, thanks for the reply,
I’ve checked that and the MySQL password is correct. I know that this isn’t the problem because the FOG server works fine on boot up, but starts re-directing back to the schema update page at a random interval of time - essentially MySQL is failing after some random amount of time.

Since this command fails to restart MySQL, I know that there’s something wrong…
sudo /etc/init.d/mysql restart

Somewhere in another thread Tom mentioned that it is probably a Ubuntu problem with 14.04 but I just thought that I would ask if I should post the error log…

I’m thinking that no password on the MySQL database might fix the problem, but I really want to have a password going forward.

Thanks!
D.L.

Tom Elliott · Jun 6, 2014, 4:23 PM

I don’t think a “nopassword” setting will work.

If you want to post the mysql.log file that might help see the error, could you also get a portion of the syslog from around the time when mysql fails?

rhythmtone · Jun 6, 2014, 4:42 PM

Thanks for the reply,

Which system log should I use, and/or where would I find it?? I know that there are several in Ubuntu…

Below are the SQL logs…

From /var/log/mysql -> error.log

140606 09:35:05 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140606 9:35:38 [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.
140606 9:35:38 [Note] Plugin ‘FEDERATED’ is disabled.
140606 9:35:38 InnoDB: The InnoDB memory heap is disabled
140606 9:35:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140606 9:35:38 InnoDB: Compressed tables use zlib 1.2.8
140606 9:35:38 InnoDB: Using Linux native AIO
140606 9:35:38 InnoDB: Initializing buffer pool, size = 128.0M
140606 9:35:38 InnoDB: Completed initialization of buffer pool
140606 9:35:38 InnoDB: highest supported file format is Barracuda.
140606 9:35:39 InnoDB: Waiting for the background threads to start
140606 09:35:40 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140606 9:35:40 [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.
140606 9:35:40 [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.
140606 9:35:40 [Note] Plugin ‘FEDERATED’ is disabled.
140606 9:35:40 InnoDB: The InnoDB memory heap is disabled
140606 9:35:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140606 9:35:40 InnoDB: Compressed tables use zlib 1.2.8
140606 9:35:40 InnoDB: Using Linux native AIO
140606 9:35:40 InnoDB: Initializing buffer pool, size = 128.0M
140606 9:35:40 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140606 9:35:40 InnoDB: Retrying to lock the first data file
140606 9:35:40 InnoDB: 5.5.37 started; log sequence number 1676069
140606 9:35:40 [Note] Server hostname (bind-address): ‘127.0.0.1’; port: 3306
140606 9:35:40 [Note] - ‘127.0.0.1’ resolves to ‘127.0.0.1’;
140606 9:35:40 [Note] Server socket created on IP: ‘127.0.0.1’.
140606 9:35:41 [Note] Event Scheduler: Loaded 0 events
140606 9:35:41 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.5.37-0ubuntu0.14.04.1’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 (Ubuntu)
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140606 9:37:20 InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
140606 9:37:20 InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means ‘Resource temporarily unavailable’.
InnoDB: Some operating system error numbers are described at
InnoDB: [url]http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html[/url]
140606 9:37:20 InnoDB: Could not open or create data files.
140606 9:37:20 InnoDB: If you tried to add new data files, and it failed here,
140606 9:37:20 InnoDB: you should now edit innodb_data_file_path in my.cnf back
140606 9:37:20 InnoDB: to what it was, and remove the new ibdata files InnoDB created
140606 9:37:20 InnoDB: in this failed attempt. InnoDB only wrote those files full of
140606 9:37:20 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
140606 9:37:20 InnoDB: remove old data files which contain your precious data!
140606 9:37:20 [ERROR] Plugin ‘InnoDB’ init function returned error.
140606 9:37:20 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
140606 9:37:20 [ERROR] Unknown/unsupported storage engine: InnoDB
140606 9:37:20 [ERROR] Aborting

140606 9:37:20 [Note] /usr/sbin/mysqld: Shutdown complete

140606 09:37:20 mysqld_safe Number of processes running now: 0
140606 09:37:20 mysqld_safe mysqld restarted
140606 9:37:20 [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.
140606 9:37:20 [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.
140606 9:37:20 [Note] Plugin ‘FEDERATED’ is disabled.
140606 9:37:20 InnoDB: The InnoDB memory heap is disabled
140606 9:37:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140606 9:37:20 InnoDB: Compressed tables use zlib 1.2.8
140606 9:37:20 InnoDB: Using Linux native AIO
140606 9:37:20 InnoDB: Initializing buffer pool, size = 128.0M
140606 9:37:20 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140606 9:37:20 InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

From /var/log/upstart -> mysql.log

140606 9:35:38 [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.
/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
mysqld is alive
Checking for tables which need an upgrade, are corrupt or were
not closed cleanly.

rhythmtone · Jun 9, 2014, 3:16 PM

Hi,
Apparently a “no password” setting does fix this issue across the board, reliably, every time.

I would much rather have a password in my situation, that is my goal.

The strangest thing is how it happens randomly - my new FOG installations have been fine being up all weekend, but I’m guessing that sometime this week it will happen again…

Thanks for any help and/or advice,
D.L.

MySQL problem continues

240

12.0k

17.3k

155.2k