Check the machine-hostname.err file when you manually try and
start MySQL.
Provided that you have mysql_enable="YES" in /etc/rc.conf you
should be able
to manually attempt to start with /usr/local/etc/rc.d/mysql-server
start (it
seems to work reliably when you type out the entire command path-
wise).
Note that if somehow permissions on the my.cnf file got changed
MySQL won't
start if my.cnf is world writable. Check for stale PID and
sockets. Normally
these shouldn't be a problem as a startup will just overwrite
them. Check
these to eliminate any wonkiness, e.g. some permission change
isn't allowing
for MySQL to wipe the old ones.
The whateverthehostname.err log and possibly /var/log/messages
might give
some clue for what's going on. If the database files are corrupt
just clean
them out and replace with a backup done with dump. Ensure the /var/
db/mysql
tree is chowned mysql:mysql. If you had to install/reinstall from
ports the
install should have created the appropriate uid/gid accounts.
Check and see
if these are missing.
At any rate I wish you the best of luck. Now that you can SSH in
you can
probably fix it up.
Okay, so my new database server is running with backup data and I am
trying to salvage the old database, or what's left of it.
Unfortunately, it seems like what's left of it, is not much.
the /var/db/mysql directory tree is now a file:
qu# ls -l /var/db/mysql
-rwx------ 2 mysql wheel 1024 Jul 5 2008 /var/db/mysql
The situation looks hopeless to me. Is it?
Another question: given that the file system took a major hit, should
I try to fix it, or just do a clean install? I'm leaning towards the
clean install since I've been meaning to upgrade this machine to 7.1
anyway.
Is there anyway to fix the file system, reliably? fsck doesn't seem
to be able to solve all the problems.
-- John
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"