Server start / restart

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. 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.

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.

Does anyone have any idea of how can effect a restart before running to
do an Upgrade?

Thanks

"Adam Smith" <adamsmith@econ.com> wrote in message
news:DYCdnaI-v4hSKUrenZ2dnUVZ_sKdnZ2d@speakeasy.net...
> Does anyone have any idea of how can effect a restart before running to
> do an Upgrade?

Try rebooting the FreeBSD server host.

Regards,
Bill K.

>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.

>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).

>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.

>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.

Gordon L. Burditt

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

>>>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

It's still probably a bad idea to delete *sockets* out of /tmp unless
you have a problem with *sockets* cluttering up /tmp. If you're using
find(1) it's easy to limit it like this.

Are you *sure* you put the socket there? /usr/local/var/mysql seems
like it would be a *directory*, not a socket.

>>>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)

perror 38 gives 'Socket operation on non-socket'.
Are you *sure* your socket is /usr/local/var/mysql, not
/usr/local/var/mysql/mysql.sock or something like that?

>current message becaused of changes made to /etc/my.cnf file for new
>location. Identical message when the SNAFU occurrred, but with /tmp instead

Gordon L. Burditt

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
>
>
> It's still probably a bad idea to delete *sockets* out of /tmp unless
> you have a problem with *sockets* cluttering up /tmp. If you're using
> find(1) it's easy to limit it like this.
>
Well not *sockets* but many session and temp files, so a rm * in the
cron file removed it

> Are you *sure* you put the socket there? /usr/local/var/mysql seems
> like it would be a *directory*, not a socket.
>
Yes, I am asumming that it needed the absolute path to the socket
directory rather than to the socket itself. Although, I changed this in
the /etc/my.cnf file and later did a compilation to vers 5.0.18
Here is the config used.

../configure CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors
-fno-exceptions -fno-rtti" --prefix=/usr/local/mysql --enable-assembler
--enable-thread-safe-client --enable-local-infile
--with-unix-socket-path=/usr/local/var/mysql --with-mysqld-user=mysql
--with-openssl --with-big-tables --with-archive-storage-engine
--with-csv-storage-engine --localstatedir=/usr/db/mysql

**** "--with-unix-socket-path" ??? led to the directory assumption

Anyway used both approaches, but neiher solved the problem




Error!!!???

On Running
mysql_install_db ==>

Neither host 'econn' and 'localhost' could not be looked up with
/usr/local/bin/resolveip
Please configure the 'hostname' command to return a correct hostname.
If you want to solve this at a later stage, restart this script with
the --force option

but the hostname and at the very least localhost is OK they are set in
the /etc/rc.conf and /etc/hosts files

[Caveat - the hostname entry has the domain extension '*.com',
hostname -s removes the extension]

so I used the --force option then
mach1# pwd
/usr/local/mysql/bin
mach1# mysqld_safe &
[1] 3213
mach1# Starting mysqld daemon with databases from /var/db/mysql
060126 06:42:01 mysqld ended
Then tried
mach1# mysqladmin version
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/usr/local/var/mysql' (38)'
Check that mysqld is running and that the socket:
'/usr/local/var/mysql' exists!

It does exist w/ permissons of drwxrwxrwt

Any suggestions?


>
>>>>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)
>
>
> perror 38 gives 'Socket operation on non-socket'.
> Are you *sure* your socket is /usr/local/var/mysql, not
> /usr/local/var/mysql/mysql.sock or something like that?
>
>
>>current message becaused of changes made to /etc/my.cnf file for new
>>location. Identical message when the SNAFU occurrred, but with /tmp instead
>
>
> Gordon L. Burditt

>Well not *sockets* but many session and temp files, so a rm * in the
>cron file removed it

I suggest you *NOT* remove *sockets* in /tmp. Don't do "rm *"
(which will fail with "arguments too long" if it gets too cluttered
up too fast anyway).

>On Running
>mysql_install_db ==>
>
>Neither host 'econn' and 'localhost' could not be looked up with
>/usr/local/bin/resolveip
>Please configure the 'hostname' command to return a correct hostname.
>If you want to solve this at a later stage, restart this script with
>the --force option
>
>but the hostname and at the very least localhost is OK they are set in
>the /etc/rc.conf and /etc/hosts files
>
>[Caveat - the hostname entry has the domain extension '*.com',
>hostname -s removes the extension]
>
>so I used the --force option then
> mach1# pwd
> /usr/local/mysql/bin
> mach1# mysqld_safe &
> [1] 3213
> mach1# Starting mysqld daemon with databases from /var/db/mysql
> 060126 06:42:01 mysqld ended
>Then tried
> mach1# mysqladmin version
> mysqladmin: connect to server at 'localhost' failed
> error: 'Can't connect to local MySQL server through socket
>'/usr/local/var/mysql' (38)'
> Check that mysqld is running and that the socket:
>'/usr/local/var/mysql' exists!
>
>It does exist w/ permissons of drwxrwxrwt

That's NOT a socket! That's a directory!
Error 38 is 'socket operation on non-socket'.

The mysqld variable 'socket' (shown with "mysqld --verbose --help",
using an appropriate path for mysqld) on my system has the value
/tmp/mysql.sock. If yours does not end in .sock, fix it so it does
or come up with a darn good excuse for why not.

You can also see this with "mysqladmin variables" but only
if you can actually get the server to start first.

Gordon L. Burditt