Bug #42186 Mysql don't start after power off (mysqld got signal 11)
Submitted: 18 Jan 2009 10:16 Modified: 26 Jun 2009 9:11
Reporter: Ruslan Mansurov Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious)
Version:5.0.51a OS:Linux (Kubuntu 8.04)
Assigned to: CPU Architecture:Any
Tags: crash recovery, mysqld got signal 11

[18 Jan 2009 10:16] Ruslan Mansurov
Description:
After the power off (pressing button reset) mysql couldn't start. Our OS is Kubuntu 8.04

Here is content of syslog:

Jan 18 12:12:44 server mysqld[16467]: InnoDB: Log scan progressed past the check
point lsn 0 3207474084
Jan 18 12:12:44 server mysqld[16467]: 090118 12:12:44  InnoDB: Database was not
shut down normally!
Jan 18 12:12:44 server mysqld[16467]: InnoDB: Starting crash recovery.
Jan 18 12:12:44 server mysqld[16467]: InnoDB: Reading tablespace information fro
m the .ibd files...
Jan 18 12:12:44 server mysqld[16467]: InnoDB: Restoring possible half-written da
ta pages from the doublewrite
Jan 18 12:12:44 server mysqld[16467]: InnoDB: buffer...
Jan 18 12:12:45 server mysqld[16467]: InnoDB: Doing recovery: scanned up to log
sequence number 0 3207484055
Jan 18 12:12:45 server mysqld[16467]: 090118 12:12:45  InnoDB: Starting an apply
 batch of log records to the database...
Jan 18 12:12:45 server mysqld[16467]: InnoDB: Progress in percents: 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 8
0 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 090118 12:12:45 - mys
qld got signal 11;
Jan 18 12:12:45 server mysqld[16467]: This could be because you hit a bug. It is
 also possible that this binary
Jan 18 12:12:45 server mysqld[16467]: or one of the libraries it was linked agai
nst is corrupt, improperly built,
Jan 18 12:12:45 server mysqld[16467]: or misconfigured. This error can also be c
aused by malfunctioning hardware.
Jan 18 12:12:45 server mysqld[16467]: We will try our best to scrape up some inf
o that will hopefully help diagnose
Jan 18 12:12:45 server mysqld[16467]: the problem, but since we have already cra
shed, something is definitely wrong
Jan 18 12:12:45 server mysqld[16467]: and this may fail.
Jan 18 12:12:45 server mysqld[16467]:
Jan 18 12:12:45 server mysqld[16467]: key_buffer_size=0
Jan 18 12:12:45 server mysqld[16467]: read_buffer_size=131072
Jan 18 12:12:45 server mysqld[16467]: max_used_connections=0
Jan 18 12:12:45 server mysqld[16467]: max_connections=100
Jan 18 12:12:45 server mysqld[16467]: threads_connected=0
Jan 18 12:12:45 server mysqld[16467]: It is possible that mysqld could use up to

Jan 18 12:12:45 server mysqld[16467]: key_buffer_size + (read_buffer_size + sort
_buffer_size)*max_connections = 217599 K
Jan 18 12:12:45 server mysqld[16467]: bytes of memory
Jan 18 12:12:45 server mysqld[16467]: Hope that's ok; if not, decrease some vari
ables in the equation.
Jan 18 12:12:45 server mysqld[16467]:
Jan 18 12:12:45 server mysqld[16467]: thd=(nil)
Jan 18 12:12:45 server mysqld[16467]: Attempting backtrace. You can use the foll
owing information to find out
Jan 18 12:12:45 server mysqld[16467]: where mysqld died. If you see no messages
after this, something went
Jan 18 12:12:45 server mysqld[16467]: terribly wrong...
Jan 18 12:12:45 server mysqld[16467]: Cannot determine thread, fp=0xb51a9338, ba
cktrace may not be correct.
Jan 18 12:12:45 server mysqld[16467]: Stack range sanity check OK, backtrace fol
lows:
Jan 18 12:12:45 server mysqld[16467]: 0x81f22d3
Jan 18 12:12:45 server mysqld[16467]: 0x842aec6
Jan 18 12:12:45 server mysqld[16467]: 0x842bd80
Jan 18 12:12:45 server mysqld[16467]: 0x83ea55d
Jan 18 12:12:45 server mysqld[16467]: 0x83ec320
Jan 18 12:12:45 server mysqld[16467]: 0x83d7283
Jan 18 12:12:45 server mysqld[16467]: 0x8404990
Jan 18 12:12:45 server mysqld[16467]: 0x833a4a8
Jan 18 12:12:45 server mysqld[16467]: 0xb7f904fb
Jan 18 12:12:45 server mysqld[16467]: 0xb7da4e5e
Jan 18 12:12:45 server mysqld[16467]: New value of fp=(nil) failed sanity check,
 terminating stack trace!
