| Bug #14049 | Message "Timeout error occurred trying to start MySQL Daemon" On Daemon Restart | ||
|---|---|---|---|
| Submitted: | 15 Oct 2005 16:30 | Modified: | 17 Oct 2005 13:57 |
| Reporter: | David Ashley | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 4.1.12.3 | OS: | Linux (RHEL4) |
| Assigned to: | CPU Architecture: | Any | |
[16 Oct 2005 9:22]
Valeriy Kravchuk
Thank you for a problem report and proposed fix. Please, send the appropriate part of the error log for analysis. Do you use InnoDB tables? Do you have active connections when trying to retstart and getting this message?
[16 Oct 2005 15:54]
David Ashley
---------- Error Logs: Error log excerpts below: 051015 12:38:40 mysqld started 051015 12:38:41 InnoDB: Started; log sequence number 0 43634 051015 12:38:41 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them /usr/libexec/mysqld: ready for connections. Version: '4.1.12' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 051015 12:53:29 [Note] /usr/libexec/mysqld: Normal shutdown 051015 12:53:29 InnoDB: Starting shutdown... 051015 12:53:31 InnoDB: Shutdown completed; log sequence number 0 43634 051015 12:53:31 [Note] /usr/libexec/mysqld: Shutdown complete 051015 12:53:31 mysqld ended These messages repeat every time the daemon is stopped and started. No other errors or anomalous messages. BTW, in my /var/log directory, there is only the file mysqld.log file (no separate error file, as would be present with some products). --------- Use of InnoDB tables: I have no idea what an InnoDB table is. I use Bugzilla 2.16.7, and my best guess is that it does not configure the MySQL database for anything unusual or very performance related. I don't think they are used, but I'm not sure. If there is any info I can get you about the database design (i.e. "show ..."), please let me know. ----------- Active Connections: I don't think so. MySQL is used only from web pages (Perl scripts) to support Bugzilla. My understanding of these things is that the database connection is closed after the web page has finished loading (Perl script has finished executing). Additionally, since I'm setting up a new server and the web content is secured by browser client certificates, the probability of hits on the web pages without my knowledge is zero. No active connections, I believe.
[17 Oct 2005 10:10]
Valeriy Kravchuk
Thank you for the additional information. From your log: 051015 12:53:29 InnoDB: Starting shutdown... 051015 12:53:31 InnoDB: Shutdown completed; log sequence number 0 43634 051015 12:53:31 [Note] /usr/libexec/mysqld: Shutdown complete we can see, that InnoDB storage engine is used, and it really needs 2-3 seconds for proper shutdown. I think, you can still work with your change to the script, but I have to check the latest version of it, because that simple kill looks incorrect for me. I'd better wait while the server process exist.
[17 Oct 2005 13:57]
Valeriy Kravchuk
Thank you for taking the time to report a problem. Unfortunately
you are not using a current version of the product your reported a
problem with -- the problem might already be fixed. Please download
a new version from http://www.mysql.com/downloads/
If you are able to reproduce the bug with one of the latest versions,
please change the version on this bug report to the version you
tested and change the status back to "Open". Again, thank you for
your continued support of MySQL.
Additional info:
The problem you reported about was solved. I've just installed 4.1.14 RPM, and look how the /etc/rc.d/init.d/mysql file was changed:
'stop')
# Stop daemon. We use a signal here to avoid having to know the
# root password.
if test -s "$pid_file"
then
mysqld_pid=`cat $pid_file`
echo $echo_n "Shutting down MySQL"
kill $mysqld_pid
# mysqld should remove the pid_file when it exits, so wait for it.
wait_for_pid removed
# delete lock for RedHat / SuSE
if test -f /var/lock/subsys/mysql
then
rm -f /var/lock/subsys/mysql
fi
else
log_failure_msg "MySQL PID file could not be found!"
fi
;;
So, it is waiting for a real MySQL shutdown now. Please, upgrade to 4.1.14.
[17 Oct 2005 14:02]
David Ashley
Just one final question then ... and this may be documented somewhere ... I'm a Red Hat Enterprise Linux user ... I normally use a command like: up2date --dry-run mysql to see if there are any updates available. What is the propagation process from MySQL to RedHat ... how long will it take for RedHat to get the release you mention ...??? Thanks, Dave
Description: When executing: /etc/rc.d/init.d/mysqld restart, get the message: "Timeout error occurred trying to start MySQL Daemon." Daemon is in fact not started (unlike earlier versions of a similar problem). How to repeat: Not sure if can do it out of the box. In my case, I tar'd in databases (including "mysql") from another server. Logs show messages about missing leap seconds table or field. The fact that I have this problem and that I dragged in other databases (by physically moving them to mysql's area) may be somehow correlated. When daemon is up, mysql works fine. Trouble is starting it. With my setup, about 90% of the time restarting, get the message and no daemon start. Suggested fix: The problem goes away if I modify the startup script to include an extra "sleep" statement as shown below. Not sure why this should be delay-related, but the extra sleep does the trick. stop(){ /bin/kill `cat "$mypidfile" 2>/dev/null ` >/dev/null 2>&1 ret=$? if [ $ret -eq 0 ]; then sleep 2 rm -f /var/lock/subsys/mysqld rm -f "$socketfile" action $"Stopping $prog: " /bin/true else action $"Stopping $prog: " /bin/false fi sleep 5 #This is the statement I added. Value of 2 works fine, but #overkill to be sure. Not sure if value of 1 works (didn't try). return $ret }