mysql timezone problem
after changing my system timezone from UTC to MSD i have the following problem: after restarting mysql server its timezone has not changet at all: mysql show variables like '%zone%'; +--++ | Variable_name| Value | +--++ | system_time_zone | UTC| | time_zone| SYSTEM | +--++ meanwhile system command date says the following: # date Tue Mar 28 18:35:45 MSD 2006 OS: FreeBSD 6.0-RELEASE mysql: mysql Ver 14.12 Distrib 5.0.18, for portbld-freebsd6.0 (i386) using 5.0 -- С уважением, Сергей Аверьянов, ООО Паллант Мобайл, Руководитель отдела разработок +7 9272 702841 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: mysql timezone problem
[EMAIL PROTECTED] schrieb: after changing my system timezone from UTC to MSD i have the following problem: after restarting mysql server its timezone has not changet at all: mysql show variables like '%zone%'; +--++ | Variable_name| Value | +--++ | system_time_zone | UTC| | time_zone| SYSTEM | +--++ This is not necessarily wrong. See if select now(); gives you the correct time. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Timezone problem.
The small problem in mysql is it does not check if parameter is correct in configure script - this produced the problem... Peter mailto:[EMAIL PROTECTED] Yes, I don't know of any clear way of handling this with autoconf. Basically, if your option starts with --with-, then the script just sets a variable and moves on. If anyone knows a good way to validate --with- and --enable- options in an autoconf-generated configure script, let me know. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-time Developer /_/ /_/\_, /___/\___\_\___/ Boone, NC USA ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Timezone problem.
Peter Zaitsev writes: Hello Michael, Tuesday, August 07, 2001, 10:20:18 PM, you wrote: The question is which place do you do aply timezone ? I found the following interesting thing: Then mysql is started it uses correct timestamp, therefore INNODB is started with wrong timestamp... 010807 12:59:44 mysqld started 010807 8:59:45 InnoDB: Started The above means that timezone has changed between the two calls .. Between the two was tzset call. This is a typical case when a zone is changed from GMT to something else !!! And you are 4 hours before GMT, aren't you ?? If on Linux, check where does /etc/localtime point to. Simply, your startup scripts are not well setup. TZ should be set at the machine boot. -- Best regards, Petermailto:[EMAIL PROTECTED] -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Timezone problem.
Hello mysql, It seems like you made an incomportable changes in 3.23.40 without taking a time to write a release note :( The mysql 3.23.39 used the system timezone by default: maindb:/spylog/mysql/logs # date Tue Aug 7 13:31:56 MSD 2001 | transaction_isolation | READ-COMMITTED | | | | timezone| MSD | | | | tmp_table_size | 4194304 Therefore MYSQL 3.23.40 does not determinate the timezone correctly: | | transaction_isolation | READ-COMMITTED | | | | timezone| Local time zone must be set--see´ manual page | | | | tmp_table_size | 4194304 | | | It uses GMT in this case which could dammage the data (as went in my case) The other thing is the manual does not contains much info about setting timezone - only option to safe_mysqld which exports TZ variable, which does not work: root 19380 1 0 13:43 pts/800:00:00 sh /usr/local/mysql/bin/safe_mysqld --mysqld=mysqld --user=mysql --pid-file=/spylog/db/mysqld.pid --timezone=MSD --datadir=/spylog/db It set's the timezone according to required value but date still bad: | transaction_isolation | READ-COMMITTED | | | | timezone| MSD | | | | tmp_table_size | 4194304 mysql select now(); +-+ | now() | +-+ | 2001-08-07 09:44:44 | +-+ 1 row in set (0.00 sec) Therefore date returns correct value. rat:/spylog/layers # date Tue Aug 7 13:47:05 MSD 2001 rat:/spylog/layers # Do you have any ideas about this ? How I can fix the problem ? -- Best regards, Peter mailto:[EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re[2]: Timezone problem.
Hello Sinisa, Tuesday, August 07, 2001, 4:48:56 PM, you wrote: 1) SUSE. Destributions does not have TZ variable set by default. And the idea is it worked quite well wothout it with .39 2) The strange thing is why settng TZ makes mysql to print correct timezone in variables but still produces the wrong time ? SM Peter Zaitsev writes: Hello mysql, It seems like you made an incomportable changes in 3.23.40 without taking a time to write a release note :( The mysql 3.23.39 used the system timezone by default: maindb:/spylog/mysql/logs # date Tue Aug 7 13:31:56 MSD 2001 | transaction_isolation | READ-COMMITTED | | timezone| MSD | | tmp_table_size | 4194304 Therefore MYSQL 3.23.40 does not determinate the timezone correctly: | | transaction_isolation | READ-COMMITTED | | timezone| Local time zone must be set--see´ manual page | | tmp_table_size | 4194304 | It uses GMT in this case which could dammage the data (as went in my case) The other thing is the manual does not contains much info about setting timezone - only option to safe_mysqld which exports TZ variable, which does not work: root 19380 1 0 13:43 pts/800:00:00 sh /usr/local/mysql/bin/safe_mysqld --mysqld=mysqld --user=mysql --pid-file=/spylog/db/mysqld.pid --timezone=MSD --datadir=/spylog/db It set's the timezone according to required value but date still bad: | transaction_isolation | READ-COMMITTED | | timezone| MSD | | tmp_table_size | 4194304 mysql select now(); +-+ | now() | +-+ | 2001-08-07 09:44:44 | +-+ 1 row in set (0.00 sec) Therefore date returns correct value. rat:/spylog/layers # date Tue Aug 7 13:47:05 MSD 2001 rat:/spylog/layers # Do you have any ideas about this ? How I can fix the problem ? Peter mailto:[EMAIL PROTECTED] SM Hi Pjotr, SM I just tested the above, and it worked just fine for me with 4.0. SM But I have noticed something. If I mess up my shell, it will mess up SM all programs started from it, including MySQL. We can not do anything SM about it ... SM If a shell that starts up MySQL does not have TZ set properly then SM there is not much we can do about it ... -- Best regards, Petermailto:[EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Timezone problem.
Hi!
"Peter" == Peter Zaitsev [EMAIL PROTECTED] writes:
Peter Hello mysql,
Peter It seems like you made an incomportable changes in 3.23.40 without
Peter taking a time to write a release note :(
Peter The mysql 3.23.39 used the system timezone by default:
Peter maindb:/spylog/mysql/logs # date
Peter Tue Aug 7 13:31:56 MSD 2001
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| MSD
|
Peter | tmp_table_size | 4194304
Peter Therefore MYSQL 3.23.40 does not determinate the timezone correctly:
Peter |
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| Local time zone must be set--see´ manual
page
|
Peter | tmp_table_size | 4194304
|
Are you sure you are not starting mysqld differently ?
According to my knowing, we have not changed anything in timezone
usage in MySQL.
The name if the timezone mysqld displays is what we get from the
following call:
{
struct tm tm_tmp;
localtime_r(start_time,tm_tmp);
strmov(time_zone,tzname[tm_tmp.tm_isdst == 1 ? 1 : 0]);
}
I don't know why localtime_r() doesn't work in your case, but I would guess
something in your setup that has changed.
The only way to affect the timezone is to set the TZ variable before
starting mysqld/safe_mysqld or by starting safe_mysqld with the
--timezone= option.
Peter It uses GMT in this case which could dammage the data (as went in my
Peter case)
Peter The other thing is the manual does not contains much info about
Peter setting timezone - only option to safe_mysqld which exports TZ
Peter variable, which does not work:
Peter root 19380 1 0 13:43 pts/800:00:00 sh
/usr/local/mysql/bin/safe_mysqld --mysqld=mysqld --user=mysql
--pid-file=/spylog/db/mysqld.pid --timezone=MSD --datadir=/spylog/db
Peter It set's the timezone according to required value but date still bad:
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| MSD
|
Peter | tmp_table_size | 4194304
mysql select now();
Peter +-+
Peter | now() |
Peter +-+
Peter | 2001-08-07 09:44:44 |
Peter +-+
Peter 1 row in set (0.00 sec)
Peter Therefore date returns correct value.
Peter rat:/spylog/layers # date
Peter Tue Aug 7 13:47:05 MSD 2001
Peter rat:/spylog/layers #
Peter Do you have any ideas about this ? How I can fix the problem ?
Sorry, no ideas; It looks like there is some problem with your glibc
library.
Did you try the MySQL 3.23.39 and 3.23.40 binaries on the same
machine?
If not, then I think this is a glibc problem!
Regards,
Monty
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Re[2]: Timezone problem.
Peter Zaitsev writes: Hello Sinisa, Tuesday, August 07, 2001, 4:48:56 PM, you wrote: 1) SUSE. Destributions does not have TZ variable set by default. And the idea is it worked quite well wothout it with .39 2) The strange thing is why settng TZ makes mysql to print correct timezone in variables but still produces the wrong time ? -- Best regards, Petermailto:[EMAIL PROTECTED] Hello Pjotr, We did not changed it recently. If you take a look at Changelog, you will see that nothing like that was introduced. mysqld.cc has the following code at the beginning : tzset(); and that is all. Regarding a strange thing when you set TZ that it changes time, this is /bin/sh doing by help of kernel, of course. Check it out. Change TZ and watch your time change. We truly can't do anything about it. We must use OS C API functions for such things. Anyway, all those functions we use are POSIX compliant. -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Timezone problem.
Peter Zaitsev writes: Hello mysql, It seems like you made an incomportable changes in 3.23.40 without taking a time to write a release note :( The mysql 3.23.39 used the system timezone by default: maindb:/spylog/mysql/logs # date Tue Aug 7 13:31:56 MSD 2001 | transaction_isolation | READ-COMMITTED | | timezone| MSD | | tmp_table_size | 4194304 Therefore MYSQL 3.23.40 does not determinate the timezone correctly: | | transaction_isolation | READ-COMMITTED | | timezone| Local time zone must be set--see´ manual page | | tmp_table_size | 4194304 | It uses GMT in this case which could dammage the data (as went in my case) The other thing is the manual does not contains much info about setting timezone - only option to safe_mysqld which exports TZ variable, which does not work: root 19380 1 0 13:43 pts/800:00:00 sh /usr/local/mysql/bin/safe_mysqld --mysqld=mysqld --user=mysql --pid-file=/spylog/db/mysqld.pid --timezone=MSD --datadir=/spylog/db It set's the timezone according to required value but date still bad: | transaction_isolation | READ-COMMITTED | | timezone| MSD | | tmp_table_size | 4194304 mysql select now(); +-+ | now() | +-+ | 2001-08-07 09:44:44 | +-+ 1 row in set (0.00 sec) Therefore date returns correct value. rat:/spylog/layers # date Tue Aug 7 13:47:05 MSD 2001 rat:/spylog/layers # Do you have any ideas about this ? How I can fix the problem ? Peter mailto:[EMAIL PROTECTED] Hi Pjotr, I just tested the above, and it worked just fine for me with 4.0. But I have noticed something. If I mess up my shell, it will mess up all programs started from it, including MySQL. We can not do anything about it ... If a shell that starts up MySQL does not have TZ set properly then there is not much we can do about it ... -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Timezone problem.
Hello Michael,
Tuesday, August 07, 2001, 10:20:18 PM, you wrote:
OK guys I think I've found the problem.
It seems like new innodb version (40b) does something bad with time.
I've tested 3 binaries
1) Plain .40 with normal GLIBC - OK
2) Plain .40 with patched GLIBC - OK
3) Plain .40 with new INNODB with doublewrite - This binary shiftes
the time.
Could you Heikke please check if you have something similar ?
MW Hi!
Peter == Peter Zaitsev [EMAIL PROTECTED] writes:
Peter Hello mysql,
Peter It seems like you made an incomportable changes in 3.23.40 without
Peter taking a time to write a release note :(
Peter The mysql 3.23.39 used the system timezone by default:
Peter maindb:/spylog/mysql/logs # date
Peter Tue Aug 7 13:31:56 MSD 2001
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| MSD
|
Peter | tmp_table_size | 4194304
Peter Therefore MYSQL 3.23.40 does not determinate the timezone correctly:
Peter |
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| Local time zone must be set--see´ manual
page
|
Peter | tmp_table_size | 4194304
|
MW Are you sure you are not starting mysqld differently ?
MW According to my knowing, we have not changed anything in timezone
MW usage in MySQL.
MW The name if the timezone mysqld displays is what we get from the
MW following call:
MW {
MW struct tm tm_tmp;
MW localtime_r(start_time,tm_tmp);
MW strmov(time_zone,tzname[tm_tmp.tm_isdst == 1 ? 1 : 0]);
MW }
MW I don't know why localtime_r() doesn't work in your case, but I would guess
MW something in your setup that has changed.
MW The only way to affect the timezone is to set the TZ variable before
MW starting mysqld/safe_mysqld or by starting safe_mysqld with the
MW --timezone= option.
Peter It uses GMT in this case which could dammage the data (as went in my
Peter case)
Peter The other thing is the manual does not contains much info about
Peter setting timezone - only option to safe_mysqld which exports TZ
Peter variable, which does not work:
Peter root 19380 1 0 13:43 pts/800:00:00 sh
/usr/local/mysql/bin/safe_mysqld --mysqld=mysqld --user=mysql
--pid-file=/spylog/db/mysqld.pid --timezone=MSD --datadir=/spylog/db
Peter It set's the timezone according to required value but date still bad:
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| MSD
|
Peter | tmp_table_size | 4194304
mysql select now();
Peter +-+
Peter | now() |
Peter +-+
Peter | 2001-08-07 09:44:44 |
Peter +-+
Peter 1 row in set (0.00 sec)
Peter Therefore date returns correct value.
Peter rat:/spylog/layers # date
Peter Tue Aug 7 13:47:05 MSD 2001
Peter rat:/spylog/layers #
Peter Do you have any ideas about this ? How I can fix the problem ?
MW Sorry, no ideas; It looks like there is some problem with your glibc
MW library.
MW Did you try the MySQL 3.23.39 and 3.23.40 binaries on the same
MW machine?
MW If not, then I think this is a glibc problem!
MW Regards,
MW Monty
--
Best regards,
Petermailto:[EMAIL PROTECTED]
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Timezone problem.
Hi!
No idea what is wrong. Below is the code which
prints the timestamp in InnoDB:
.
struct tm cal_tm;
struct tm* cal_tm_ptr;
time_t tm;
time(tm);
#ifdef HAVE_LOCALTIME_R
localtime_r(tm, cal_tm);
cal_tm_ptr = cal_tm;
#else
cal_tm_ptr = localtime(tm);
#endif
fprintf(file,%02d%02d%02d %2d:%02d:%02d,
cal_tm_ptr-tm_year % 100,
cal_tm_ptr-tm_mon+1,
cal_tm_ptr-tm_mday,
cal_tm_ptr-tm_hour,
cal_tm_ptr-tm_min,
cal_tm_ptr-tm_sec);
...
I tested 3.23.40b on our Linux computer and got the following:
heikki@donna:~/mysql-3.23.40/sql mysqld
010807 18:01:01 Warning: setrlimit couldn't increase number of open files
to mo
re than 1024
010807 18:01:01 Warning: Changed limits: max_connections: 250 table_cache:
382
010807 18:01:02 InnoDB: Started
010807 18:01:02 mysqld: Table 'mysql.func' doesn't exist
010807 18:01:02 Can't open mysql/func table
mysqld: ready for connections
mysql select now();
+-+
| now() |
+-+
| 2001-08-07 18:03:24 |
+-+
1 row in set (0.00 sec)
mysql
..
Any ideas anybody?
Regards,
Heikki
-Original Message-
From: Peter Zaitsev [EMAIL PROTECTED]
To: Michael Widenius [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED]
[EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday, August 07, 2001 5:41 PM
Subject: Re: Timezone problem.
Hello Michael,
Tuesday, August 07, 2001, 10:20:18 PM, you wrote:
OK guys I think I've found the problem.
It seems like new innodb version (40b) does something bad with time.
I've tested 3 binaries
1) Plain .40 with normal GLIBC - OK
2) Plain .40 with patched GLIBC - OK
3) Plain .40 with new INNODB with doublewrite - This binary shiftes
the time.
Could you Heikke please check if you have something similar ?
MW Hi!
Peter == Peter Zaitsev [EMAIL PROTECTED] writes:
Peter Hello mysql,
Peter It seems like you made an incomportable changes in 3.23.40
without
Peter taking a time to write a release note :(
Peter The mysql 3.23.39 used the system timezone by default:
Peter maindb:/spylog/mysql/logs # date
Peter Tue Aug 7 13:31:56 MSD 2001
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| MSD
|
Peter | tmp_table_size | 4194304
Peter Therefore MYSQL 3.23.40 does not determinate the timezone
correctly:
Peter |
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| Local time zone must be
set--see´ manual page
|
Peter | tmp_table_size | 4194304
|
MW Are you sure you are not starting mysqld differently ?
MW According to my knowing, we have not changed anything in timezone
MW usage in MySQL.
MW The name if the timezone mysqld displays is what we get from the
MW following call:
MW {
MW struct tm tm_tmp;
MW localtime_r(start_time,tm_tmp);
MW strmov(time_zone,tzname[tm_tmp.tm_isdst == 1 ? 1 : 0]);
MW }
MW I don't know why localtime_r() doesn't work in your case, but I would
guess
MW something in your setup that has changed.
MW The only way to affect the timezone is to set the TZ variable before
MW starting mysqld/safe_mysqld or by starting safe_mysqld with the
MW --timezone= option.
Peter It uses GMT in this case which could dammage the data (as went in
my
Peter case)
Peter The other thing is the manual does not contains much info about
Peter setting timezone - only option to safe_mysqld which exports TZ
Peter variable, which does not work:
Peter root 19380 1 0 13:43 pts/800:00:00 sh
/usr/local/mysql/bin/safe_mysqld --mysqld=mysqld --user=mysql --pid-file=/sp
ylog/db/mysqld.pid --timezone=MSD --datadir=/spylog/db
Peter It set's the timezone according to required value but date still
bad:
Peter | transaction_isolation | READ-COMMITTED
|
Peter | timezone| MSD
|
Peter | tmp_table_size | 4194304
mysql select now();
Peter +-+
Peter | now() |
Peter +-+
Peter | 2001-08-07 09:44:44 |
Peter +-+
Peter 1 row in set (0.00 sec)
Peter Therefore date returns correct value.
Peter rat:/spylog/layers # date
Peter Tue Aug 7 13:47:05 MSD 2001
Peter rat:/spylog/layers #
Peter Do you have any ideas about this ? How I can fix the problem ?
MW Sorry, no ideas; It looks like there is some problem with your glibc
MW library.
MW Did you try the MySQL 3.23.39 and 3.23.40 binaries on the same
MW machine?
MW If not, then I think this is a glibc problem!
MW Regards,
MW Monty
--
Best regards,
Petermailto:[EMAIL PROTECTED]
-
Before posting, please check:
http
Re: Timezone problem.
On Tuesday 07 August 2001 09:10, Heikki Tuuri wrote: Hi! No idea what is wrong. Below is the code which prints the timestamp in InnoDB: . struct tm cal_tm; struct tm* cal_tm_ptr; time_t tm; time(tm); #ifdef HAVE_LOCALTIME_R localtime_r(tm, cal_tm); cal_tm_ptr = cal_tm; #else cal_tm_ptr = localtime(tm); #endif fprintf(file,%02d%02d%02d %2d:%02d:%02d, cal_tm_ptr-tm_year % 100, cal_tm_ptr-tm_mon+1, cal_tm_ptr-tm_mday, cal_tm_ptr-tm_hour, cal_tm_ptr-tm_min, cal_tm_ptr-tm_sec); ... I tested 3.23.40b on our Linux computer and got the following: heikki@donna:~/mysql-3.23.40/sql mysqld 010807 18:01:01 Warning: setrlimit couldn't increase number of open files to mo re than 1024 010807 18:01:01 Warning: Changed limits: max_connections: 250 table_cache: 382 010807 18:01:02 InnoDB: Started 010807 18:01:02 mysqld: Table 'mysql.func' doesn't exist 010807 18:01:02 Can't open mysql/func table mysqld: ready for connections mysql select now(); +-+ | now() | +-+ | 2001-08-07 18:03:24 | +-+ 1 row in set (0.00 sec) mysql .. Any ideas anybody? Peter - can you strace the bad mysqld and the good one on startup and compare? Also compile the bad one with debugging, set a breakpoint in getenv() and backtrace every time it stops on both binaries. -- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA ___/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
