5.0.70 needs to be stabilized for security bugs. The patchset is identical to 5.0.60-r1 to speed stabilization. I have not personally tested on any big-endian machines, and it wouldn't surprise me if archive_gis fails there - it would then just need to be disabled like in previous releases. Target keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 Test instructions: USE='berkdb cluster embedded extraengine' FEATURES='test userpriv -usersandbox' emerge mysql
Created attachment 171693 [details] dev-db:mysql-5.0.70:20081114-044918.log [hppa, fail] [ebuild U ] dev-db/mysql-5.0.70 [5.0.60-r1] USE="berkdb cluster* embedded* extraengine perl ssl -big-tables -debug -latin1 -max-idx-128 -minimal (-selinux) -static" 0 kB [1] Failed 3 out of 499 tests: archive_gis, func_in and ndb_trigger.
jer: thanks. the archive_gis is the same big-endian failure as previous releases, so I've just disabled that testcase again. The other two look like your system was running short on disk space or has disk corruption, because they passed during the 'test-ns' phase, but failed in the 'test-ps' phase with errors in code that was common to both phases.
emerged and running (afaik) correctly on HPPA, as a replication slave via ssl. But I had different flags (default ones plus -berkdb): [ebuild R ] dev-db/mysql-5.0.70 USE="perl ssl -berkdb -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal (-selinux) -static" from make.conf: CFLAGS="-pipe -O2 -march=2.0" CXXFLAGS="-pipe -O1 -march=2.0" CHOST="hppa2.0-unknown-linux-gnu" FEATURES="test userpriv" all the stable ebuilds, the only exceptions being baselayout-2.0.0, openrc-0.2.5, gcc-4.2.4 and mysql-5.0.70. portage tree sync'ed some hours ago before emerging mysql. glibc currently is 2.7-r2. I'll setup a system to test with robbat2's instruction.
I have problems as well with 5.0.70, running it in an openvz container it appear other ct's on the same host have problems connecting to the mysql server. I run mysql in one ct, postfix in another, amavis_new and clamd in another and then a a few running apache on the same host. None of the services that uses mysql work at the momet as they cannot establish a connection. Not sure what's about at this stage, but I am recompiling all the ct's right now to leave out any toolchain issue or similar (needed that anyway). Will get back when I know more but it appear as if "something" isn't ok with 5.0.70 just not sure what! I can connect locally on the mysql ct using webmin and access tables, but nothing else.
with Robin's settings on HPPA with gcc-4.2.4 and glibc-2.7-r2: CFLAGS="-pipe -O2 -march=2.0" CXXFLAGS="-pipe -O1 -march=2.0" USE="cluster* embedded* extraengine* perl ssl -berkdb -big-tables -debug -latin1 -max-idx-128 -minimal (-selinux) -static" FEATURES="test userpriv -usersandbox" Failed 1/499 tests, 99.80% were successful. [...] mysql-test-run in ps-protocol mode: *** Failing the test(s): archive_gis
fails testsuite on x86 (amd64 looks good): ndb_bug31477 [ fail ] mysqltest: At line 71: query 'select * from t1 where b >= 1 order by b' failed: 1296: Got error 241 'Invalid schema object version' from ndbcluster The result from queries just before the failure was: < snip > drop table t1; --con1 create table t1(a int primary key, b int, c int, key(b)) engine = ndb; insert into t1 values (1,1,1); insert into t1 values (2,2,2); insert into t1 values (3,3,3); insert into t1 values (4,4,4); begin; update t1 set c = 10 where a = 1; update t1 set c = 20 where a = 1; update t1 set c = 30 where a = 1; --con1 c=30 select * from t1 where b >= 1 order by b; a b c 1 1 30 2 2 2 3 3 3 4 4 4 --con2 c=1 select * from t1 where b >= 1 order by b; More results from queries before failure can be found in /var/tmp/portage/dev-db/mysql-5.0.70/work/mysql/mysql-test/var-ns/log/ndb_bug31477.log Warnings from just before the error: Error 1296 Got error 241 'Invalid schema object version' from NDB Stopping All Servers Restoring snapshot of databases Resuming Tests <snip> ------------------------------------------------------- Stopping All Servers Failed 1/500 tests, 99.80% were successful. The log files in var/log may give you some hint of what went wrong. If you want to report this error, please read first the documentation at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html The servers were restarted 123 times Spent 1212.796 of 1881 seconds executing testcases mysql-test-run in default mode: *** Failing the test(s): ndb_bug31477 mysql-test-run: *** ERROR: there were failing test cases make: *** [test-ns] Error 1 * test-ns failed <snip> * ERROR: dev-db/mysql-5.0.70 failed. * Call stack: * ebuild.sh, line 49: Called src_test * environment, line 3676: Called die * The specific snippet of code: * [[ -z "$failures" ]] || die "Test failures: $failures"; * The die message: * Test failures: test-ns Portage 2.1.4.5 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26.7 i686) ================================================================= System uname: 2.6.26.7 i686 Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz Timestamp of tree: Sat, 15 Nov 2008 08:30:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r14, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind /var/lib/hsqldb /var/spool/torque" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" LINGUAS="en en_GB de" MAKEOPTS="-j2" PKGDIR="/mnt/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa apache2 berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt cups dbus doc dri dvd dvdr dvdread eds emboss encode esd evo examples fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde ldap libnotify mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session source spell spl ssl startup-notification svg sysfs tcpd test tiff truetype unicode usb vorbis win32codecs x86 xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB de" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Stable on alpha.
Gentoo Hardened 2008.0 on x86_64, Xen 3.0.4 domain sys-devel/gcc-3.4.6-r2 PIE & SSP enabled sys-libs/glibc-2.6.1 CFLAGS=CXXFLAGS="-march=nocona -O2 -pipe -fforce-addr" FEATURES="parallel-fetch test userpriv -usersandbox" dev-db/mysql-5.0.70 USE="berkdb ssl -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -perl (-selinux) -static" stable and working. Please note many USE flags are disabled, though.
dodoc: support-files/my-*.cnf does not exist dodoc: support-files/magic does not exist dodoc: support-files/ndb-config-2-node.ini does not exist dodoc: scripts/mysql* does not exist but amd64 stable anyway, thanks for the testing Luca!
Gentoo Hardened 2008.0 on x86_64, Xen 3.0.4 domain sys-devel/gcc-3.4.6-r2 PIE & SSP enabled sys-libs/glibc-2.6.1 CFLAGS=CXXFLAGS="-march=nocona -O2 -pipe -fforce-addr" FEATURES="parallel-fetch test userpriv -usersandbox" it's the same system as my comment #8 but this time I try the USE flags given in this request. I cannot play too much with the mysql on this system so I used emerge -B mysql, it should produce a binpkg without an actual merge but in doing so it runs the tests. [ebuild R ] dev-db/mysql-5.0.70 USE="berkdb cluster* embedded* extraengine* ssl -big-tables -debug -latin1 -max-idx-128 -minimal -perl (-selinux) -static" 0 kB Failed 47/500 tests, 90.60% were successful. [....] mysql-test-run in ps-protocol mode: *** Failing the test(s): loaddata_autocom_ndb ndb_alter_table ndb_alter_table2 ndb_auto_increment ndb_autodiscover ndb_autodiscover2 ndb_autodiscover3 ndb_basic ndb_bitfield ndb_blob ndb_bug26793 ndb_bug31477 ndb_cache ndb_cache2 ndb_cache_multi ndb_cache_multi2 ndb_charset ndb_condition_pushdown ndb_config ndb_database ndb_gis ndb_index ndb_index_ordered ndb_index_unique ndb_insert ndb_limit ndb_load ndb_loaddatalocal ndb_lock ndb_minmax ndb_multi ndb_read_multi_range ndb_rename ndb_replace ndb_restore ndb_restore_different_endian_data ndb_restore_print ndb_single_user ndb_subquery ndb_transaction ndb_trigger ndb_truncate ndb_types ndb_update ps_7ndb rpl_ndb_innodb_trans strict_autoinc_5ndb
Created attachment 172034 [details] build log [x86_64, hardened, fail] bzipped since it's 1798KiB in plaintext
maekke: I can't reproduce on my x86 luckyluke@softhome.net: that set of test failures (specifically all of NDB because the NDB cluster master fails to start) is identical to what happens with FEATURES=usersandbox on my systems. Can you please check that hardened stuff isn't interfering with the NDB?
(In reply to comment #12) > Can you please check that hardened stuff isn't interfering with the NDB? I don't run a patched kernel since I'm under Xen, so there isn't any grsec here interfering with chroots and similar stuff. Thus my hardened features consists of: toolchain (PIE and SSP turned on by default), profile (hardened is still on gcc-3.4 and glibc-2.6), and some USE flags here and there (slightly different default configurations). As you can see I had -usersandbox in FEATURES in my /etc/make.conf. I really don't know where to look from here, suggestions are welcome. I don't currently have a system where to test stuff on x86_64, if I find some time I'll try to provide one and run an hardened and a non-hardened profiles in Xen domains, but I'm not promising anything ;) Meanwhile I'll try emerging -B mysql-5.0.60-r1 with the same settings to see if it has the same problems. If there are other tests I can do on the existing hardened system, always running emerge -B to not interfere with the running system, I'll be glad to try.
luckyluke@softhome.net: I mean just switch your gcc profiles to try different PIE/SSP/hardened combinations. (hardenednopie, hardenednossp, hardenednopiessp, vanilla).
(In reply to comment #14) > luckyluke@softhome.net: I mean just switch your gcc profiles to try different > PIE/SSP/hardened combinations. (hardenednopie, hardenednossp, hardenednopiessp, > vanilla). I tested myself on another system. x86_64-pc-linux-gnu-3.4.6 - fails x86_64-pc-linux-gnu-3.4.6-hardenednopie - fails x86_64-pc-linux-gnu-3.4.6-hardenednopiessp - passes x86_64-pc-linux-gnu-3.4.6-hardenednossp - passes x86_64-pc-linux-gnu-3.4.6-vanilla - not tested So something with SSP is breaking just the NDB cluster section. hardened: Can you either offer suggestions at tracing why SSP is breaking the MySQL NDB cluster, or can we just put 'dev-db/mysql cluster' in package.use.mask for hardened profiles?
(In reply to comment #5) > with Robin's settings on HPPA with gcc-4.2.4 and glibc-2.7-r2: > > CFLAGS="-pipe -O2 -march=2.0" > CXXFLAGS="-pipe -O1 -march=2.0" > USE="cluster* embedded* extraengine* perl ssl -berkdb -big-tables -debug > -latin1 -max-idx-128 -minimal (-selinux) -static" > FEATURES="test userpriv -usersandbox" > > Failed 1/499 tests, 99.80% were successful. > [...] > mysql-test-run in ps-protocol mode: *** Failing the test(s): archive_gis Thanks for testing. Stable for HPPA.
For hardened, thanks to solar's suggestion, running with an SSP gcc profile, and adding -fno-stack-protector-all to CFLAGS and CXXFLAGS, it does pass the tests.
(In reply to comment #17) > For hardened, thanks to solar's suggestion, running with an SSP gcc profile, > and adding -fno-stack-protector-all to CFLAGS and CXXFLAGS, it does pass the > tests. I think you meant a NON-ssp profile :) I tried on my system and x86_64-pc-linux-gnu-3.4.6-hardenednossp will emerge correctly MySQL-5.0.70 with the full USE flags and testing enabled. While it's good that there is a way to compile it, IMHO the ebuild should take care of this or at least warn the user.
(In reply to comment #18) > I think you meant a NON-ssp profile :) No, I meant that it was broken on SSP profiles, per my comment #15. It will work if: (non-SSP profile) OR ((SSP profile) AND (C[XX]FLAGS has -fno-stack-protector-all)). > I tried on my system and x86_64-pc-linux-gnu-3.4.6-hardenednossp will emerge > correctly MySQL-5.0.70 with the full USE flags and testing enabled. I already noted that per comment #15.
I doubt we're going to fix this and we probably want to get this update out. So could you try adding this to the ebuild (w/ the proper inherits) and see if it works: if [[ $(gcc-major-version) -lt 4 ]]; then filter-flags "-fstack-protector-all" fi Unless the problem also shows itself in gcc-4, in which case get rid of the if/fi check and probably want to report it upstream (they might care if its broke with gcc-4).
gengor: upstream didn't really care about the SSP stuff before, that's why we still carry a partial patch (written by pageexec) since mysql 4.1.12, of the bits that they didn't accept. Trying your filter-flags does seem to work, but I don't see why, since that flag wasn't in the CFLAGS that I passed: CFLAGS='-O2 -pipe' CXXFLAGS='-O2 -pipe' USE='berkdb cluster embedded extraengine' FEATURES='test userpriv -usersandbox' ebuild mysql-5.0.70.ebuild digest clean test
(In reply to comment #0) it fails on sparc USE='berkdb cluster embedded extraengine' FEATURES='test userpriv -usersandbox' emerge -v dev-db/mysql mysql-test-run in ps-protocol mode: *** Failing the test(s): archive_gis loaddata_autocom_ndb ndb_alter_table ndb_alter_table2 ndb_auto_increment ndb_autodiscover ndb_autodiscover2 ndb_autodiscover3 ndb_basic ndb_bitfield ndb_blob ndb_bug31477 ndb_cache ndb_cache2 ndb_cache_multi ndb_cache_multi2 ndb_charset ndb_condition_pushdown ndb_gis ndb_index ndb_index_ordered ndb_index_unique ndb_insert ndb_limit ndb_load ndb_loaddatalocal ndb_lock ndb_minmax ndb_multi ndb_read_multi_range ndb_replace ndb_restore ndb_restore_different_endian_data ndb_restore_print ndb_single_user ndb_subquery ndb_transaction ndb_trigger ndb_truncate ndb_update ps_7ndb rpl_ndb_innodb_trans strict_autoinc_5ndb mysql-test-run: *** ERROR: there were failing test cases [102] [root@startdust:~] # emerge --info Portage 2.2_rc14 (default-linux/sparc/sparc64/2007.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r9 sparc64) ================================================================= System uname: Linux-2.6.25-gentoo-r9-sparc64-sun4u-with-glibc2.0 Timestamp of tree: Tue, 18 Nov 2008 05:01:01 +0000 distcc 2.18.3 sparc-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [disabled] app-shells/bash: 3.2_p33 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.7.9-r1, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="sparc" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=ultrasparc -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -mcpu=ultrasparc -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg collision-protect distcc distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict test unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.localhost.net.ar" LDFLAGS="" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages/sparc" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl apache2 bash-completion bzip2 cli cracklib cups dri fortran iconv ipv6 isdnlog ldap logrotate midi mudflap mysql nptl nptlonly openmp pam pcre perl ppds pppd reflection sasl session snmp sparc spl ssl truetype unicode vim-syntax xml xorg" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev glint mach64 mga r128 radeon sunbw2 suncg14 suncg3 suncg6 sunffb sunleo tdfx v4lvoodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
gfa/sparc: were you using any form of hardened stuff? If not, from the failed system, could you please tar and email me ${S}/mysql-test? It's just the NDB failures again that I saw with usersandbox or hardened SSP.
maekke/x86: somebody else please retest on x86, since I can't reproduce maekke failure on my x86 box.
(In reply to comment #21) > gengor: upstream didn't really care about the SSP stuff before, that's why we > still carry a partial patch (written by pageexec) since mysql 4.1.12, of the > bits that they didn't accept. I believe that patch was for PIC/PIE, not SSP. I didn't check and could be wrong. Since SSP in gcc-3 is non-standard upstream will most certainly not care about SSP in it. They might care about SSP in gcc-4 since its part of mainline gcc in that series. SSP in gcc-4 might also not exhibit the problem, hence the gcc-major-version check. > > Trying your filter-flags does seem to work, but I don't see why, since that > flag wasn't in the CFLAGS that I passed: > CFLAGS='-O2 -pipe' CXXFLAGS='-O2 -pipe' USE='berkdb cluster embedded > extraengine' FEATURES='test userpriv -usersandbox' ebuild mysql-5.0.70.ebuild > digest clean test > The flag is passed by hardened GCC specs.
wfm on x86, all tests passed
I don't know if it's the right place to bring it up here, but I think 5.0.70 is seriously broken somewhere, possibly involving data/table corruption... and discard my complaint in #4, install somehow managed to change the listening parameter so only localhost was connect able. This is something else... I have had 5.0.70 running for some days and all seem to work fine, and apps using it still are able to connect and request data, but... I use Webmin to manage my databases with and suddenly I cannot access any of them in the interface and this happened w/o me installing or changing anything. When I try to access a db in the webmin ui I get this: SQL select table_schema,table_name from information_schema.views failed : Lost connection to MySQL server during query and mysql is killed. In logs: 081119 21:10:52 6 Connect root@localhost on 6 Query show databases 6 Quit 7 Connect root@localhost on acalcdb 7 Init DB acalcdb 7 Query show tables 7 Quit 8 Connect root@localhost on 8 Query show databases 8 Quit 9 Connect root@localhost on 9 Init DB information_schema 9 Query show tables like '%' 9 Quit 10 Connect root@localhost on acalcdb 10 Query select table_schema,table_name from information_schema.views and another strange thing I noticed, since I installed 5.0.70 on Nov 14, every time I stop and start mysql I get a new file mysqld-bin.nnnnnn in /var/lib/mysql, so I am now up to 49 files like this: -rw-rw---- 1 mysql mysql 117 Nov 14 10:48 mysqld-bin.000001 -rw-rw---- 1 mysql mysql 117 Nov 14 10:53 mysqld-bin.000002 -rw-rw---- 1 mysql mysql 117 Nov 14 11:04 mysqld-bin.000003 ... -rw-rw---- 1 mysql mysql 117 Nov 19 21:27 mysqld-bin.000048 -rw-rw---- 1 mysql mysql 98 Nov 19 21:27 mysqld-bin.000049 -rw-rw---- 1 mysql mysql 980 Nov 19 21:27 mysqld-bin.index appearently something connected with mysql-bin.index I have tried to revert back to 5.0.60-r1 but the problem remains, which makes me belive there is data/table corruption involved and I am not quite sure how to go about. I have also tried to revert webmin to earlier known working version but no change. Any idea? btw, I have this in /etc/conf.d/mysql: mysql_slot_0=("default-storage-engine=InnoDB")
I can as well add this from the mysqld log at startup: 081119 22:07:17 InnoDB: Started; log sequence number 0 848834346 081119 22:07:17 [Warning] Found an entry in the 'db' table with empty database name; Skipped 081119 22:07:17 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.70-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Gentoo Linux mysql-5.0.70 081119 22:08:49 [Warning] Found an entry in the 'db' table with empty database name; Skipped not sure what that empty database name is but it sounds bad...
here is more from the mysqld.err log which seem to have some useful info: 081119 22:13:14 InnoDB: Started; log sequence number 0 848843743 081119 22:13:14 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.70-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Gentoo Linux mysql-5.0.70 InnoDB: Unable to lock ./bw2/bit_liberty_content_id_seq.ibd, error: 37 081119 22:16:42InnoDB: Assertion failure in thread 1141680464 in file fil0fil.c line 629 InnoDB: Failing assertion: ret 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. 081119 22:16:42 - 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=16777216 read_buffer_size=262144 max_used_connections=3 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 93184 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x226eee0 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=0x440ca0e0, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) New value of fp=0x226eee0 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 Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x2248da0 = select table_schema,table_name from information_schema.views thd->thread_id=11 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. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 081119 22:17:06 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: Last MySQL binlog file position 0 20227, file name ./mysqld-bin.000058
something serious have really happened sql / # mysql -u root test ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO) sql / # mysql -u root -pmypasswd test ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) The above still apply, but I managed to get out of the grip not being able to access db's. From the mysqld log I noticed this: InnoDB: Unable to lock ./bw2/bit_liberty_content_id_seq.ibd, error: 37 081119 22:49:34InnoDB: Assertion failure in thread 1141414224 in file fil0fil.c line 629 InnoDB: Failing assertion: ret bw2 is a db I created the other day making a test install of the CMS bitweaver, so the db isn't important. Hover I wasn't able to drop it as root with mysqladmin (same access denied as above) but as the user I set up that db to run with having enough prevs. After restart I am able to access db's in webmin again, but root user is still out of power regarding mysql although user table grants full prevs, strange.
Ok I was able to fix root prev's by set again the passwd from webmin, same as before but this generated a new hash and I think here maybe is the root of the problem, old value formats that need to be upgraded. now I was able to run #mysql_upgrde -pmypasswd and it certainly found some tables in need of REPAIR: davaccess.user_groups error : Table upgrade required. Please do "REPAIR TABLE `user_groups`" to fix it! so maybe some forced check is needed here to make sure user fix inconsistancies before running into trouble and being forced to drop a realy important table??? Well I hope the above have been of some use, or will to someone and not just go to history as a big rant, just trying to contribute ;-)
joakim: how old was your database? mysql_upgrade doesn't do all that much unless your database are from a really old and you didn't run mysql_upgrade before, nothing that would change you between being locked out and not. After that, I'd blame webmin for doing something weird probably, with bad hardware or gcc as a close third. Start with skip-grant-tables, run REPAIR TABLE on your entire database, every single table, and then start trying stuff again. Also run the full testcases on your system, if they crash and it's not highly repeatable, it's probably hardware. MySQL is good at exposing hardware errors.
Robin: You probably have a point there with the db age, I think I have a few rather old db origine from 4.x something or even 3.53 and been brought forward on upgrading mysql - all in line with the Gentoo mysql upgrade guide though - but I cannot recall I ever ran mysql_update before. Now some tables that was corrupted wasn't that old and the one that seem to have crashed webmin was just about a week, but it's not unlikely something already was lingering in the system. I think I am ok now though after I managed to remove the faulty db, recreated root password hash and ran mysql_update, now all seem to work fine with 5.0.70 - I guess it was just bad luck it went over the edge at this point, and not earlier or later ;-)
joakim: the upgrade guide does state mysql_upgrade is needed, in listing 1.1. gengor: thanks, I've applied the change to the mysql eclass now. x86: armin76 tested it as good, you're clear to stabilize. sparc/sh/s390/ppc/ppc64/ia64/arm: still waiting for you, we need this to issue several GLSAs.
ia64/sparc/x86 stable
ppc stable
ppc64 done
Robin: I did my upgrade long time ago, cannot remember how long, but long ago and I am sure I followed the guide as it was then, and if it said something about running upgrade script, I am sure I did it. Point is though, I still have problems with 5.0.70 tables getting corrupted and server chrashes on CHECK TABLE, and it's all about InnoDB tables. Now I think I did something bad as well, sitting in front of it for too long, I seem to have stuff lurking in the tablespace referring to a db (and tables) no longer in the system. The table names exists, but I changed name on db as I wasn't able to drop the original one and finally "hard removed" it with #rm -r dbname, which maybe wasn't so good but saw no other way to get rid of it. But it's still lurking somewhere inside of mysql's permanent memory :-( No I have dump backups of most resent data, so I thought of simply remove current instance of mysql-5.0.70 completely, clean-up and reinstall from scratch so to speak. I am also thinking of moving over to mysql-community as I assume SUN will make sure that happens sooner or later anyway, so just accepting that I don't have their size of wallet...
fyi a simple rename of mysql-5.0.70.ebuild to mysql-5.0.72 seem to work fine, at least it compiles and start up fine, the latter also seem to fix several bugs present in 5.0.72 so maybe a ~ bump at least would be in order? I installed this is another openvz CT to see if I can move over my postfix db, before 5.0.70 corrupt it as well. So it will get some live testing.
Joakim: You don't need to move to -community unless you want some feature that is only in community. And I am testing 5.0.72 already. Sun is still providing the source tarballs to customers, and some of them are distributing them publically (like Jeremy Cole's provenscaling).
security: Only arm, s390 and sh are left, so you can probably issue the GLSAs from bugs 229329, 237166, 238117, 240407, right, or do we need to chase those arches still?
(In reply to comment #41) > security: Only arm, s390 and sh are left, so you can probably issue the GLSAs > from bugs 229329, 237166, 238117, 240407, right, or do we need to chase those > arches still? Nope, we won't wait for the mentioned architectures before GLSA. However, please elaborate on bug 240407 and bug 229329 whether they are actually fixed by this upgrade. My looking at the upstream commit logs, they never made it in there and I did not find the patches in our own patchset. Maybe I didn't look hard enough.
@Robin: Thanks and you are right, I will skip the thoughts of moving to community for now. I made an ebuild for 5.0.72 by renaming a copy of 5.0.70 and put it in my overlay and it runs fine an no sign of corruptions as before. But I also did some resource adjustments for the openvz CT and it's maybe what was needed as no one else reporting similar problems, but looking at upstrea's changelog quite a few bugfixes have been done since .70 anyway ;-)
Target keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 Test instructions: USE='berkdb cluster embedded extraengine' \ FEATURES='-test userpriv -usersandbox' \ emerge mysql arches, sorry to restart stabilization, but I missed two patches for security issues (I didn't check for the patches being in final and one of them was reverted by upstream temporarily and not reapplied for the release). Since we did the actual testcases already, and the new code doesn't cover stuff that has existing testcases, I think just try to compile it and mark stable if you can compile.
amd64/x86 stable
alpha/arm/ia64/sparc stable
01 Dec 2008; Brent Baude <ranger@gentoo.org> mysql-5.0.72-r1.ebuild: Marking mysql-5.0.72-r1 ppc64 for bug 246652 Wrong version.
ppc64 fixed. Sorry about that
s390/sh stable
shouldn't be affected versions dropped from tree?
Stable on all arches, closing.
