what is wrong with mysql 4.1.7 on gentoo?

[tulpa]

Ok, this is really really weird....

I'm trying to install mysql 4.1.7 on my box which I KNOW is marked as unstable in the portage tree but it is stable according to mysql. I'm ok with that as long as I can install it. I started installing it on all my boxes a few weeks ago almost the day after they put the ebuild in the portage tree. Everything worked fine, I followed the ebuild to a T...

1. I had to emerge DBD-mysql-2.9004 which was marked as untable but screw it.
2. I had to then unmerge my current version of mysql which was ok.

3. I emerged mysql-4.1.7 directly to its .ebuild file

4. I didn't have to do a mysql_install_db because the tables where already made.

5. I started up mysql and everything was lolipops and ball sacks in the universe.

Ok get this. a few days and emerge sync's later I tried performing the exact same steps on different servers for the past 2 weeks and after I follow the steps mysql 4.1.7 craps out. It does this endless loop and restarts its self over and over again really fast when I try to run mysqld_safe. When I try to just run the mysql command it says it can't connect to the db server which is kinda true since it can't sit still.

I've googled and searched these forums for weeks. I've seen posts of people having the exact same endless loop problem and I have followed all there fixes and its still broken. These are the things I already tried to figure out why some gentoo boxes worked...

1. I made a print out of all the ebuilds emerged on a worked mysql 4.1.7 boxes (emerge -ep world) and compared the packages and version numbers to a print out of all the ebuilds on a box that mysql tanks on. Everything checks out fine. The only difference in packages and versions of packages are the apache things I built (apache, php, mod_php) and I built those and tried to rebuild mysql again and it still failed.

2. I reformated the drive and remerged my whole system over again with the same USE flags I setup in /etc/make.conf

3. I did 2. but used NO use flags what so over and just used the system defaults

4. I thought it could be a bad tar.gz file so I did an md5 check sum on it and compared it to the one posted on mysql's web site and they matched.

5. I bypassed the ebuild system all together and compiled it by hand into a self contained directory to see if I could execute it. Same exact endless loop result for mysqld_safe

6. I downloaded the pre compiled linux distribution from mysql.com and just executed the db myself, SAME thing. I even used the other linux pre compiled version just as a long shot.

7. Since I knew the 4.0 ebuild works fine, I thought I would perform a bit of a hack and rename the 4.0 ebuild to a 4.1.7 ebuild so it installs 4.1.7 but uses 4.0 patchs and ebuild configs instead...same thing happens.

8. I tried 2. and 3. but both times I tried to run mysqld_safe without a mysql_install_db first.

9. big duh, I checked the log file and it gave me all kinds of segment faults and bla bla bla.

10. Since the errors I found said mysql could already be running or opening the mysql port, I did a netstat -l to see if it was already turned on but it wasn't. I also checked the mysqld.sock file and it wasn't created. The dang thing couldn't create it. I checked the permissions and even did a big fat ass chmod -R 777 to my WHOLE file system JUST to make monkey balls sure that everything could write to everything.

11. I thought MAYBE it could be something in the portage tree. Like some change they made AFTER I got mysql 4.1.7 up and running and that new change is hosing up my boxes. I tested this by doing an emerge sync and then re emerging mysql 4.1.7 on a known working box and it worked fine, perfecting freakin peter pan paul and marry claws on my balls fine with powered sugar crapidy crap crap nut sacks fine!

12. Just as a paranoid idea, I did a emerge -e world on one of the failed boxes so I recompiled the whole system, then I re emerged mysql and it still failed.

GOD what is going on. I don't get it, I just don't get it. I tried duron, athlons, xeons and celerons. I got servers in my house, all of which have gentoo on them. I got boxes in the office and dedicated boxes outside of the office. I do not like green eggs and ham I do not like them sam I CAN'T EMERGE MYSQL 4.1.7!

Can someone PLEASE just donate an hour or so of there time to just do a fresh gentoo install on a box and try to get mysql 4.1.7 working on it. Save your breath if you already emerged your system before Nov 20th. Mysql will work just fine and all will be well. I'm looking for those folks out there trying to emerge a system with mysql 4.1.7 some time this month. For balls sake, theres GOT to be a freak way around this. There HAS to be. I have the same problem others have had but they wern't using gentoo and I performed all the system checks they have performed. Please just try it out on your own and IF you got it emerged on a system that has been installed some time this month can you please tell me what you did and what USE flags you used? Thank you for your time and emerge cpu cycles.

[steveb]

i don't have 4.1.7 installed on my system, but if you think the ebuild is diffrend then do a diff on the system where you have a working mysql 4.1.7:

[tulpa]

I have an auto cron script on all my boxes that update the emerge tree once a day. Doing a diff on the ebuild files or anywhere in /usr/portage wouldn't do any good because all the files are the same from the rsync. Besides, with the latest and greatest portage, I can install mysql 4.1.7 just fine on the working boxes, but when I run the exact same command on the failed servers, I get the same errored result.

[steveb]

okay... then try to build a binary package on the system where mysql 4.1.7 is working and then emerge this binary package on a non-working system.

cheers

SteveB

