I patched mysqld_safe directly based on Mario's diff (and replace the "& wait" that I had removed). This fixes the problem for me.
I also looked in the logs to see what was happening on boot with the change and I noticed: May 10 11:02:55 willvo sshd[2981]: Received signal 15; terminating. May 10 11:02:55 willvo ntpd[3721]: ntpd exiting on signal 15 but both seem to be running. Postfix also reloads its configuration. Is someone (upstart?) telling all daemons to reload their configs for some reason? Is there an easy way to track down who sends a signal? It seems there are two problems here - the signal being sent, and mysqld_safe poor response to receiving it. It would be nice to get to the bottom of each of them. ** Description changed: --Impact-- I'm running mythtv on jaunty with mysql-server-5.0 version 5.1.30really5.0.75-0ubuntu5. During boot mysql starts, then mythtv starts, then mysql restarts and mythtv gets confused. This is caused by some portions of a debian patch that is applied on top of MySQL. It has not been accepted yet at upstream MySQL. The MySQL server is receiving a SIGHUP which the behavior is changed because of the debian patch. Here are some relevant syslog sections: Feb 8 12:35:07 willvo mysqld_safe[3668]: started Feb 8 12:35:08 willvo mysqld[3671]: 090208 12:35:08 InnoDB: Started; log sequence number 0 43655 Feb 8 12:35:08 willvo mysqld[3671]: 090208 12:35:08 [Note] /usr/sbin/mysqld: ready for connections. Feb 8 12:35:08 willvo mysqld[3671]: Version: '5.0.75-0ubuntu5' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) Feb 8 12:35:08 willvo /etc/mysql/debian-start[3710]: Upgrading MySQL tables if necessary. Feb 8 12:35:08 willvo /etc/mysql/debian-start[3713]: Looking for 'mysql' as: /usr/bin/mysql Feb 8 12:35:08 willvo /etc/mysql/debian-start[3713]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck Feb 8 12:35:08 willvo /etc/mysql/debian-start[3713]: This installation of MySQL is already upgraded to 5.0.75, use --force if you still need to run mysql_upgrade Feb 8 12:35:08 willvo /etc/mysql/debian-start[3720]: Checking for insecure root accounts. Feb 8 12:35:08 willvo /etc/mysql/debian-start[3724]: Triggering myisam-recover for all MyISAM tables Feb 8 12:35:13 willvo mythtv-backend[4560]: Started mythtv-backend Feb 8 12:35:16 willvo mysqld_safe[5212]: Number of processes running now: 1 Feb 8 12:35:16 willvo mysqld_safe[5223]: mysqld process hanging, pid 3670 - killed Feb 8 12:35:16 willvo mysqld_safe[5227]: restarted Feb 8 12:35:16 willvo mysqld[5231]: 090208 12:35:16 InnoDB: Started; log sequence number 0 43655 Feb 8 12:35:17 willvo mysqld[5231]: 090208 12:35:17 [Note] /usr/sbin/mysqld: ready for connections. Feb 8 12:35:17 willvo mysqld[5231]: Version: '5.0.75-0ubuntu5' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) Note that mysqld_safe is finds one mysqld process still running after it is supposed to have crashed. mysqld_safe then kills that process and starts another. This only seems to happen once during boot - it doesn't keep restarting mysqld in normal use. --Addressing-- This has *not* yet been addressed in the karmic branch, but it has been verified that a PPA resolve the problem. MySQL hasn't changed yet in karmic, so this can easily be brought to karmic if viewed to properly solve the problem. - --Test Case-- + --Test Case - Myth To reproduce this, you can boot up off of a fresh install of Mythbuntu 9.04 (which includes MySQL and mythtv-backend preinstalled). Check /var/log/syslog and you will see errors regarding mysql getting restarted because of a hanging process. Depending on the speed of your system, this may or may not cause problems with mythtv-backend because of the race condition inherent in this problem. + + -- Test Case - non-Myth + sudo killall -HUP mysqld_safe # should cause mysql to reload its config, but causes it to restart instead. --Regression Potential-- This type of patch has implications if users were dependent on the behavior of this debian/ubuntu specific patch to issue a mysql refresh via a SIGHUP. -- mysqld_safe thinks mysqld has crashed when it hasn't https://bugs.launchpad.net/bugs/326768 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
