> On Sun, 13 Mar 2005, Bob Brennan wrote: > > > My remaining problems are: > > 1) how to open up *safe* relays for legitimate users, the preferred > > method being pop-b4-smtp because it is widely supported. > > 2) how to get mysql up and running again. The log-reported missing was > > in fact there and valid, even when replaced by a backup. I am > > currently trying uninstalls and reinstalls but not having a lot of > > luck. Most of my sites are dynamic and heavily rely on MySql. > > I recall that the problem you reported was that, when you typed "service > mysqld start", you got a message about "Timeout error...". When this > happens, what does "service mysqld status" report? > > Depending on what you've done to your configuration, this may not mean > that mysqld actually failed. What failed is a little piece of the > startup script that pings the server until it comes up: > > /usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER ping > > The failure message occurs if the ping fails after 10 tries (1/sec). > > The initial mysql database installed with the mysql-server RPM has two > users defined. One is "root" and the other is "". If you removed "" or > set a password for it, then the ping will fail and you'll get the message, > even if if the server started successfully. > > I'm no MySQL expert, but if you are concerned about a user with no > password, I'll just note that that user also has no privileges. That's what I thought it was too Matthew - since the hosts.frm file contains the users and passwords. So I copied all hosts.* files from a known good working installation and it made no difference. Putting back the old files I noticed the log error was specifically "could not *read* hosts.frm" even though it was obviously there and obviously valid. I tested my theory on the good working machine by renaming hosts.frm - mysqld would not start but the error was "could not *find* hosts.frm". Aha! So I started thinking it has to do with access rights, disabled SELinux, and hey presto mysqld works again. It is obviously an Up2Date change to SELinux that didn't take effect until I rebooted, and now I need to narrow down the policy in question in order to re-enable SELinux without crippling my databases. Thanks for the suggestions - it put me in the right direction. bob
