"emerge -u mysql" went from dev-db/mysql-4.0.20 to dev-db/mysql-4.0.20-r1 and broke php connections to the databases. "Warning: mysql_connect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13) in /path/to/script.php" Now, /var/lib/mysql/mysql.sock is being created correctly, and is the setting in both my.cnf and php.ini. I can still connect to the data with "mysql" at the command line. Re-emerging mod_php-4.3.8 doesn't change the problem. So ... what am I missing? This is with apache-1.3.31-r3 (also freshly emerged, replacing apache-1.3.31-r2). Reproducible: Always Steps to Reproduce: 1. 2. 3. # emerge info Portage 2.0.50-r11 (default-x86-1.4, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.5-gentoo-r1) ================================================================= System uname: 2.6.5-gentoo-r1 i586 AMD-K6(tm) 3D processor Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=k6-2 -O2 -fomit-frame-pointer -funroll-loops -pipe" CHOST="i586-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k6-2 -O2 -fomit-frame-pointer -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X apm arts avi berkdb bitmap-fonts crypt cups encode foomaticdb gdbm gif gpm gtk gtk2 imlib jpeg kde libg++ libwww mad mbox mikmod motif mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcltk tcpd truetype x86 xml2 xmms xprint xv zlib"
What I was missing was the ebuild changed the perms on /var/lib/mysql so mysql.sock wasn't available to php! This needs to be fixed in the ebuild, imho. Apache/php is not going to be running as root or as mysql.mysql, so this is just broken for anyone who keeps mysql.sock there (a standard location, although not the Gentoo default - but Gentoo doesn't keep anything else there, so this is all it seems it would apply to).
The problem was introduced by the lines if [ -z "${DATADIR}" ]; then DATADIR="/var/lib/mysql/" fi chown -R mysql:mysql ${DATADIR} chmod 0750 ${DATADIR} in the ebuild. Since this was an upgrade rather than a fresh install, could the ebuild have instructed emerge to leave well enough alone? In almost all existing installations a data dir will already exist, and can be found by examining my.cnf (if emerge has access to that?). In any case /var/lib/mysql is not my data dir, but it is where (for historical reasons - it's standard on non-Gentoo mysql setups) I keep mysql.sock. Shouldn't this sort of ownership/permissions change be left up to the user anyway? In a fresh install, it's fine to use defaults, but when directories exist, should the ebuild be making this sort of assumption about their current use?
The real bug looks like it's in: DATADIR=`my_print_defaults mysqld | sed -ne '/datadir/s|^--datadir=||p' | tail -n1` which has replace the older line from .20: DATADIR=`/usr/sbin/mysqld --help |grep '^datadir' | awk '{print $2}' So that first one for some reason failed on my system, thus cascading to the perms being reset wrong (for this system). Maybe revert to the version that works??
Yikes, the problem was still further upstream, I think. That command does show the right data dir now. But the ebuild had _replaced_ my my.cnf without asking. I'd replaced it back - I checked that before restarting and caught it. But my guess is the line got the wrong data dir because that came after emerge had substituted the default my.cnf over the working one. Can't recall seeing that happen before, and haven't changed any settings on what to protect from such overwriting. In any case, it looks like it must have happened before the ebuild got to that line.
Correction on that last: The substitution of my.cnf must have been my own mistake post-installation. But, I have another system, same my.cnf, same upgrade, and the ebuild also changed the ownership and perms on /var/lib/mysql - so for some reason that my_print_defaults line in the new ebuild file is not succeeding in the context it's run - while the older grep method had worked fine when upgrading on both these systems to .20.
This is still broken as of mysql-4.0.22. Why has there been absolutely no attention to this? If you look above I identified where the ebuild script is buggy. Please fix it.
If you looked closer at the 4.0.22 ebuild, you would see that the only place your referenced lines: if [ -z "${DATADIR}" ]; then DATADIR="/var/lib/mysql/" fi chown -R mysql:mysql ${DATADIR} chmod 0750 ${DATADIR} exist is inside the pkg_config function - which should only ever be run manually by the user on new installs. Regardless, in 4.0.23, i've put in some einfo statements that print out what directory they are about to operate on.
I just did the upgrade to mysql-4.0.22 and it changed the perms on /var/lib/mysql so that mysql.sock could not be written there. I did not run anything manually, and it was not a new install. It did this on two different systems. And /var/lib/mysql is not the datadir in my installations. I don't believe /var/lib/mysql is the default place for mysql.sock to go in Gentoo, however it's a fairly standard place to put it. So to sum up, "emerge -u mysql" will take a system in which my.cnf has the datadir somewhere else than /var/lib/mysql, and is using /var/lib/mysql to store mysql.sock (and nothing else), and will switch the perms on /var/lib/mysql so that it is no longer accessible on startup to put mysql.sock there - which stops mysql from running until the problem is tracked down and fixed. Maybe I didn't fully debug how that happens, but it wasn't a problem until 4.0.20-r1, it was still a problem in 4.0.22, and what you say you've done won't have fixed it unless by accident.
Slight correction: When I said "stops mysql from running," what I should have said is "stops other programs (e.g. PHP) which connect through mysql.sock from accessing mysql (which can really screw up Web sites), since there is not a valid mysql.sock in /var/lib/mysql where they're looking for it. (What happens with the upgrade is that the perms get changed, and then the old mysql.sock - evident from its date - is still sitting there, but of course won't connect with the new instance of mysql. My initial report here missed the wrong date on mysql.sock.) Change the perms on /var/lib/mysql back, restart mysql, and it's fixed. But it shouldn't be up to the user to do that - it's an ebuild malfunction that produced it. Mysql does start in this situation, it just won't successfully create mysql.sock in /var/lib/mysql, because the perms have been inappropriately changed to no good end (although if that were the datadir in the installation, there would be a good end to it).
I've just put 4.0.22-r1 in the tree, specially for you. Try it (it's only in ~x86 so that stable users don't get it, it's very similar to the old 4.0.22). If it does still cause the problem, debug it more throughly, by altering the ebuild to display the permissions of /var/lib/mysql around places you think it is being changed.
no response from user.
Didn't see your 12-23 message - probably went by it too fast while at relative's for the holiday. Is 4.0.22-r1 still the one to test, or has the modification been inherited by others since? Thanks.
yes, 4.0.22-r1 is still the version to test, or the new 4.0.24-r1 which will be in CVS soon.
