On brand new gentoo installation I can't get MySQL 5.0.22 to work on my AMD64 machine. I successfully install mysql 5.0.22 and installed the mysql database using: # mysql_install_db Then I started it up: # /etc/init.d/mysql start * ... * Starting mysql (/etc/mysql/my.cnf) And it works fine. Then when I restart it: schwartz lib # /etc/init.d/mysql restart * Stopping mysql ... * Stopping mysqld (0) [ ok ] * ... * Starting mysql (/etc/mysql/my.cnf) * MySQL NOT started (0) fails. I can then # rm -rf /var/lib/mysql/* # mysql_install_db # /etc/init.d/mysql start And it works fine. Then again if I reboot or restart the server it crashes. The mysqld.err log puts out the following: InnoDB: The first specified data file ./ibdata1 did not exist: InnoDB: a new database to be created! 060602 16:08:52 InnoDB: Setting file ./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 060602 16:08:52 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait... 060602 16:08:53 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait... InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 060602 16:08:53 InnoDB: Started; log sequence number 0 0 060602 16:08:53 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.22' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Gentoo Linux mysql-5.0.22 060602 16:08:58 [Note] /usr/sbin/mysqld: Normal shutdown 060602 16:08:58 InnoDB: Starting shutdown... 060602 16:08:59 InnoDB: Shutdown completed; log sequence number 0 43655 060602 16:08:59 [Note] /usr/sbin/mysqld: Shutdown complete mysqld got signal 4; 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=258048 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 = 76399 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. emerge --info Portage 2.0.54-r2 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.5-r3, 2.6.16-gentoo-r7 x86_64) ================================================================= System uname: 2.6.16-gentoo-r7 x86_64 Intel(R) Pentium(R) D CPU 3.00GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.chem.wisc.edu/gentoo/ http://mirror.mcs.anl.gov/pub/gentoo/ http://gentoo.cites.uiuc.edu/pub/gentoo/ " MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi ads aim alsa apm arts audiofile avi bash-completion berkdb bitmap-fonts browserplugin bzip2 cdparanoia cdr cli crypt cups curl directfb dri dvd dvdr eds emboss encode exif expat fam ffmpeg foomaticdb fortran gdbm gif gimpprint gmp gphoto2 gpm gstreamer gtk gtk2 hal howl idn imlib ipv6 isdnlog java jpeg junit kde kerberos lcms ldap lzw lzw-tiff mad mng mp3 mpeg musicbrainz mysql ncurses nls nptl nsplugin odbc opengl pam pcre pdf pdflib perl png ppds pppd python qt quicktime rdesktop readline reflection ruby samba sasl sdl session spell spl sql ssl subversion tcpd tiff truetype truetype-fonts type1-fonts udev usb winbind xinerama xml2 xorg xpm xv zeroconf zlib userland_GNU kernel_linux elibc_glibc" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS, PORTDIR_OVERLAY
Created attachment 88213 [details] my.cnf configuration
Well I figured out a fix but I don't know what's wrong. If in the my.cnf file i change the tmpdir to anything but /tmp or /var/tmp it seems to work fine. Maybe something about the sticky bit?? drwxrwxrwt 5 root root 4096 Jun 2 16:23 tmp I guess we could close this but that doesn't seem right. I've always had the tmp dir for MySQL as /tmp Also I installed 4.1.22 and that worked fine with the same my.cnf
Well looking at the logs it looks like I can only get it to start when tmpdir is something that the mysql user can't write to. I get an error like the following: /usr/sbin/mysqld: Can't create/write to file '/ib0JR5zf' (Errcode: 13) 060602 16:36:21 InnoDB: Error: unable to create temporary file; errno: 13 But the server appears to start and works. Not sure what the negative of not having a tmpdir is.
*** Bug 135387 has been marked as a duplicate of this bug. ***
looks like the root cause might be innodb. I was able to use /tmp and my tmpdir with skip-innodb enabled in my.cnf. Any ideas why innodb would become a problem?
I'm getting what looks like a very similar or the same error on PPC, but rather than on the second-run, it happens when run mysql_install_db on trying to initialise the database for first use. The error reported in /var/log/mysql/mysqld.err is: mysqld got signal 4; 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=258048 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 = 92783 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. emerge --info output is: Portage 2.1 (default-linux/ppc/ppc32/2006.0/G4, gcc-3.4.6, glibc-2.3.6-r3, 2.6.16-gentoo-r9 ppc) ================================================================= System uname: 2.6.16-gentoo-r9 ppc 7447A Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -fomit-frame-pointer" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc alsa altivec apache2 apm arts berkdb bitmap-fonts bonobo cdr cli crypt cups dri dvd eds emboss encode esd foomaticdb fortran gdbm gif gnome gstreamer gtk gtk2 gtkhtml imlib ipv6 isdnlog jpeg kde ldap libg++ libwww mad mikmod motif mozilla mp3 mpeg ncurses nls nptl ogg opengl pam pcre pdflib perl png pppd python qt quicktime readline reflection ruby sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode vorbis xml xmms xorg xv zlib elibc_glibc kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY /etc/mysql/my.cnf is as per gentoo default.
Update: Am now getting exactly as originally reported on this bug - only not as a result of mysql_install_db but running emerge --config =dev-db/mysql-5.0.22 - this actually succeeds, mysql starts, but fails exactly as already detailed on the *second* start.
Update: I tried the same thing as suggested by someone else here, and skipped innodb in my.cnf. Mysql then started OK. However as soon as it's first accessed by PHP, mysql quits with signal 4.
Update: Also fails when just interacted with by its own mysql client. Simply go in as mysql -u root -p and quit from the client straight away without even doing anything. It dies with signal 4. OK, this is hopelessly broken. I haven't bothered pasting in the signal 4 error message because it's essentially identical to those pasted earlier.
Current stable version mysql-4.1.20 exhibits same problem, even after an emerge --emptytree world (suspecting a dependency on something from the stage3 binaries).
Got a working mysql 5.0.22 thusly: First, I just did a manual build from source following the instructions in the INSTALL-SOURCE file included in the distribution. It worked perfectly straight off. Then I as much as possible configured my system to build the Gentoo ebuild in the same way: /etc/portage/package.cflags (with Solar's /etc/portage/bashrc installed): dev-db/mysql -O3 -felide-constructors -fno-exceptions -fno-rtti /etc/portage/package.use: dev-db/mysql -ssl static /etc/portage/package.keywords: dev-db/mysql ~ppc This also worked fine.
> /etc/portage/package.cflags (with Solar's /etc/portage/bashrc installed): > dev-db/mysql -O3 -felide-constructors -fno-exceptions -fno-rtti I changed my package.cflags file to the above and built mysql like the following: [ebuild R ] dev-db/mysql-5.0.22 USE="berkdb perl ssl -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -srvdir -static" 0 kB And indeed innodb turned on also works for me now too. So now the question is what was wrong with my normal cflags?
My guess is the -fno_exceptions CFLAG. There's a specific note to the effect it *must* be set in the mysql build instructions. But I haven't gone back to progressively take out the other custom CFLAGS and USE flags I defined to get this working, because I frankly needed to get it into production quickly :-) The ebuild probably just needs to set that one flag itself. At least on ppc (g4) and amd64 - apparently wasn't necessary on x86.
The C(XX)FLAGS are correctly set since a few months now inside the MySQL ebuilds, as upstream specifies on the manual, also actual stable MySQL is 5.0.26-r2 and unstable 5.0.32, so please try with those versions, and reopen if needed. Best regards, CHTEKK.
