Re: chroot in MySQL 5.0

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Gleb, Thanks for the answer. I was hoping to use the mysql.server script that ships with MySQL to start the database, which it seems You are not doing. I think the script is the core of my problem. I guess i'll have to give up on the scrip

chroot in MySQL 5.0

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi all! I had chroot working under 3.23 and 4.x, although it was always rather kludgy. Under 5.0 i can't get it to work to save my life. I start MySQL with the mysql.server script that is included in 5.0. It seems that no matter how i set

Re: chroot() and 3.23.54

Just saw the announcement for 3.23.54a, and that it fixes the bug in safe_mysqld that i mentioned in the postscript to my last mail. Sorry. I was in the middle of building 3.23.54a when i wrote my last mail, and i didn't see anything in the changelog that indicated that bug. -& -- GPG key /

Re: chroot() in 3.23.54

Sergei, Forgive my ignorance, but i've been thinking about this. Isn't it impossible to get it to work with the system calls i listed from strace? To repeat: chdir("/usr/local/var/mysql/") = 0 chroot("/chroot/mysql") = 0 chdir("/") = 0 open(

chroot() in 3.23.54

Hi everyone, First off, please include my personal e-mail address in any responses, as i am not subscribed to the list. I run MySQL with the chroot option. Up until 3.23.54, it worked fine. 3.23.54 changed the ordering in which some files were accessed (before or after chroot()), which messed

LOAD DATA, \N, and auto_increment

To Whom it May Concern, I sincerely doubt it's relevant, but i'm running MySQL 3.23.52 on Linux 2.4.18 (RedHat build 5). Client and server are on the same machine and communicate via a Unix domain socket. Perhaps it is a conscious decision, but it would seem an odd one: When usi