Adam Smith

Gordon Burditt wrote:

>>FreeBSD / UNIX platform, MySQL ver.4.0.16
>>Prob. of growing /tmp file, solved by introducing a cron job to clean up
>>the folder intermittently. Prob.solve but new one created - mysql socket
>>wiped out.
>
>
> So don't delete *SOCKETS* with your cron job.

Point taken - in full agreement,
Changed location of socket to its own dedicated location ==>
/usr/local/var/mysql

>>Could not restart the server with all the standard methods.
>>Complained of other running processes. Killed the orphaned processes
>>runining. But still can't restart.
>
>
> What error message do you get? If safe_mysqld is running, when you
> killed mysqld, it may have restarted automatically (and should have
> re-created the socket).

Error message
ERROR 2002: Can't connect to local MySQL server through socket
'/usr/local/var/mysql' (38)
current message becaused of changes made to /etc/my.cnf file for new
location. Identical message when the SNAFU occurrred, but with /tmp instead


>>So can't do a dump or any other back up action, so created a tar file of
>>the data etc. Now I wanted to try an upgrade to a newer version but
>>concerned about ability to restore data from the tarball.
>
>
> Assuming that the data was not being actively changed when you made
> the tarball (likely if the server wasn't working), this should
> not be a problem. Be sure to restore ownership and file permissions.
>
Likely or unlikely? Shouldn't all the file permission be retained in
tarball, I do expect redo GRANT PRIVILLEGES
>
>>Does anyone have any idea of how can effect a restart before running to
>>do an Upgrade?
>
>
> Kill off safe_mysqld (if it's running), then mysqld.
mysqld killed,
>
> Gordon L. Burditt