MySQL Bugs: #60660: OS X Installer does not produce a working installation

Bug #60660	OS X Installer does not produce a working installation
Submitted:	26 Mar 2011 18:01	Modified:	26 Mar 2012 17:46
Reporter:	Rob Lewis (Candidate Quality Contributor)	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S1 (Critical)
Version:	5.5.10GA	OS:	MacOS (10.6.7)
Assigned to:		CPU Architecture:	Any

Description:
It is stunning that after all this time and the months that have passed since these problems were reported, the latest OS X installer still cannot produce a working installation. 

I just tried (using the DMG pkg) to update an installation of a 5.4.2 beta version to the latest GA release of 5.5.10. The installer reports success, but the mysqld server won't start. Here's what it reports:

110326 10:38:39 [Warning] Can't create test file /usr/local/mysql-5.5.10-osx10.6-x86_64/data/minime.lower-test
110326 10:38:39 [Warning] Can't create test file /usr/local/mysql-5.5.10-osx10.6-x86_64/data/minime.lower-test
mysqld: File './mysql-bin.index' not found (Errcode: 13)
110326 10:38:39 [ERROR] Aborting
110326 10:38:39 [Note] mysqld: Shutdown complete

The startup controller in System Preferences doesn't work either. 

Following instructions, I copied my old data directory to the new location (how hard would it be to include a script to do this?) 
I tried fixing these lines in the mysql.server file, with no improvement: 
basedir=/usr/local/mysql (was basedir=)
datadir=/usr/local/mysql/data (was datadir=)
(Why does this step seem to be uniquely required of OS X users?)

As far as I can tell, ownership and permissions are set correctly. The file mysql-bin.index that is reported missing is present in the data directory, as reported in this directory listing of /usr/local/mysql-5.5.10-osx10.6-x86_64/data:
-rw-rw----    1 _mysql  wheel       3249 Mar 26 08:50 mysql-bin.index

Perhaps Linux users enjoy solving problems by performing arcane Terminal commands, but OS X users sort of expect things to "just work." 

Incidentally, there is a longstanding error in the ReadMe file that comes with the installer: since at least 3 versions of OS X ago, the user name for the mysql process has been "_mysql" rather than "mysql". 

How to repeat:
Run the 5.5.10GA installer on a Mac 10.6 system. 

Suggested fix:
Produce an OS X installer that just works.

Please, send the results of:

ls -l /usr/local | grep mysql
ls -l /usr/local/mysql/

Here are the requested commands and results: 

ls -l /usr/local | grep mysql
lrwxr-xr-x   1 root  wheel   27 Mar 26 08:31 mysql -> mysql-5.5.10-osx10.6-x86_64
drwxr-xr-x   3 root  wheel  102 Mar 26 08:31 mysql-5.4.2-beta-osx10.5-x86_64
drwxr-xr-x  16 root  wheel  544 Mar  9 08:42 mysql-5.5.10-osx10.6-x86_64

ls -l /usr/local/mysql/
total 280
-rw-r--r--    1 root    wheel   17987 Mar  9 07:11 COPYING
-rw-r--r--    1 root    wheel    7370 Mar  9 07:11 INSTALL-BINARY
-rw-r--r--    1 root    wheel  114014 Mar  9 07:11 README
drwxr-xr-x   44 root    wheel    1496 Mar  9 08:42 bin
drwxr-xr-x  193 _mysql  wheel    6562 Mar 26 11:07 data
drwxr-xr-x    5 root    wheel     170 Mar  9 08:42 docs
drwxr-xr-x   37 root    wheel    1258 Mar  9 08:42 include
drwxr-xr-x   12 root    wheel     408 Mar 26 08:31 lib
drwxr-xr-x    4 root    wheel     136 Mar  9 08:42 man
drwxr-xr-x   19 root    wheel     646 Mar 26 08:31 mysql-test
drwxr-xr-x    3 root    wheel     102 Mar  9 08:42 scripts
drwxr-xr-x   32 root    wheel    1088 Mar  9 08:42 share
drwxr-xr-x   28 root    wheel     952 Mar  9 08:42 sql-bench
drwxr-xr-x   16 root    wheel     544 Mar  9 08:42 support-files