Jan 18 12:12:45 server mysqld[16467]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack t
race. Resolved
Jan 18 12:12:45 server mysqld[16467]: stack trace is much more helpful in diagno
sing the problem, so please do
Jan 18 12:12:45 server mysqld[16467]: resolve it
Jan 18 12:12:45 server mysqld[16467]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Jan 18 12:12:45 server mysqld[16467]: information that should help you find out
what is causing the crash.
Jan 18 12:12:45 server mysqld_safe[16484]: ended

How to repeat:
I don't know how to repeat it. The problem occured first time. Earlier we had no problems after power off.
[18 Jan 2009 10:17] Ruslan Mansurov
Resolved stack trace:

root@server:~/mysql# resolve_stack_dump -s ./symbols -n ./stack
0x81f22d3 handle_segfault + 771
0x842aec6 page_cur_insert_rec_low + 1014
0x842bd80 page_cur_parse_insert_rec + 800
0x83ea55d log_fsp_current_free_limit_set_and_checkpoint + 1773
0x83ec320 recv_recover_page + 912
0x83d7283 buf_page_io_complete + 1395
0x8404990 fil_aio_wait + 480
0x833a4a8 srv_normalize_path_for_win + 136
0xb7f904fb _end + -1350384125
0xb7da4e5e _end + -1352396954

root@server:~/mysql# resolve_stack_dump -s ./symbols -n ./stack | c++filt
0x81f22d3 handle_segfault + 771
0x842aec6 page_cur_insert_rec_low + 1014
0x842bd80 page_cur_parse_insert_rec + 800
0x83ea55d log_fsp_current_free_limit_set_and_checkpoint + 1773
0x83ec320 recv_recover_page + 912
0x83d7283 buf_page_io_complete + 1395
0x8404990 fil_aio_wait + 480
0x833a4a8 srv_normalize_path_for_win + 136
0xb7f904fb _end + -1350384125
0xb7da4e5e _end + -1352396954
[18 Jan 2009 10:17] Ruslan Mansurov
Content of my.cnf file:

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

[mysqld]
innodb_force_recovery = 4

#
# * Basic Settings
#

#
# * IMPORTANT
#   If you make changes to these settings and your system uses apparmor, you may
#   also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.
#

user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address		= 127.0.0.1
#
# * Fine Tuning
#
key_buffer		= 16M
max_allowed_packet	= 16M
thread_stack		= 128K
thread_cache_size	= 8
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log		= /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log_slow_queries	= /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id		= 1
#log_bin			= /var/log/mysql/mysql-bin.log
expire_logs_days	= 10
max_binlog_size         = 100M
#binlog_do_db		= include_database_name
#binlog_ignore_db	= include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

[mysql]
#no-auto-rehash	# faster start of mysql but no tab completition

[isamchk]
key_buffer		= 16M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1

#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
[18 Jan 2009 10:18] Ruslan Mansurov
The size of /var/lib/mysql is 1333 Mb.
[18 Jan 2009 13:19] Ruslan Mansurov
After updating mysql-server to version 5.1.30 the problem still active.

I attached log-file from /var/lib/mysql/server.err
[18 Jan 2009 13:20] Ruslan Mansurov
log-file /var/lib/mysql/server.err

Attachment: server.err (text/plain), 2.68 KiB.

[18 Jan 2009 13:22] Ruslan Mansurov
New configuration file from mysql-server-5.1

Attachment: my.cnf (text/plain), 4.16 KiB.

[18 Jan 2009 13:28] Ruslan Mansurov
After updating to 5.1.30 the new messages began to appear in the syslog when trying to start mysql-server:

