I am not sure if this is the right Stack Exchange to post to or not (StackOverflow figured it belonged elsewhere, so maybe it will do better here?) but I keep receiving this MySQL error when I try to install Magento2 on a VPS (Centos6, MySQL 5.7.11):

SQLSTATE[HY000]: General error: 1030 Got error 168 from storage engine

I have searched around and have found that it has to do with InnoDB not being able to write to its data files. I have also found that people who have had the same 1030 error mostly receive a -1 or 28 error and both are easily identified as 1) innodb_force_recovery set to greater than 0 (I don't have this set in my my.cnf file), and 2) not enough disk space (I have 5GB left on the drive mysql is on).

I should note that it installs anywhere from 136-162 tables fine before it stops and errors out. After that I try to add the last table it errored on manually, it then exhibits symptoms similar to this issue:

Can't create table, but table doesn't exist

The MySQL manual says:

"Check the %d value to see what the OS error means. For example, 28 indicates that you have run out of disk space."

So my question(s) are:

  1. Does anyone know what the 168 code means? -OR-
  2. Where to find the list of "%d value" errors so I can hopefully get some idea for what else to try? I have Googled %d value mysql and other versions of these search criteria and don't get back any results of value (that I can decipher anyway)

What I have tried thus far:

  1. Adding a line to my fstab to up the storage of my /temp folder to 2GB
  2. I have tried to repair tables (which actually was not a good idea, that messed up a bunch of stuff)
  3. I tried to run the mysql_upgrade (I recently updated the MySQL install so I could install Magento2 so I was hoping I forgot to do that and that might work)
  4. Various other tinkering-type things that probably broke something else I don't know about...

If anyone has any insight on where these %d descriptions are or can point me in the right direction besides what's already out there for the -1 and 28 versions of this error, I would appreciate it. I am not a Database expert at all, but I've never had so much trouble installing into a database before, usually it's pretty straight forward.


EDIT:

After reviewing the log, this is the top-most part of the error and is the table it failed on:

 2016-05-15T15:08:22.610729Z 240 [ERROR] InnoDB: Unable to lock
 ./magento_test2/authorization_rule.ibd error: 37
 2016-05-15T15:08:22.610789Z 240 [ERROR] InnoDB: Operating system error
 number 37 in a file operation. 2016-05-15T15:08:22.610840Z 240 [ERROR]
 InnoDB: Error number 37 means 'No locks available'
 2016-05-15T15:08:22.610879Z 240 [Note] InnoDB: Some operating system
 error numbers are described at
 http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html
 2016-05-15T15:08:22.610896Z 240 [ERROR] InnoDB: Cannot create file
 './magento_test2/authorization_rule.ibd' 2016-05-15T15:08:23.025333Z 0
 [ERROR] InnoDB: Unable to lock ./magento_test2/quote_address.ibd
 error: 37 2016-05-15 08:08:23 0x7f968ae75700  InnoDB: Assertion
 failure in thread 140284552238848 in file fil0fil.cc line 884 InnoDB:
 Failing assertion: success InnoDB: We intentionally generate a memory
 trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
 InnoDB: If you get repeated assertion failures or crashes, even
 InnoDB: immediately after the mysqld startup, there may be InnoDB:
 corruption in the InnoDB tablespace. Please refer to InnoDB:
 http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
 InnoDB: about forcing recovery. 15:08:23 UTC - mysqld got signal 6 ;
 This could be because you hit a bug. It is also possible that this
 binary or one of the libraries it was linked against is corrupt,
 improperly built, or misconfigured. This error can also be caused by
 malfunctioning hardware. Attempting to collect some information that
 could help diagnose the problem. As this is a crash and something is
 definitely wrong, the information collection process might fail.

I guess it's just not working very well in general.

  • What is the query/statement which ends in this error? I found one test case checking for this code - github.com/mysql/mysql-server/blob/5.7/mysql-test/suite/… and it seems to have something to do with InnoDB fulltext index helper tables and tablespaces configuration. If you can get the statement you might make a test case from it to help finding the culprit. – jkavalik May 14 '16 at 10:19
  • Thanks for your response. The query is not always the same one. Same kind, but not the same one. Some times it stops before sometimes it stops later but since it's installing Magento it fails on creating a table (CREATE TABLE IF NOT EXISTS XXX....etc) of one type or another. – Rasclatt May 14 '16 at 14:11
  • So it shows randomly? If you try to run the same statement just after receiving the error it would succeed? – jkavalik May 14 '16 at 14:14
  • No, as above in my question, when I try adding the table manually from where I left off, it then says table exists, but it actually doesn't. Then I try to drop the table and it says it doesn't exist. Sometimes the database is pretty much toast, it won't let me add anymore tables. – Rasclatt May 14 '16 at 14:16
  • I personally am hoping the 168 error code would give me more information on what it's doing but I don't know where to locate those error codes like it says on the MySQL manual site – Rasclatt May 14 '16 at 14:19
up vote 0 down vote accepted
[ERROR] InnoDB: Unable to lock ./magento_test2/authorization_rule.ibd error: 37
[ERROR] InnoDB: Error number 37 means 'No locks available'

Check your OS open file limit (for the mysql user) - ulimit -a and open files or maybe file locks for values between 256-512 (160 tables created, each having ibd/frm or frm/myi/myd for possible myisam table means a bit over 300 files) and try to make it higher.

  • Ok I took drastic measures and totally reinstalled mysql and that never fixed it, same error, so I ran this command you suggested. Those particular settings show as follows: open files (-n) 1024, file locks (-x) unlimited. – Rasclatt May 16 '16 at 6:51
  • @Rasclatt try raising it then. Is that for the MySQL user? – jkavalik May 16 '16 at 6:54
  • I'll be straight honest, 1) I don't know which to raise (do file locks not say unlimited or am I reading that wrong?) 2) I have no idea how to raise said limit (though I will google it) 3) I just ran the ulimit -a as you indicated but I don't know how to target a usergroup/user specifically and that is what displayed. Sorry, like I say I am not "trained" as a server admin, I never really expected to run into this much difficulty. It's always been straight forward. – Rasclatt May 16 '16 at 7:01
  • After Googling, I think this is correct. I haven't tried the Magento installer but I have updated my /etc/security/limits.conf file and it installed one of my bigger databases where it previously failed....but I have completely messed up my VPS by fiddling so I have to probably get my provider to reset my whole container to default so I can start over with it. Anyway I think this will be the right direction, so thanks a lot for the info! I appreciate it. – Rasclatt May 16 '16 at 8:03
  • Yeah, 1024 is unreasonably low for MySQL; this is a common problem with certain Operating Systems. – Rick James May 26 '16 at 0:04

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.