Developer Forum

n Mon, 28 Dec 2009 18:04:01 -0800 (PST), JRough wrote:

Yup. It started and kersploded.
>> sh-3.2# ./bin/mysqld_safe & >> [1] 1722 >> sh-3.2# 091228 18:03:05 mysqld_safe Logging to '/usr/local/ >> mysql-5.1.40-osx10.5-powerpc/data/janis-roughs-power-mac- >> g5.local.err'. >> 091228 18:03:06 mysqld_safe Starting mysqld daemon with databases >> from /usr/local/mysql-5.1.40-osx10.5-powerpc/data >> 091228 18:03:07 mysqld_safe mysqld from pid file /usr/local/ >> mysql-5.1.40-osx10.5-powerpc/data/janis-roughs-power-mac-g5.local.pid >> ended

This is a separate run. What does the error log say THIS time? (If you don't
know where it logs, specify temporarily with --log-error=/path/to/file
on the mysqld_safe.
>> thanks, >> >> What am I looking for? In /private/tmp there is no mysql.sock. No >> hidden files nothing.


It ain't gonna be there. Both the server and client are configured (per
your first post) to look in /var/mysql/mysql.sock for the socket.

--
"Doesn't everybody?" is a question that never expects an answer of "No."

Did you set up a plist?

Suggest you take a look at this site- you don't need to compile the
MySQL- but the part about creating a plist is useful.

http://www.yqcomputer.com/

1) There are no such thing as 32-bit G5 processor. If you have a G5,
then it's a 64-bit. If you meant G4, then that's what you have. Double
check this to be sure you're using the right bit-size.

2) You can't install Snow Leopard on a PPC machine. It's intel-only.

3) Is there a reason for compiling from source? You should be able to
use the binary. Leopard has changed the way MySQL starts up and hence
requires the plist fix I linked you to.

JRough < XXXX@XXXXX.COM > writes:


No such animal - G5s are 64-bit.


It's not. I'm running the latest MySQL on a ten year old G4.


Snow Leopard requires an Intel Mac.


If you're referring to Mac OS X Server, yes it does. It's not in your
default PATH, but it's there.

sherm--

JRough < XXXX@XXXXX.COM > writes:


Does /usr/local/mysql-5.1.40-osx10.5-powerpc/ exist? If not, and if
/usr/local/mysql/ *does*, then a symlink should fix things up:

cd /usr/local
sudo ln -s ./mysql ./mysql-5.1.40-osx10.5-powerpc

I've seen this kind of problem before on Mac OS X versions of MySQL,
where the MySQL tools were configured to use the longer path, but the
installer package placed files in /usr/local/mysql instead.

sherm--

JRough < XXXX@XXXXX.COM > writes:



Leopard, although I've had MySQL working on it since the 4th Developer
Preview release of Mac OS X 10.0. You kids today have it easy - in MY
day we had to edit the source code just to get it to compile! Grumble,
grumble, uphill both ways, grumble... :-)


Only Mac OS X Server includes MySQL. If you don't have Server, it wasn't
preinstalled.

sherm--

JRough < XXXX@XXXXX.COM > writes:


*What* package file? Did you download it from mysql.com?


That's bizarre. It should be looking for share/english/errmsg.sys here,
not bin/share/english/errmsg.sys. The required file is in the package
I just now downloaded from mysql.com, and installed to the correct
spot, but mysqld is looking in the wrong place for it.

sherm--

Sherm Pendley < XXXX@XXXXX.COM > writes:


Okay, earlier in the thread you posted a my.conf that includes this:

#Path to installation directory. All paths are usually resolved
#relative to this.
basedir=/usr/local/mysql-5.1.40-osx10.5-powerpc/bin/

Notice what it says in the comment? When mysqld is starting up, it's
looking for share/english/errmsg.sys *relative to the basedir* - that's
where the incorrect bin/ is coming from.

sherm--

If you can connect via mysql client, then it's working.


Pretty sure that mysqladmin isn't interactive- you should pass in
commands & options and it'd do stuff. If you want interactive session,
use mysql client, or GUI tool.

Banana < XXXX@XXXXX.COM > writes:



Yep. The absence of any error messages is a good sign though!


You're right, mysqladmin isn't an interactive shell. The help page lists
the available commands and options that can be given as arguments when
you run it.

sherm--

As explained previously, mysqladmin isn't interactive; you need to pass
in the command... e.g.

mysqladmin ping -u root



(note the ping command being given after the mysqladmin -- read the man
pages to see the rest of option and how it is to be used)

launchd is Daemon manager for Mac OS X.


I would want to verify that the mysql.sock is actually in /tmp/ folder.
Depending on how it was installed, it could have been in a different folder.

Alternatively, try this:

mysql -h 127.0.0.1 -u XXXX -p

to coerce connecting to MySQL via TCP/IP instead of socket (which I
prefer for local connection but let's do one thing at a time-- this is
to rule out missing socket file from a server that is not running).

Next point, I _think_ you are supposed to see a mysqld (note the d at
the end). mysql would be just be a client. At least in my top & aux
doesn't list mysql but rather mysqld.


This only will succeed if there is an actual file named mysql.sock
located in the /tmp folder. As explained above, if the installation
configuration is different, it may be actually somewhere else.

The far more likely answer is that the mysql isn't up and running.

How did you start the server? Manually or automatically as a part of
startup?


I don't think so. See the above for possible troubleshooting steps.

Okay, this does confirm that MySQL isn't running at all and this isn't a
case of missing socket file or misconfiguration.


It's just a file that tells the OS where to look for inter-process
communication. UNIX and Unix-like systems uses sockets, which are small
files that points to the memory address of the process for entry points.


Maybe I should change the my.conf and

No. Your MySQL server is looking in /tmp/mysql.sock so that's where it
expects it to be. If your configuration files already points to
/tmp/mysql.sock, then this is correct.



Apologies if I've missed this but did you already try running
mysqld_safe? Furthermore, did you do this as an administrator?

For example, I usually do this:

su admin -c 'sudo /usr/local/mysql/bin/mysqld_safe'

where 'admin' is my Administrator account's short name. Your
administrator account may be named differently, so change that
accordingly. You would then enter the administrator's password twice
(yes, twice). See if this succeed, then we can move further in fixing
the startup issues.