I tried re-running the installer and starting the server (using both the PrefPane and the mysqld terminal command)--and got the same errors: 

110326 15:50:40 [Warning] Can't create test file /usr/local/mysql-5.5.10-osx10.6-x86_64/data/MiniMe.lower-test
110326 15:50:40 [Warning] Can't create test file /usr/local/mysql-5.5.10-osx10.6-x86_64/data/MiniMe.lower-test
mysqld: File './mysql-bin.index' not found (Errcode: 13)
110326 15:50:40 [ERROR] Aborting

It appears that re-running the installer retained my data in the data folder in the new installation folder (that I had copied from the data folder of the previous beta version I have been running). I thought the installer would overwrite it with the default data folder contents, but apparently not.

I tried starting the server with the "startup item" command documented in S. 2.4.3 of the manual: 

sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
Password:
Starting MySQL database server

Although it said it was starting the server, a check with Activity Monitor reveals that there is no running mysqld process, and the PrefPane continues to report that the server instance is stopped.

I have now tried deleting the installation directory and the "mysql" link to it, and re-running the installers without attempting to copy my old data to the new installation. 

No change in behavior. Server still will not start up.

Had you used "sudo" to start MySQL server? Look:

macbook-pro:5.5 openxs$ sudo /usr/local/mysql-5.5.10-osx10.5-x86_64/support-files/mysql.server start
Password:
Starting MySQL
..... SUCCESS! 
macbook-pro:5.5 openxs$ bin/mysql -uroot test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

Permissions in my case looks exactly like yours, and I doubt Mac OS X version matters that much.

Note that I had NOT changed basedir and datadir in mysql.server script. Everything works by default...

Hello. Thanks for the response. I tried this:
sudo /usr/local/mysql/support-files/mysql.server start

and got this:
Password:
Starting MySQL
... ERROR! The server quit without updating PID file (/usr/local/mysql/data/minime.lan.pid).
minime:~ xt$ 

Even if this worked, I am supposed to be able to start and stop the server via the PrefPane, which is also supposed to give me the option to automatically start the server at system startup time. This used to work with earlier versions. 

As noted above, this is with a clean install of MySQL with the default data directory contents.

