mysqld startup issue
Michael Powell
nightrecon at hotmail.com
Mon Jun 11 19:26:22 UTC 2012
Gary Aitken wrote:
> I've done the following after having a running system with a running mysql
> on it:
>
> moved user accounts, although no logical move:
> /usr/home/foo was => /hd1/foo
> now
> /usr/home => /hd1/home and /hd1/foo is now /hd1/home/foo
> repartitioned the SSD and restored the system from a dump taken prior to
> repartitioning. removed all ports and reinstalled them
Although I have not really experienced much in the way of toruble with this,
as my systems are not very 'busy', it can be better to boot from a LiveCD to
do the dump because no files are open for writing and all your MySQL files
will be static. No possibility of change during the dump. That being said, I
have done dumps from live filesystems and have been able to restore them many
times. Forewarned is forearmed.
> Unfortunately, mysqld won't start:
>
> 120611 10:55:52 [Warning] Can't create test file
> /var/db/mysql/breakaway.lower-test 120611 10:55:52 [Warning] Can't create
> test file /var/db/mysql/breakaway.lower-test mysqld: Table 'mysql.plugin'
> doesn't exist 120611 10:55:52 [ERROR] Can't open the mysql.plugin table.
> Please run mysql_upgrade to create it. 120611 10:55:52 InnoDB: The InnoDB
> memory heap is disabled 120611 10:55:52 InnoDB: Mutexes and rw_locks use
> GCC atomic builtins 120611 10:55:52 InnoDB: Compressed tables use zlib
> 1.2.5 120611 10:55:52 InnoDB: Initializing buffer pool, size = 128.0M
> 120611 10:55:52 InnoDB: Completed initialization of buffer pool
> 120611 10:55:52 InnoDB: Operating system error number 13 in a file
> operation. InnoDB: The error means mysqld does not have the access rights
> to InnoDB: the directory.
> InnoDB: File name ./ibdata1
> InnoDB: File operation call: 'create'.
> InnoDB: Cannot continue operation.
I have had trouble before when playing with these files outside of MySQL.
What happens is if they get out of sync with the index they will become
totally unusable. There are recovery procedures in the docs, but if memory
serves it was just easier to delete the ib_logfile(x) and allow MySQL to
recreate from scratch. Probably not central to your problem, per se, just
thought I'd make mention in passing. I would recommend consulting the docs
on this subject of index/logfile recovery prior to any blindly mucking about.
> Running mysqld --verbose shows:
>
> basedir /usr/local
> general-log-file /var/db/mysql/breakaway.log
Usually this file is of the form <FQDN hostname>.err
> ls -aol /usr/local/libexec/mysqld
> -rwxr-xr-x 1 root wheel - 9558944 Jun 11 10:40
mine shows:
testbed# ls -aol /usr/local/libexec/mysqld
-r-xr-xr-x 1 root wheel - 6694672 May 10 11:16 /usr/local/libexec/mysqld
> /usr/local/libexec/mysqld ls -dl /var/db/mysql
> drwxr-xr-x 2 mysql mysql 512 Jun 11 10:31 /var/db/mysql
and my /var/db shows the below for the mysql directory:
drwxr-xr-x 21 mysql mysql 3072 Jun 4 12:09 mysql
> cd /
> find . -ls | grep my.cnf
>
> shows nothing.
>
> This looks like some kind of access / setuid problem, but I'm not sure
> what. Suggestions?
Beginning with the mysql_enable="YES" I have found when using rc startup
scripts you need the entire path: /usr/local/etc/rc.d/mysql-server <blah>
Moving on to permissions. Don't recall specifically, but if memory serves
during the port install/reinstall there is a choice displayed to keep/use a
previous mysql:mysql user and group combo. Perhaps an incorrect choice
allows for deleting this - never known as I have always chosen to not delete
but to reuse the old accounts.
Nevertheless, in /etc/group there should be an entry like this:
mysql:*:88:
And the user account as shown by vipw will look like this:
mysql:*:88:88::0:0:MySQL Daemon:/nonexistent:/sbin/nologin
These should both be handled 'automagically' by the ports build system. You
can cd to /var/db and do a chown -R mysql:mysql mysql if you want to ensure
file ownership is correct, provided the above referenced entries are in
place.
The ports these days will place the my.cnf file in /usr/local/etc instead of
the old location of /var/db/mysql. I believe it is still supposed to fall
back to /var/db/mysql if not found. One thing I found out when I was having
a problem was that MySQL will not source this file if permissions on it are
world read/write. Not exactly sure what it's supposed to be (I'm sure this
can be found in the docs) but I've just chmod'd it 444 when I'm done with
edits.
I do not grasp why any movement of your home directories mentioned at the
top would matter to MySQL. I suspect something more to do with the "removed
all ports and reinstalled them" part. The mysql.plugin tells you to run an
update script to update schema. There is more info on this in the docs.
Don't believe that is the main problem. I suspect either you have InnoDB
configs not being read in my.cnf or that InnoDB logfiles or index got
corrupted by the backup process. If you have MyIsam tables and you comment
out in my.cnf the activation (once you get my.cnf being read and used) of
the InnoDB engine and now MySQL starts then I would focus on the InnoDB
corruption issue.
-Mike
More information about the freebsd-questions
mailing list