Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162123 - Timeout error occurred trying to start MySQL Daemon (Table 'mysql.host' doesn't exist).
Summary: Timeout error occurred trying to start MySQL Daemon (Table 'mysql.host' doesn...
Keywords:
Status: CLOSED DUPLICATE of bug 141062
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-30 04:56 UTC by Brian Woo
Modified: 2013-07-03 03:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-25 01:02:04 UTC


Attachments (Terms of Use)

Description Brian Woo 2005-06-30 04:56:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
MySQL fails to start:

[root@ashley ~]# /etc/init.d/mysqld start
Timeout error occurred trying to start MySQL Daemon.
Starting MySQL:                                            [FAILED]

And the following is in the /var/log/mysqld.log:

[root@ashley ~]# tail -f /var/log/mysqld.log 
to the [mysqld] section of init parameters in your my.cnf
or my.ini. If you want to use InnoDB tables, add to the [mysqld]
section, for example,
innodb_data_file_path = ibdata1:10M:autoextend
But to get good performance you should adjust for your hardware
the InnoDB startup options listed in section 2 at
http://www.innodb.com/ibman.html
050629 22:53:59  /usr/libexec/mysqld: Table 'mysql.host' doesn't exist
050629 22:53:59  mysqld ended



Version-Release number of selected component (if applicable):
mysql-server-3.23.58-16.FC3.1

How reproducible:
Always

Steps to Reproduce:
1. /etc/init.d/mysqld start
2.
3.
  

Actual Results:  Timeout error occurred trying to start MySQL Daemon.
Starting MySQL:                                            [FAILED]


Expected Results:  MySQL should have started up OK

Additional info:

Comment 1 Tom Lane 2005-06-30 14:41:37 UTC
I think this is a duplicate of bug #141062, although that was supposedly worked
around in mysql-3.23.58-14.  Did you perhaps update from an earlier package
after having the database startup failure?  If so, I think the broken
installation is still there.  Try rm -rf /var/lib/mysql/* and then see if it
will start.  Also make sure you are using a reasonably up-to-date
selinux-policy-targeted package.

Comment 2 Brian Woo 2005-07-01 04:34:10 UTC
OK, I have removed everything in /var/lib/mysql.

[root@ashley ~]# /etc/init.d/mysqld start
Initializing MySQL database:                               [  OK  ]
Timeout error occurred trying to start MySQL Daemon.
Starting MySQL:                                            [FAILED]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This time, tail -f /var/log/mysqld.log returns:

050630 22:31:03  mysqld started
Cannot initialize InnoDB as 'innodb_data_file_path' is not set.
If you do not want to use transactional InnoDB tables, add a line
skip-innodb
to the [mysqld] section of init parameters in your my.cnf
or my.ini. If you want to use InnoDB tables, add to the [mysqld]
section, for example,
innodb_data_file_path = ibdata1:10M:autoextend
But to get good performance you should adjust for your hardware
the InnoDB startup options listed in section 2 at
http://www.innodb.com/ibman.html
/usr/libexec/mysqld: ready for connections

And, mysqld seems to be running... 
ps -ef | grep mysql
root      6804     1  0 22:22 pts/3    00:00:00 /bin/sh /usr/bin/safe_mysqld
--defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid
mysql     6832  6804  0 22:22 pts/3    00:00:00 /usr/libexec/mysqld
--defaults-file=/etc/my.cnf --basedir=/usr --datadir=/var/lib/mysql --user=mysql
--pid-file=/var/run/mysqld/mysqld.pid --skip-locking

It's interesting that the startup script still fails to run although the daemon
is actually running ok.  And this is a brand new install of MySQL, not from an
upgrade.

Here is my system configurations:
[bwoo@ashley ~]$ rpm -q mysql
mysql-3.23.58-16.FC3.1
[bwoo@ashley ~]$ rpm -q selinux-policy-targeted
selinux-policy-targeted-1.17.30-3.15

Thanks,
Brian

Comment 3 Mark Nienberg 2005-07-09 00:00:18 UTC
I have the same symptoms on Fedora Core 1, if that helps.  But as you say, the
daemon does actually start and everything is fine after that so I haven't been
worrying about it.

[root@gingham mysql]# service mysqld start
Timeout error occurred trying to start MySQL Daemon.
Starting MySQL:                                            [FAILED]

[root@gingham mysql]# service mysqld status
mysqld (pid 30187) is running...

Comment 4 Tom Lane 2005-07-11 16:38:46 UTC
The start script basically does this to see if MySQL is up yet:

/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER ping
echo $?

What happens if you try that by hand?

Comment 5 Mark Nienberg 2005-07-11 16:49:33 UTC
In Fedora Core 1 the command being used is:

/usr/bin/mysqladmin ping

I found this website:
http://www.siliconvalleyccie.com/linux-adv/mysql.htm#_Toc105342556

and followed it's directions to add "-u $RANDOM" to the ping command, and now
everything works just great.  I guess the username part was added since FC1.
Note that the problem does not occur at bootup, just on restarts of the daemon.

Comment 6 Timon 2005-10-24 01:51:33 UTC
i think i found a problem

[root@child ~]# diff ./mysqld /etc/init.d/mysqld
81c81
<               RESPONSE=`/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER ping 2>&1` &&
break
---
>               RESPONSE=`/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER -S
$socketfile ping 2>&1` && break


Comment 7 Brian Woo 2005-10-24 01:54:23 UTC
It works after I cleaned the mysql directory under /var/lib... but thanks guys.

Comment 8 Tom Lane 2005-10-25 01:02:04 UTC
OK, in that case I'm going to assume this is the same problem as bug #141062.
Thanks for getting back on that.

*** This bug has been marked as a duplicate of 141062 ***


Note You need to log in before you can comment on or make changes to this bug.