Having chroot Problems with MySQL

[Mark Phillips]

On Wed, Jun 2, 2010 at 9:47 AM, Matt Graham <danceswithcrows at usa.net> wrote:

> From: Mark Phillips <mark at phillipsmarketing.biz>
> > On Wed, Jun 2, 2010 at 8:41 AM, Matt Graham <danceswithcrows at usa.net>
> wrote:
> >> The post-install script should've chowned the mysql log files to mysql.
>
> [[It did, /etc/passwd and /etc/group are OK in the chroot]]
>
> >>> It looks like you have all binaries & libraries installed, but some
> >>> post-installation tasks have failed to complete.  You might try
> >>> starting mysql yourself, and see if that gives you any more clues
> >>> about what's wrong.
> >> Yeah.  And if that gives you no useful info, there's always the nuclear
> >> option:  "strace -ff /etc/init.d/mysql start > strace.log 2>&1"
> > write(1, "\7/usr/bin/mysqladmin: connect to "..., 62)
> > write(1, "error: 'Can't connect to local My"..., 94)
> > write(1, "Check that mysqld is running and "..., 88)
>
> Translation:  The local socket (probably in /var/run/mysqld/mysqld.sock )
> doesn't exist for some reason.  Lots of things, including the Debian start
> script, like to have that socket there so they can talk to mysqld.  Make
> sure
> the my.cnf file says where the socket should be, and make sure that
> /var/run/mysqld/ in the chroot is owned by mysql .
>

my.cnf in the chroot is just the stock my.cnf from the install. It says -
socket          = /var/run/mysqld/mysqld.sock

Does it have to read
socket          = /opt/chroot/lenny-i386/var/run/mysqld/mysqld.sock

the full path to the chroot var/mysqld? I thought everything in the chroot
only knew about the chroot and could not look past it. So, if anyone (root,
mysql, etc.) within the chroot went to /var/run it would be the /var/run in
the chroot and not the /var/run in the bigger world of 64 bits on squeeze.
Is this correct, or do I need to change paths within the my.cnf to reflect
the global path of /opt/chroot/lenny-i386?

>
> > stat64("/usr/local/sbin/logger", 0xfffa2798) = -1 ENOENT
> > stat64("/usr/local/bin/logger", 0xfffa2798) = -1 ENOENT
> > stat64("/usr/sbin/logger", 0xfffa2798) = -1 ENOENT
> > stat64("/usr/bin/logger" = 0
>
> So logger exists in /usr/bin/ , which makes me think it's trying to use
> logger
> to write to some sort of syslog daemon at some point.  I would install a
> syslog daemon (syslog-ng or metalog or something....) in the chroot and run
> it
> just to see if other junk is going on in there.  At the very least, you'd
> probably get some junk in various logfiles, which would probably help
> diagnose
> whatever other problems might crop up.
>

I think the logger setup is correct. When I search for logger on my
computer, there are only 2 - the chroot and the main system
/opt/chroot/lenny-i386/usr/bin/logger
/usr/bin/logger

both are in bin/logger.

>
> > connect(1, {sa_family=AF_FILE, path="/dev/log"...}, 110) =
> > -1 ENOENT (No such file or directory)
>
> I think that socket is maintained by syslog.
>
> > I mounted /proc and /dev/pts from the 64 bit system to the chroot. Do I
> need
> > to do that for other file systems, or was that wrong? Too many different
> > chroot 'recipes" out there!
>
> You need /proc/ and /dev/pts mounted.  That should be OK.
>
> >> make sure you don't have the old ib_logfile* files sitting in the data
> dir.
> > No tables copied over from 64 bit system.
>
> That makes things a bit easier.
>
> --
> Matt G / Dances With Crows
> The Crow202 Blog:  http://crow202.org/wordpress/
> There is no Darkness in Eternity/But only Light too dim for us to see
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20100602/67642728/attachment.htm>