OK, so with sudo the error is different (let's deal with Pref. Pane later). Please, send last lines from the error log, /usr/local/mysql/data/minime.err probably. I wonder what server reported there during startup.

OK, here are the last few lines from MiniMe.local.err (see below for a different error file): 

110326 21:49:24 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110326 21:49:24 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110326 21:49:25 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Table 'mysql.plugin' doesn't exist
110326 21:49:25 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110326 21:49:25 InnoDB: The InnoDB memory heap is disabled
110326 21:49:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110326 21:49:25 InnoDB: Compressed tables use zlib 1.2.3
110326 21:49:25 InnoDB: Initializing buffer pool, size = 256.0M
110326 21:49:25 InnoDB: Completed initialization of buffer pool
110326 21:49:25 InnoDB: highest supported file format is Barracuda.
110326 21:49:25  InnoDB: Waiting for the background threads to start
110326 21:49:26 InnoDB: 1.1.5 started; log sequence number 1595675
110326 21:49:26 [ERROR] /usr/local/mysql/bin/mysqld: unknown option '--skip-locking'
110326 21:49:26 [ERROR] Aborting

110326 21:49:26  InnoDB: Starting shutdown...
110326 21:49:26  InnoDB: Shutdown completed; log sequence number 1595675
110326 21:49:26 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

110326 21:49:26 mysqld_safe mysqld from pid file /usr/local/mysql/data/MiniMe.local.pid ended
110326 22:10:08 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110326 22:10:08 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110326 22:10:08 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Table 'mysql.plugin' doesn't exist
110326 22:10:08 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110326 22:10:08 InnoDB: The InnoDB memory heap is disabled
110326 22:10:08 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110326 22:10:08 InnoDB: Compressed tables use zlib 1.2.3
110326 22:10:08 InnoDB: Initializing buffer pool, size = 256.0M
110326 22:10:08 InnoDB: Completed initialization of buffer pool
110326 22:10:08 InnoDB: highest supported file format is Barracuda.
110326 22:10:08  InnoDB: Waiting for the background threads to start
110326 22:10:09 InnoDB: 1.1.5 started; log sequence number 1595675
110326 22:10:09 [ERROR] /usr/local/mysql/bin/mysqld: unknown option '--skip-locking'
110326 22:10:09 [ERROR] Aborting

110326 22:10:09  InnoDB: Starting shutdown...
110326 22:10:10  InnoDB: Shutdown completed; log sequence number 1595675
110326 22:10:10 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

110326 22:10:10 mysqld_safe mysqld from pid file /usr/local/mysql/data/MiniMe.local.pid ended

---------------------------------------------

There is also a file minime.lan.err
("MiniMe.local" is Apple's Bonjour name for the machine, while "minime.lan" exists for the same machine because I run a local DNS which gives it this name)
The lines below are from this file. It looks pretty much the same as the above except the time of day is different. I don't know what would cause MySQL to write in one file vs. the other: 

110326 22:26:11 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110326 22:26:11 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110326 22:26:11 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Table 'mysql.plugin' doesn't exist
110326 22:26:11 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110326 22:26:11 InnoDB: The InnoDB memory heap is disabled
110326 22:26:11 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110326 22:26:11 InnoDB: Compressed tables use zlib 1.2.3
110326 22:26:11 InnoDB: Initializing buffer pool, size = 256.0M
110326 22:26:12 InnoDB: Completed initialization of buffer pool
110326 22:26:12 InnoDB: highest supported file format is Barracuda.
110326 22:26:12  InnoDB: Waiting for the background threads to start
110326 22:26:13 InnoDB: 1.1.5 started; log sequence number 1595675
110326 22:26:13 [ERROR] /usr/local/mysql/bin/mysqld: unknown option '--skip-locking'
110326 22:26:13 [ERROR] Aborting

110326 22:26:13  InnoDB: Starting shutdown...
110326 22:26:13  InnoDB: Shutdown completed; log sequence number 1595675
110326 22:26:13 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

110326 22:26:13 mysqld_safe mysqld from pid file /usr/local/mysql/data/minime.lan.pid ended
110327 06:53:59 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110327  6:53:59 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110327  6:54:00 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Table 'mysql.plugin' doesn't exist
110327  6:54:00 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110327  6:54:00 InnoDB: The InnoDB memory heap is disabled
110327  6:54:00 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110327  6:54:00 InnoDB: Compressed tables use zlib 1.2.3
110327  6:54:00 InnoDB: Initializing buffer pool, size = 256.0M
110327  6:54:00 InnoDB: Completed initialization of buffer pool
110327  6:54:00 InnoDB: highest supported file format is Barracuda.
110327  6:54:00  InnoDB: Waiting for the background threads to start
110327  6:54:01 InnoDB: 1.1.5 started; log sequence number 1595675
110327  6:54:01 [ERROR] /usr/local/mysql/bin/mysqld: unknown option '--skip-locking'
110327  6:54:01 [ERROR] Aborting

110327  6:54:01  InnoDB: Starting shutdown...
110327  6:54:01  InnoDB: Shutdown completed; log sequence number 1595675
110327  6:54:01 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

110327 06:54:01 mysqld_safe mysqld from pid file /usr/local/mysql/data/minime.lan.pid ended

Thank you for helping me troubleshoot this.

P.S. I saw the logged item about running mysql_upgrade, so I tried that: 

mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/tmp/mysql.sock' 
mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) when trying to connect
FATAL ERROR: Upgrade failed

(I recall years ago, running an older version of OS X Server, I had to change the location of the socket to connect to MySQL, but I believe that was specific to the Server OS, and I am now running the regular non-server edition of Snow Leopard.)

This is a key problem now:

--skip-locking

Please, check for my.cnf in usual locations, find and comment out this option.

OK, I have commented out that line in /private/etc/mysql/my.cnf

What do I do now? 

By the way, I see that my.cnf has a number of old changes I made at various times in the past. Might it be advisable to start over with a fresh copy from the latest distribution? Where would I find that? 

Maybe I will upload my current version. You can see the changes I've made by searching the file for "***GRL". Also, I note that the first line describes this file as "for large systems". I don't really think my system qualifies as "large" (Mac mini w/4GB RAM, used as a desktop workstation too). Any advice appreciated.

OK, I found the various sample .cnf files (like my-large.cnf) in support-files and may try replacing my old my.cnf file. 

One question though: is it still necessary to uncomment all those lines to use InnoDB tables as it says in the sample file? I thought I read somewhere that InnoDB was now the default table engine for MySQL.

OK, I created a new my.cnf file based on the sample file my-large.cnf. 
I changed only the following things: 
--increased max_allowed_packet from 1M to 32M (I need this for some applications)
--reduced thread_concurrency from 8 to 4 (2X the dual-core processor)
--uncommented the group of InnoDB parameters near the end of the file

No other changes, and mysql still will not start. Also, mysql_upgrade will not run because mysqlcheck can't connect through /tmp/mysql.sock (which does not exist).

Here's my attempt to run mysqld_safe: 

mysqld_safe
110327 15:00:24 mysqld_safe Logging to '/usr/local/mysql/data/minime.lan.err'.
110327 15:00:25 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
/usr/local/mysql/bin/mysqld_safe: line 107: /usr/local/mysql/data/minime.lan.err: Permission denied
/usr/local/mysql/bin/mysqld_safe: line 144: /usr/local/mysql/data/minime.lan.err: Permission denied
110327 15:00:25 mysqld_safe mysqld from pid file /usr/local/mysql/data/minime.lan.pid ended
/usr/local/mysql/bin/mysqld_safe: line 107: /usr/local/mysql/data/minime.lan.err: Permission denied

Why do you use mysqld_safe now, instead of mysql.server script? 

In any case, mysqld_safe also works, but you should run it via sudo. Without that you get the same "error 13" messages we had with mysql.server previously...

You ask why I do things? I don't know why, I'm just trying stuff. All I really know is that 2 days ago I was happily using MySQL 5.4 beta, and now after spending hours and hours fighting with it I can't even get 5.5 to start up! 
Why is this so hard? Why won't the PrefPane work? Why can't the installer install a working system? 

Here is my attempt to run mysql.server:

sudo /usr/local/mysql/support-files/mysql.server start
Password:
Starting MySQL
.... ERROR! The server quit without updating PID file (/usr/local/mysql/data/minime.lan.pid).

P.S. Is there anyone working at MySQL who is in charge of the Macintosh user experience? If not, I submit that there should be.

I tried running mysqld_safe from a different OS X user account: 

sudo mysqld_safe
Password:
110328 10:09:02 mysqld_safe Logging to '/usr/local/mysql/data/MiniMe.local.err'.
110328 10:09:02 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110328 10:09:04 mysqld_safe mysqld from pid file /usr/local/mysql/data/MiniMe.local.pid ended

Server is not running. Here's the error file. Note the report of a crash: 

110328 10:09:02 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110328 10:09:02 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110328 10:09:02 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Table 'mysql.plugin' doesn't exist
110328 10:09:02 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110328 10:09:02 InnoDB: The InnoDB memory heap is disabled
110328 10:09:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110328 10:09:02 InnoDB: Compressed tables use zlib 1.2.3
110328 10:09:02 InnoDB: Initializing buffer pool, size = 256.0M
110328 10:09:02 InnoDB: Completed initialization of buffer pool
110328 10:09:02 InnoDB: highest supported file format is Barracuda.
110328 10:09:03  InnoDB: Waiting for the background threads to start
110328 10:09:04 InnoDB: 1.1.5 started; log sequence number 1595675
110328 10:09:04 [Note] Recovering after a crash using mysql-bin
110328 10:09:04 [Note] Starting crash recovery...
110328 10:09:04 [Note] Crash recovery finished.
110328 10:09:04 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
110328 10:09:04 mysqld_safe mysqld from pid file /usr/local/mysql/data/MiniMe.local.pid ended

Please, run:

sudo /usr/local/mysql-5.5.10-osx10.5-x86_64/scripts/mysql_install_db

and then try to start server again. Some of the tables in the mysql database are missing.

Thanks. I tried the command (changing the OS X version from 10.5 to 10.6), and here are the results: 

sudo /usr/local/mysql-5.5.10-osx10.6-x86_64/scripts/mysql_install_db
Password:
FATAL ERROR: Could not find ./bin/my_print_defaults
If you compiled from source, you need to run 'make install' to
copy the software into the correct location ready for operation.
If you are using a binary release, you must either be at the top
level of the extracted archive, or pass the --basedir option
pointing to that location.

Are you SURE that I don't need to specify basedir and datadir in the /usr/local/mysql/support-files/mysql.server file? That was what made it work with some previous releases (though I have tried it with this release without success, although there may have been other problems too).

I noticed something else: I was thinking about trying to revert to my previous running install of 5.4.2beta, but when I looked in its folder I saw that everything in it except (thankfully) my previous data directory is gone! I did not delete anything from this folder, so do you have any idea what happened?

OK, I think I had a bit of success here. The first "cd" command seems to have made this part work: 

cd /usr/local/mysql-5.5.10-osx10.6-x86_64
MiniMe:mysql-5.5.10-osx10.6-x86_64 robbo$ sudo ./scripts/mysql_install_db
Password:
Installing MySQL system tables...
OK
Filling help tables...
OK

To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:

./bin/mysqladmin -u root password 'new-password'
./bin/mysqladmin -u root -h MiniMe.local password 'new-password'

Alternatively you can run:
./bin/mysql_secure_installation

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

See the manual for more instructions.

You can start the MySQL daemon with:
cd . ; ./bin/mysqld_safe &

You can test the MySQL daemon with mysql-test-run.pl
cd ./mysql-test ; perl mysql-test-run.pl

Please report any problems with the ./bin/mysqlbug script!

Looks like you should have all missing tables from the mysql database in place. Had you tried to start server again, using sudo mysqld_safe or sudo mysql.server start?

Sorry, but I will not comment on what happened to former 5.4.2 installation, as I do not know all the steps you had performed during upgrade, and I do not think this is relevant to the startup problem we are trying to solve here.

As recommended in the program's output, I tried this:
sudo perl mysql-test-run.pl

It ran a long time reporting various tests and finally output this: 
The servers were restarted 346 times
Spent 8535.040 of 10798 seconds executing testcases
Completed: All 1636 tests were successful.
469 tests were skipped, 103 by the test itself.

So I guess that is maybe somewhat encouraging. 

At the moment, the PrefPane reports that the server is stopped. 
I tried this command:
sudo /usr/local/mysql/support-files/mysql.server start

and got this:
Starting MySQL
..... ERROR! The server quit without updating PID file (/usr/local/mysql/data/MiniMe.local.pid).

and this was written in the .err file:
110329 05:45:26 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110329  5:45:27 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110329  5:45:27 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
110329  5:45:27 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110329  5:45:27 InnoDB: The InnoDB memory heap is disabled
110329  5:45:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110329  5:45:27 InnoDB: Compressed tables use zlib 1.2.3
110329  5:45:27 InnoDB: Initializing buffer pool, size = 256.0M
110329  5:45:27 InnoDB: Completed initialization of buffer pool
110329  5:45:27 InnoDB: highest supported file format is Barracuda.
110329  5:45:27  InnoDB: Waiting for the background threads to start
110329  5:45:28 InnoDB: 1.1.5 started; log sequence number 1595675
/usr/local/mysql/bin/mysqld: File './mysql-bin.000009' not found (Errcode: 13)
110329  5:45:28 [ERROR] Failed to open log (file './mysql-bin.000009', errno 13)
110329  5:45:28 [ERROR] Could not open log file
110329  5:45:28 [ERROR] Can't init tc log
110329  5:45:28 [ERROR] Aborting
110329  5:45:28  InnoDB: Starting shutdown...
110329  5:45:29  InnoDB: Shutdown completed; log sequence number 1595675
110329  5:45:29 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete
110329 05:45:29 mysqld_safe mysqld from pid file /usr/local/mysql/data/MiniMe.local.pid ended

so I guess that is not so encouraging. 
Next, I tried this: 
sudo mysqld_safe

and got this:
110329 05:47:32 mysqld_safe Logging to '/usr/local/mysql/data/MiniMe.local.err'.
110329 05:47:32 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110329 05:47:35 mysqld_safe mysqld from pid file /usr/local/mysql/data/MiniMe.local.pid ended

and the same information was written in the .err file as above. 
I notice it asked me to run mysql_upgrade. Should I try that?

Can you try to comment out this:

log-bin=mysql-bin

in your my.cnf and try to start server again (sudo mysql.server start is enough).

Also, please, send the results of:

ls -l /usr/local/mysql/data

As requested: 

ls -l /usr/local/mysql/data
total 301152
-rw-rw----   1 _mysql  wheel     21559 Mar 29 05:47 MiniMe.local.err
-rw-rw----   1 _mysql  wheel  67108864 Mar 29 05:47 ib_logfile0
-rw-rw----   1 _mysql  wheel  67108864 Mar 26 21:36 ib_logfile1
-rw-rw----   1 _mysql  wheel  18874368 Mar 29 05:47 ibdata1
-rw-rw----   1 _mysql  wheel     10445 Mar 27 20:35 minime.lan.err
drwxr-xr-x  75 _mysql  wheel      2550 Mar 28 12:40 mysql
-rw-rw----   1 _mysql  wheel       107 Mar 27 14:43 mysql-bin.000001
-rw-rw----   1 _mysql  wheel       107 Mar 27 14:43 mysql-bin.000002
-rw-rw----   1 _mysql  wheel       107 Mar 27 16:17 mysql-bin.000003
-rw-rw----   1 _mysql  wheel       107 Mar 27 20:35 mysql-bin.000004
-rw-rw----   1 _mysql  wheel       107 Mar 27 20:47 mysql-bin.000005
-rw-rw----   1 _mysql  wheel       107 Mar 28 10:09 mysql-bin.000006
-rw-rw----   1 _mysql  wheel       107 Mar 28 10:11 mysql-bin.000007
-rw-rw----   1 root    wheel     27823 Mar 28 12:40 mysql-bin.000008
-rw-rw----   1 root    wheel    995332 Mar 28 12:40 mysql-bin.000009
-rw-rw----   1 _mysql  wheel       171 Mar 28 12:40 mysql-bin.index
drwx------  20 root    wheel       680 Mar 28 12:40 performance_schema
drwxr-xr-x   3 _mysql  wheel       102 Mar 26 21:44 test

OK I commented this line out:
# log-bin=mysql-bin
in /private/etc/mysql/my.cnf 

then I ran this:
sudo /usr/local/mysql/support-files/mysql.server start

and got this:
Starting MySQL
.. SUCCESS! 

but Activity Monitor does not show any mysqld process running. 
And if I enter this: 
mysql

I get this:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

Just to review: I had a working installation of 5.4.2beta. 
I downloaded the DMG of the latest pkg installer for 5.5.10
I also installed the StartupItem and the PrefPane. 
That's all I did and I was left with a totally nonworking system. 
Of course I have tried many things since then, but nothing to change my impression that your installer simply doesn't work.

This was the problem:

-rw-rw----   1 root    wheel     27823 Mar 28 12:40 mysql-bin.000008
-rw-rw----   1 root    wheel    995332 Mar 28 12:40 mysql-bin.000009

These files belonged to root, not to mysql_. They do not come from 5.5.10 .dmg for sure.

I do not claim, yet, that there is no bug in .dmg or components like Pref. Pane. There were several verified bug reports about Pref. Pane not working properly. There can be a problem specific to 5.4.2 --> 5.5.10 upgrade (I truly doubt anybody in development tried that).

I only claim that:

1. On clean system, or system like mine with the following versions:

macbook-pro:5.5 openxs$ ls -l /usr/local | grep mysql
lrwxr-xr-x   1 root  wheel   27 25 бер 17:31 mysql -> mysql-5.5.10-osx10.5-x86_64
drwxr-xr-x   4 root  wheel  136 19 тра  2009 mysql-5.1.31-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578  1 кві  2009 mysql-5.1.34-osx10.5-x86
drwxr-xr-x  17 root  wheel  578 14 лип  2009 mysql-5.1.37-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578 22 бер  2010 mysql-5.1.45-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578  6 кві  2010 mysql-5.1.46-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578  6 тра  2010 mysql-5.1.47-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578  4 чер  2010 mysql-5.1.48-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578  3 сер  2010 mysql-5.1.50-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578 13 вер  2010 mysql-5.1.51-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578 12 жов 02:03 mysql-5.1.52-osx10.5-x86_64
drwxr-xr-x  17 root  wheel  578  5 лис 04:42 mysql-5.1.53-osx10.5-x86_64
drwxr-xr-x  16 root  wheel  544 10 гру 13:09 mysql-5.1.54-osx10.5-x86_64
drwxr-xr-x  16 root  wheel  544 28 січ 01:01 mysql-5.1.55-osx10.5-x86_64
drwxr-xr-x  16 root  wheel  544  9 бер 17:52 mysql-5.5.10-osx10.5-x86_64
drwxr-xr-x  16 root  wheel  544 20 січ 22:15 mysql-5.5.9-osx10.5-x86_64
drwxr-xr-x  16 root  wheel  544  3 гру 20:24 mysql-advanced-5.5.8-osx10.5-x86_64

.dmg installer works, and resulting installation can be started with 

sudo mysqld_safe

after usual installation steps, if there is no my.cnf in the system. No data disappear in the process.

2. I had not identified clear set of (correct) steps, yet, that makes this a report about a new repeatable bug in 5.5.10 on Mac OS X 10.6.x. This is probably my fault.

3. In my case even Pref. Pane works OK with 5.5.10, but this is some older version. I had not copied it from .dmg of 5.5.10.

So, after proving that MySQL server 5.5.10 can be started successfully on Mac OS X, I am leaving this bug report open for others to comment and identify missing information.

That is very interesting. 
Should the /usr/local/mysql/data/performance_schema directory also be owned by _mysql instead of root? 

I changed owner on those 2 files and then got this in the .err file: 

110329 12:21:39 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110329 12:21:39 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110329 12:21:39 [Warning] You need to use --log-bin to make --binlog-format work.
110329 12:21:39 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
110329 12:21:39 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110329 12:21:39 InnoDB: The InnoDB memory heap is disabled
110329 12:21:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110329 12:21:39 InnoDB: Compressed tables use zlib 1.2.3
110329 12:21:39 InnoDB: Initializing buffer pool, size = 256.0M
110329 12:21:39 InnoDB: Completed initialization of buffer pool
110329 12:21:39 InnoDB: highest supported file format is Barracuda.
110329 12:21:40  InnoDB: Waiting for the background threads to start
110329 12:21:41 InnoDB: 1.1.5 started; log sequence number 1595675
110329 12:21:41 [ERROR] /usr/local/mysql/bin/mysqld: Can't find file: './mysql/host.frm' (errno: 13)
110329 12:21:41 [ERROR] Fatal error: Can't open and lock privilege tables: Can't find file: './mysql/host.frm' (errno: 13)
110329 12:21:41 mysqld_safe mysqld from pid file /usr/local/mysql/data/MiniMe.local.pid ended

So the server still does not start up. 
I think I would like to remove all traces of MySQL from my system and start over from scratch. I have my old data directory from 5.4.2beta backed up on another drive. 
Can you point me to instructions for doing this?

Just to report "closure" on this issue: thanks to Time Machine I was able to restore the previous installation of 5.4.2beta. Backed up my data with mysqldump. (Note that 5.4 was an aborted development path and has incompatibilities with 5.5.) 

I deleted every file related to mysql that I could find, and reinstalled the 5.5.10 pkg, including the Startup Item and the Pref Pane. I edited a few minor items in .../support-files/my-large.cnf and saved it as /etc/mysql/my.cnf. 

But I wasn't done: trying to reimport my saved SQL data kept giving many messages that the "server has gone away." Researching this error suggested that one cause could be trying to send too large a packet to the server. Sure enough, my data included email attachments that could be several megabytes and the server's max_allowed_packet defaults to only 1MB. Changing this to 32MB allowed the import to work. Restarting the server loaded my now-restored privilege tables, etc., and I was back in business. 

I still feel that there is much room for improvement in the Mac installer. I wasted way too many hours fighting this.

Rob, you are being very polite and kind. I have had not so kind words concerning this, but, I will remain civil as we really need to have a working solution.  I am hoping such restraint will yield some happier results.

I too have wasted MANY hours trying to get the latest package to install and let me connect to it on my MACBook Pro running Snow Leopard.  I was trying to install the package: mysql-5.5.21-osx10.6-x86_64.dmg

I get the same socket error.  Uninstalling and reinstalling if fruitless.

Past installers have been great and my MAMP install's MySQL works fine.  I really want to have a dev environment without MAMP.

Please, Oracle folks, could you see this gets resolved?

Thank you so very much.

Sorry, I forgot to subscribe to the post.

John,

I do not see any problems with exactly the same .dmg:

macbook-pro:mysql-5.5.21-osx10.5-x86_64 openxs$ sudo bin/mysqld_safe
Password:
120325 18:11:52 mysqld_safe Logging to '/usr/local/mysql-5.5.21-osx10.5-x86_64/data/macbook-pro.err'.
120325 18:11:52 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql-5.5.21-osx10.5-x86_64/data
^Z
[1]+  Stopped                 sudo bin/mysqld_safe
macbook-pro:mysql-5.5.21-osx10.5-x86_64 openxs$ bg 1
[1]+ sudo bin/mysqld_safe &
macbook-pro:mysql-5.5.21-osx10.5-x86_64 openxs$ bin/mysql -uroot test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.21 MySQL Community Server (GPL)

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> exit
Bye
macbook-pro:mysql-5.5.21-osx10.5-x86_64 openxs$ tail data/macbook-pro.err 
tail: data/macbook-pro.err: Permission denied
macbook-pro:mysql-5.5.21-osx10.5-x86_64 openxs$ sudo tail data/macbook-pro.err 
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: 127 rollback segment(s) active.
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
120325 18:11:55  InnoDB: Waiting for the background threads to start
120325 18:11:56 InnoDB: 1.1.8 started; log sequence number 0
120325 18:11:56 [Note] Event Scheduler: Loaded 0 events
120325 18:11:56 [Note] /usr/local/mysql-5.5.21-osx10.5-x86_64/bin/mysqld: ready for connections.
Version: '5.5.21'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Server (GPL)
macbook-pro:mysql-5.5.21-osx10.5-x86_64 openxs$

First of all, please excuse me as I am not the "seasoned" programmer that I am sure many of you are.

I have an update to my comments that for me have untangled much of the mystery.

First of all, and I should have mentioned this, (I know this is "MySQL" support and not for some programming language forum), but my struggle was two fold:

1) I was getting MySQL to run from terminal (which I see Valeriy Kravchuk has in her case had a successful experience) after some sleuthing and updating of the PATH. Seems the order was having an effect for some reason on my ability to run from the command line? Yep, spelling was correct. Odd.
Thank you for your time to test this from your objective point of view.

