All of a sudden, I cant get mysql to start. Its looping with signal 11, filling up the logs with the output below. I'm running Redhat 9 & haven't changed the config in months.

Even worse I that I've found files like C:\windows\system32\shell64.dll under /var with modification dates in the last month.
Is this a mysql problem or have I been hacked?

----------
Number of processes running now: 0
050614 01:25:27 mysqld restarted
050614 1:25:28 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...
050614 1:25:28 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 43634.
InnoDB: Doing recovery: scanned up to log sequence number 0 43634
050614 1:25:28 InnoDB: Flushing modified pages from the buffer pool...
050614 1:25:28 InnoDB: Started; log sequence number 0 43634
050614 1:25:28 Found an entry in the 'db' table with empty database name; Skipped
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=5242880
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 = 427519 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Same deal here. I rebooted the Debian Woody install, then can't get back in as the boot process (as seen from Lish) hangs at

Starting MySQL database server: mysqld

Also haven't touched MySQL in a long time (or done an apt-get upgrade for that matter). Really need this fixed fast, am opening a ticket and hoping for the best. I did the last reboot only about 20 minutes earlier, no problem then. Any ideas?

Sorry, am sleep deprived and mushy brained. Obviously I can just boot in single user mode via Lish and get in to fix this myself.

Turns out the cause was 127M of MySQL logs that filled up the /var partition where is of course also were the MySQL databases reside. Minor data corruption, but could be restored. Moral of story: next time I'll partition even more aggressively. /var/log needs to be a separate partition.

Sorry for wasting your valuable time folks with this monologue.

I upgraded from Mysql 4.1beta to 4.1 production & all is fixed.