I had a power outage. Now MySQL's lock file won't go away. What do you suggest?

I do freelance IT consulting for various clients, both in Toronto, Canada, and worldwide.

A client recently experienced a power failure. Now they've been having various problems with a Slackware 12.0.0 machine which also acts as a DNS server.

One problem is that they can't log into phpMyAdmin.

I tried stopping and restarting MySQL. But even when MySQL is stopped, the lock file stays around.

jasonspiro@cybertron:~$ sudo /etc/init.d/mysql stop 
Shutting down MySQL. SUCCESS! 
jasonspiro@cybertron:~$ sudo /etc/init.d/mysql stop
 ERROR! MySQL manager or server PID file could not be found!
jasonspiro@cybertron:~$ sudo /etc/init.d/mysql status
 ERROR! MySQL is not running, but lock exists
jasonspiro@cybertron:~$ ls -l /var/lock/subsys/mysql 
-rw-r--r-- 1 root root 0 2012-07-05 16:18 /var/lock/subsys/mysql

Why is MySQL's lock file hanging around despite the fact that MySQL isn't running?

Can I simply stop MySQL, delete the lock file, and start MySQL again?

Are there any other steps that I should take next, or nothing?

EDIT: A while after I asked this question, I noticed that the way MySQL is installed on this machine seems wonky. Also, I found out that the /etc/init.d/mysql script I found on this machine always creates a lock file when it starts MySQL and never deletes the file when it stops MySQL. So this question turns out to be irrelevant to me. Thank you, but I don't need more answers to this question.


Do: ls -al /var/lock/subsys

Look for mysql.pid. Remove that. Also remove mysql.sock if it exists.

If all else fails, [as root] use updatedb ; locate <filename>. This is your friend in situations like this.

Try restarting MySQL using the init script. If that doesn't work, restore to a database checkpoint from an acceptable backup of the database.

If no database backups exist: Make a clone of this disk with dd ASAP. You may need to use some hard-core recovery procedures. Even if the MySQL service starts back up again, save the best known-good backup for a while, just in case.