[tulpa]

Great idea about the binary dist thing!!! um.. can you send me a link to a tutorial on how to do that? I've always been a compile kinda guy. But the logic sound pretty right to me.

[steveb]

option 1 (requires you to recompile mysql again):

[tulpa]

I tried both methods and both methods failed in the same way as if I tried to emerge it the old fashioned way....

localhost root # mysqld_safe
Starting mysqld daemon with databases from /var/lib/mysql

Number of processes running now: 0
041211 06:07:43 mysqld restarted

Number of processes running now: 0
041211 06:07:43 mysqld restarted

Number of processes running now: 0
041211 06:07:43 mysqld restarted

Number of processes running now: 0
041211 06:07:43 mysqld restarted

Number of processes running now: 0
041211 06:07:43 mysqld restarted

Number of processes running now: 0
041211 06:07:43 mysqld restarted

etc etc etc....


/var/log/mysql/mysqld.err...

thd=0x80717498
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=0x9f, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0x9f, stack_bottom=0xc0000000, thread_stack=131072, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
041211 6:07:43 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
041211 6:07:43 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
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=131072
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 = 233983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x80717498
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=0x9f, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0x9f, stack_bottom=0xc0000000, thread_stack=131072, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
041211 6:07:44 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
041211 6:07:44 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
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=131072
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 = 233983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x80717498
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=0x9f, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0x9f, stack_bottom=0xc0000000, thread_stack=131072, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
041211 6:07:44 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
041211 6:07:44 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
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=131072
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 = 233983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x80717498
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=0x9f, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0x9f, stack_bottom=0xc0000000, thread_stack=131072, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
041211 6:09:57 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
041211 6:09:57 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
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=131072
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 = 233983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x80717498
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=0x9f, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0x9f, stack_bottom=0xc0000000, thread_stack=131072, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

/var/log/mysql/mysql.log...
localhost root # tail -n 100 /var/log/mysql/mysql.err

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:55 mysqld restarted

Number of processes running now: 0
041211 05:07:56 mysqld restarted

Number of processes running now: 0
041211 05:07:56 mysqld restarted

Number of processes running now: 0
041211 05:07:56 mysqld restarted

Number of processes running now: 0
041211 05:07:56 mysqld restarted

Number of processes running now: 0
041211 05:07:56 mysqld restarted

Number of processes running now: 0
041211 05:07:56 mysqld restarted

Could it be a system emerge package? Like some library that I forgot to put a critical USE flag on? Do you have mysql 4.1.7 working on your server?

[steveb]

[steveb]

[tulpa]

Thats right. I forgot. If you change your mysql version you have to recompile everything that req mysql support because they where compiled with different mysql libraries. My bad.

hmm.... Is there any way I can do an emerge comparison on both systems so I can see the differences in what I emerged, what order that stuff was emerged in and what USE flags I set them with?

[steveb]

yes! just look into /var/db/pkg/<category>/<package>-<package-version>/ and you will see the use-flgas used and the cflags and and and....

cheers

SteveB

[tulpa]

Ok, I tried to fix the priv table but it didn't work...

localhost root # mysql_fix_privilege_tables --verbose
This script updates all the mysql privilege tables to be usable by
MySQL 4.0 and above.

This is needed if you want to use the new GRANT functions,
CREATE AGGREGATE FUNCTION, or the more secure passwords in 4.1

You can safely ignore all 'Duplicate column' and 'Unknown column' errors
because these just mean that your tables are already up to date.
This script is safe to run even if your tables are already up to date!

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
Got a failure from command:
/usr/bin/mysql -f --user=root --host=localhost --database=mysql
Please check the above output and try again.

If you get an 'Access denied' error, you should run this script again and
give the MySQL root user password as an argument with the --password= option


And yes I made sure mysql was running by doing a "ps aux | grep sql" and it gave me...

localhost root # ps aux | grep sql
root 18429 3.1 0.3 1996 992 ? Ss 09:23 0:00 /bin/sh /usr/bin/mysqld_safe
root 20443 0.0 1.2 11380 3140 ? R 09:23 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
root 20445 0.0 0.1 1416 452 pts/0 S+ 09:23 0:00 grep sql

[steveb]

i can't help you more. i would be forced to install 4.1.7 and i don't want that. i don't need anything special from 4.1.7. my 4.0.xx release is good the way it is now and for special tasks i use anyway postgresql.


cheers

steve

[tulpa]

Thanks for your help. I really appreciated all of it.

[ofeet]

[NOTE* THIS IS A FIX]

when i updated to 4.1 a lot of stuff got screwed.

when I tried to connect i got the "could not connect to mysqld.sock (111)" yada yada.

Here's what I did to fix it...

# cd /var/lib/mysql
and then delete ib_logfileX (x being for how ever many there are wrong)

then shutdown mysql if you have it on (you might have to zap it) and then start it back up.
you can now connect with 'mysql --user=root -p'

The problem is that I uninstalled 4.0 and installed 4.1
in 4.0 the log file sizes where different. it's lame, but this caused problems in 4.1

anyway, hope this helped!
_________________
I have nothing witty or brilliant to put here... /tear