Jan 18 16:00:24 server kernel: [103883.831722] audit(1232283624.309:229):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28321 profile="/usr/sbin/mysqld"
Jan 18 16:00:25 server kernel: [103884.946715] audit(1232283625.309:230):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28338 profile="/usr/sbin/mysqld"
Jan 18 16:00:29 server kernel: [103888.961098] audit(1232283629.309:231):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28355 profile="/usr/sbin/mysqld"
Jan 18 16:00:29 server kernel: [103889.026880] audit(1232283629.309:232):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28376 profile="/usr/sbin/mysqld"
Jan 18 16:00:29 server kernel: [103889.377719] audit(1232283629.809:233):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28504 profile="/usr/sbin/mysqld"
Jan 18 16:00:30 server kernel: [103890.082733] audit(1232283630.309:234):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28513 profile="/usr/sbin/mysqld"
Jan 18 16:00:31 server kernel: [103891.099101] audit(1232283631.309:235):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28524 profile="/usr/sbin/mysqld"
Jan 18 16:00:32 server kernel: [103892.119812] audit(1232283632.309:236):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28534 profile="/usr/sbin/mysqld"
Jan 18 16:00:33 server kernel: [103893.141139] audit(1232283633.309:237):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28544 profile="/usr/sbin/mysqld"
Jan 18 16:00:34 server kernel: [103894.167794] audit(1232283634.309:238):  type=1503 operation="inode_permission" requested_
mask="r" denied_mask="r" name="/sys/devices/system/cpu/" pid=28554 profile="/usr/sbin/mysqld"
[19 Jan 2009 7:33] Sveta Smirnova
Thank you for the report.

Pressing power off can lead to data corruption. Did you force InnoDB Recovery as described at http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html?
[19 Jan 2009 8:01] Ruslan Mansurov
After adding line
innodb_force_recovery = 4
mysql couldn't start. It started only after we have written "6", but some of the data over the last week have been lost. And some databases and data looks normal (keeps data before crash). Databases and tables that were created during the week have been crashed.
mysqlcheck shows us:
...
wab3.seo_division                                  OK
wab3.seo_page
Error    : Table 'wab3.seo_page' doesn't exist
error    : Corrupt
wab3.seo_phrase                                    OK
...

Table seo_page is not visible in phpmyadmin.
File /var/lib/mysql/wab3/seo_page.frm exists.
[19 Jan 2009 20:23] Mikhail Izioumtchenko
Mansur, please try to keep the following information:
[I understand some of it may already be in the bug]

- error.log from BEFORE the powerdown, my.cnf, error.log after the powerdown
- the coredump produced after the SEGV, and the mysqld executable that dumped it
- the datafiles where the recovery can't be done

is the SEGV reproducible?
[20 Jan 2009 13:18] MySQL Verification Team
Changing status to need feedback for last Michael question.
[20 Jan 2009 13:44] Ruslan Mansurov
Original cnf-file from mysql-5.0.51a

Attachment: my.cnf (application/octet-stream, text), 3.67 KiB.

[20 Jan 2009 13:55] Ruslan Mansurov
"the coredump produced after the SEGV, and the mysqld executable that dumped it" - I don't understand what you mean.

"the datafiles where the recovery can't be done"
Size of ibdata1 is 772 Mb. 
ib_logfile0 and ib_logfile1 are 5 Mb each.
[20 Jan 2009 14:07] Ruslan Mansurov
The part of syslog after the powerdown

Attachment: syslog (application/octet-stream, text), 75.24 KiB.

[26 May 2009 9:11] Sveta Smirnova
Thank you for the feedback.

> "the coredump produced after the SEGV, and the mysqld executable that dumped it" - I don't
understand what you mean.

Error log which you provided in the intial description of the problem contains "mysqld got signal 11;" This means mysqld got signal segmentation fault from the OS. Short name of this signal is SEGV. If this is repeatable you can turn on generation of core files with option --core for mysqld, then generate core file. Please read your OS documentation also, because it can contain details special for your installation. After crash occurs next time upload generated core file and mysqld to our FTP server as described in "Files"section. Please use mysqld-debug executable which located in the same place as mysqld.

> "the datafiles where the recovery can't be done"
> Size of ibdata1 is 772 Mb. 
> ib_logfile0 and ib_logfile1 are 5 Mb each.

You can upload them to our FTP server as described in "Files" section.

Please also try current version 5.0.81: probably you would be able to get it working.
[26 Jun 2009 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".