090115 14:20:53  mysqld started
nohup: ignoring input
090115 14:20:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
090115 14:20:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
/opt/mysql-5.0.67/libexec/mysqld: File '/opt/mysql-5.0.67/var/log/mysql/mysql.log' not found (Errcode: 13)
090115 14:20:53 [ERROR] Could not use /opt/mysql-5.0.67/var/log/mysql/mysql.log for logging (error 13). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
InnoDB: !!!!!!!!!!!!!! UNIV_DEBUG switched on !!!!!!!!!!!!!!!
InnoDB: !!!!!!!!!!!!!! UNIV_SYNC_DEBUG switched on !!!!!!!!!!!!!!!
InnoDB: !!!!!!!!!!!!!! UNIV_SEARCH_DEBUG switched on !!!!!!!!!!!!!!!
InnoDB: !!!!!!!!!!!!!! UNIV_MEM_DEBUG switched on !!!!!!!!!!!!!!!
InnoDB: Log scan progressed past the checkpoint lsn 3 1888274402
090115 14:20:53  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...
InnoDB: Doing recovery: scanned up to log sequence number 3 1888277687
090115 14:20:53InnoDB: Assertion failure in thread 3083273920 in file ibuf0ibuf.c line 330
InnoDB: Failing assertion: page_no < 2000
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.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
090115 14:20:53 - mysqld got signal 11 ;
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.

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

thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfcd7fa8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81aaa08
0x8318cc0
0x837af5a
0x8383f66
0x8384329
0x8378bb0
0x8319efc
0x831eeac
0x837af07
0x8383f66
0x8384329
0x8378bb0
0x8350b0d
0x83596d9
0x835ae43
0x8312338
0x83137bc
0x8301089
0x82feff2
0x828875c
0x827d4a2
0x81a9e4b
0x81ae7ea
0xb7c88450
0x8107bb1
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
090115 14:20:53  mysqld ended