I see this error:
Jun 29 06:25:11 monitor mysqld[10803]: mysqld got signal 11;
Jun 29 06:25:11 monitor mysqld[10803]: This could be because you hit a bug. It is also possible that this binary
Jun 29 06:25:11 monitor mysqld[10803]: or one of the libraries it was linked against is corrupt, improperly built,
Jun 29 06:25:11 monitor mysqld[10803]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jun 29 06:25:11 monitor mysqld[10803]: We will try our best to scrape up some info that will hopefully help diagnose
Jun 29 06:25:11 monitor mysqld[10803]: the problem, but since we have already crashed, something is definitely wrong
Jun 29 06:25:11 monitor mysqld[10803]: and this may fail.
Jun 29 06:25:11 monitor mysqld[10803]:
Jun 29 06:25:11 monitor mysqld[10803]: key_buffer_size=16777216
Jun 29 06:25:11 monitor mysqld[10803]: read_buffer_size=131072
Jun 29 06:25:11 monitor mysqld[10803]: max_used_connections=3
Jun 29 06:25:11 monitor mysqld[10803]: max_connections=100
Jun 29 06:25:11 monitor mysqld[10803]: threads_connected=2
Jun 29 06:25:11 monitor mysqld[10803]: It is possible that mysqld could use up to
Jun 29 06:25:11 monitor mysqld[10803]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
Jun 29 06:25:11 monitor mysqld[10803]: bytes of memory
Jun 29 06:25:11 monitor mysqld[10803]: Hope that's ok; if not, decrease some variables in the equation.
Jun 29 06:25:11 monitor mysqld[10803]:
Jun 29 06:25:11 monitor mysqld[10803]: thd=0xb0d00470
Jun 29 06:25:11 monitor mysqld[10803]: Attempting backtrace. You can use the following information to find out
Jun 29 06:25:11 monitor mysqld[10803]: where mysqld died. If you see no messages after this, something went
Jun 29 06:25:11 monitor mysqld[10803]: terribly wrong...
Jun 29 06:25:11 monitor mysqld[10803]: Cannot determine thread, fp=0xb3f49758, backtrace may not be correct.
Jun 29 06:25:11 monitor mysqld[10803]: Stack range sanity check OK, backtrace follows:
Jun 29 06:25:11 monitor mysqld[10803]: 0x8195adc
Jun 29 06:25:11 monitor mysqld[10803]: 0xffffe420
Jun 29 06:25:11 monitor mysqld[10803]: 0x865d684
Jun 29 06:25:11 monitor mysqld[10803]: 0x8208f0c
Jun 29 06:25:11 monitor mysqld[10803]: 0x820a0a7
Jun 29 06:25:11 monitor mysqld[10803]: 0x81a4827
Jun 29 06:25:11 monitor mysqld[10803]: 0x81afc97
Jun 29 06:25:11 monitor mysqld[10803]: 0x81b08c8
Jun 29 06:25:11 monitor mysqld[10803]: 0x81b1280
Jun 29 06:25:11 monitor mysqld[10803]: 0xb7f2aced
Jun 29 06:25:11 monitor mysqld[10803]: 0xb7d67dee
Jun 29 06:25:11 monitor mysqld[10803]: New value of fp=(nil) failed sanity check, terminating stack trace!
Jun 29 06:25:11 monitor mysqld[10803]: Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
Jun 29 06:25:11 monitor mysqld[10803]: stack trace is much more helpful in diagnosing the problem, so please do
Jun 29 06:25:11 monitor mysqld[10803]: resolve it
Jun 29 06:25:11 monitor mysqld[10803]: Trying to get some variables.
Jun 29 06:25:11 monitor mysqld[10803]: Some pointers may be invalid and cause the dump to abort...
Jun 29 06:25:11 monitor mysqld[10803]: thd->query at (nil) is invalid pointer
Jun 29 06:25:11 monitor mysqld[10803]: thd->thread_id=2933
Jun 29 06:25:11 monitor mysqld[10803]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Jun 29 06:25:11 monitor mysqld[10803]: information that should help you find out what is causing the crash.
Jun 29 06:25:11 monitor mysqld_safe[10262]: Number of processes running now: 0
Jun 29 06:25:11 monitor mysqld_safe[10264]: restarted
When this logrotate script is run:
jamesr@monitor:/etc/logrotate.d$ cat mysql-server
# - I put everything in one block and added sharedscripts, so that mysql gets
# flush-logs'd only once.
# Else the binary logs would automatically increase by n times every day.
# - The error log is obsolete, messages go to syslog now.
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
daily
rotate 7
missingok
create 640 mysql adm
compress
sharedscripts
postrotate
test -x /usr/bin/mysqladmin || exit 0
# If this fails, check debian.conf!
export HOME=/etc/mysql/my.cnf
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
# Really no mysqld or rather a missing debian-sys-maint user?
# If this occurs and is not a error please report a bug.
if ps cax | grep -q mysqld; then
exit 1
fi
else
$MYADMIN flush-logs
fi
endscript
}
The actualy error from that logrotate is:
/usr/bin/mysqladmin: refresh failed; error: 'Lost connection to MySQL server during query'
At which point mysql crashes...
iSteve asked for this:
root@monitor:/# cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw 0 0
udev /dev tmpfs rw 0 0
/dev/md1 / ext3 rw,data=ordered 0 0
/dev/md1 /dev/.static/dev ext3 rw,data=ordered 0 0
proc /proc proc rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/md0 /boot ext3 rw,data=ordered 0 0
/dev/mapper/VG1-home /home ext3 rw,data=ordered 0 0
/dev/mapper/VG1-usr /usr ext3 rw,data=ordered 0 0
/dev/mapper/VG1-var /var ext3 ro,data=ordered 0 0