2) Was my ability to connect from PHP to the database.

I was successful yesterday on both accounts by doing two things:

1) Was I tried the install again with the newer binary package. This may of had nothing to do with my success, but, I used: mysql-5.5.22-osx10.6-x86_64.dmg this time with the idea that it might have some improvement that made my experience more successful.

2) After installation, I edited my PHP.INI file to point to the NEW AND DIFFERENT PLACE the mysql.sock file was located.
/private/tmp and then of course include the file mysql.sock in the path.

So far, it seems the problem is solved.

The day I made my initial comment, I had been fussing through this issue the entire day and it was extremely difficult to find clear direction to the solution. Hopefully my entries here will be helpful to someone else who might find themselves in the same situation.

Meanwhile, my sincere thanks again to Valeriy for the verification. I hope I have not bruised anyone's sensibilities with my frustrations. I am sure we have all "been there" at some point right?

Sincerely,

-John

So, for me both 5.5.21 and 5.5.22 produced working installation.

5.5.28 dmg installer still fails with the same issues. I have not succeeded in getting it to work at all yet.

There is clearly something wrong with the installer. It may be that it has something to do with the OS we are installing on (I've gone from Tiger -> Leopard -> Snow Leopard -> Lion). Maybe it has something to do with other installations -- I have XAMPP installed. My situation is hardly unusual, and at least 3 people who could be bothered to search for or report bugs have experienced it. I suspect the true number of people seeing these problems is several orders of magnitude larger.