Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I got the problem with starting my mysql server, it was working fine until I copied the "read" mysql configuration file (/usr/local/share/mysql/my-huge.cnf) to the /etc/my.cnf, then I restarted my mysql server and unfortunatelly it stopped , instead of restarted.

I dont have any console errors, but this appear in my /var/db/mysql/ file:

120312 17:57:43 mysqld_safe mysqld from pid file /var/db/mysql/ ended
120312 17:58:09 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql
120312 17:58:09 InnoDB: The InnoDB memory heap is disabled
120312 17:58:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120312 17:58:09 InnoDB: Compressed tables use zlib 1.2.3
120312 17:58:09 InnoDB: Initializing buffer pool, size = 128.0M
120312 17:58:09 InnoDB: Completed initialization of buffer pool
120312 17:58:09 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120312 17:58:09  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
120312 17:58:09  InnoDB: Assertion failure in thread 34387018176 in file fsp0fsp.c line 2040
InnoDB: Failing assertion: inode
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to
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: about forcing recovery.
17:58:09 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.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338444 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

120312 17:58:09 mysqld_safe mysqld from pid file /var/db/mysql/ ended

Whats wrong?

share|improve this question
Are you completely sure this is about the new configuration file? What if you copy the old, working configuration file in place and restart the MySQL, does it work again? – Janne Pikkarainen Mar 12 '12 at 18:52
There was no default configuration file in /etc/... mysql was working without this file , strange. – Cyclone Mar 12 '12 at 19:03
You are talking about FreeBSD, the configuration file would most likely be under /usr/local/etc ... at least if you use Ports. – Janne Pikkarainen Mar 12 '12 at 19:04
There is no my.cnf file under /usr/local/etc/ :/ – Cyclone Mar 12 '12 at 19:20
Well, one place where FreeBSD loves to hide its my.cnf is somewhere under /var. Sorry, unable to remember without being near a FreeBSD box, but try something like find /var -iname 'my.cnf' and see if you have any luck. – Janne Pikkarainen Mar 12 '12 at 19:24
up vote 0 down vote accepted

Not sure if you've found the answer on your own yet, but in my experience my.cnf has historically lived under /var/db/mysql.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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