We used to use the /etc/hostconfig file for determining which programs should start at boot time on our Mac. Apple however has decided that this will stop in future versions and that they will move over to launchd, it is currently used in Leopard and is the prefered way in controlling your deamons. You can read more about it on the AFP548 site and the manpages for lauchd, launchctl and plist.

To enable it we need to create a .plist file with all the details, as MySQL is a system wide application we need to put it in /System/Library/LaunchDaemons/ and I’m going to call it com.diymacserver.mysql.plist. The content of the file will look like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.diymacserver.mysql</string>
  <key>KeepAlive</key>
  <true/>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/mysql/bin/mysqld</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
  <key>UserName</key>
  <string>_mysql</string>
  <key>WorkingDirectory</key>
  <string>/usr/local/mysql</string>
</dict>
</plist>

The label key should be the same as the plist file name without the .plist
The KeepAlive option will restart MySQL when it crashes or is stopped.
The RunAtLoad means it will start at boot time.
The UserName option indicates under which user the program should start.

To load and activate the .plist file and to make sure that it is started after a reboot you’ll need to load the plist file by using the command:

sudo launchctl load /System/Library/LaunchDaemons/com.diymacserver.mysql.plist

You can see if it loaded correctly by using the command:

sudo launchctl list

This will show you all the active plist files.

You can see if everything went correctly by trying to start the mysql instance.

sudo launchctl start com.diymacserver.mysql

To stop the instance you could use:

sudo launchctl stop com.diymacserver.mysql

Bu because of the KeepAlive option it will be restarted.

To stop the script being run at boot time you need to unload the plist file.

sudo launchctl unload /System/Library/LaunchDaemons/com.diymacserver.mysql.plist

MySQL is still working on the problems regarding the incompatibilities. In the bug reports there are some advices which will be released in the next release I guess. If you can’t wait, here are the solutions:

The not working preference pane has an update which you can download from here.

The issue of not starting up properly has to do with the user rights on the data directory. You can change them to the proper user by the command:

chown -R mysql:wheel /usr/local/mysql/data

Hopefully the next release will address all the issues. If ou want to read the bugreport yourself you can do that here: http://bugs.mysql.com/bug.php?id=28854

We’ll I wonder what will happen with MySQL, first the full or enterprise version was put behind bars and now a take over by Sun. I guess the future will tell. If it has any troubling consequences I guess we’ll have to switch to another open source database but I think there is a slim change that it will go that bad.

Here is the news from MySQL and here from Sun.

No we didn’t miss a few versions, this is the first new release after 5.0.45. By the way this is a bug fix release and it is in source format only. This means that you definitely need to compile your version if you are affected by the bugs that are fixed. If you don’t have any problems or concerns don’t upgrade.

Check the bug fixes that are listed on the release notes and check if you are affected in any way.

I’ve compiled this version and did some simple tests on Leopard and Tiger and both can be compiled and installed using the instructions in the documentation set without problems.

While trundling to my subscribed RSS feeds (still too many and I’m still pruning them regularly) I noticed John Gruber mentioning his friend Dan Benjamin writeup of his MySQL compilation instructions article. I’ve read it and it’s pretty good and really well written for an audience who have no experience at the Terminal.

I do however not gree with all his instructions which are pretty much geared to his need to get Ruby on Rails working for him. The most important mistake I see is that he doesn’t go for the shared libraries options. He is compiling static libraries and we know from experience (read the older blogpost son the subject) that that options causes issues with for instance our PHP compilation.

Another item that keeps me wondering is why he’s removing the default StartupItem which works fine even wth your own compiled installation and replace it with a new launchd script. But I would recommend to read the article yourself and draw you own conclusions.

By the way, the installation instructions for MySQL, Apache and PHP have been updated to reflect the impact that Leopard had on them. I’m still working on the mailserver instructions.

There is a small issue with installing MySQL on Leopard. The preference pane to start/stop Mysql does not work. Don’t know why but it just doesn’t. It will start manually but you need to make a slight adjustment to one file called ‘mysql.server’ in the directory ‘/usr/local/mysql/support-files/’. On line 62 change:

user=mysql

into

user=_mysql

The following has happened in Leopard. All the users that are used for running applications have a changed username. All the daemon users start with an underscore in Leopard. This means that the user ‘mysql’ which we remember in Tiger is currenty known as ‘_mysql’. You will see this user as the owner of ‘/usr/local/mysql/data’. So somehow everything gets installed with the correct user.

The error of the Preference pane has been logged as a bug on the MySQL bug site.

If anyone can explain why the usernames have changed I would like to know!

By the way the only difference in installing MySQL on Leopard is the configure statement to compile MySQL, the rest is still the same. The new ./configure statement for PowerPC and Intel based Macs is:

./configure --prefix=/usr/local/mysql \
--localstatedir=/usr/local/mysql/data \
--libexecdir=/usr/local/mysql/bin \
--libdir=/usr/local/mysql/lib \
--with-server-suffix=-standard \
--enable-thread-safe-client \
--enable-local-infile \
--enable-shared \
--with-zlib-dir=bundled \
--with-big-tables \
--with-readline \
--with-archive-storage-engine \
--with-innodb \
--without-docs \
--without-bench

As you see the CFLAGS have gone, the new XCode tools do their auto detection a lot better I guess.

Well, here as well we missed an update, sorry about this I hope to keep you more up to date to stuff like this the coming period. The bug is still there so you still need to recompile !

This release includes a number of security-relevant fixes:

• CREATE TABLE LIKE did not require any privileges on the source table and was not isolated from alteration by other connections. (Bugs #25578 and #23667)
• It is no longer possible to use a view to gain update privileges for tables in other databases. (Bug#27878)
• It is no longer possible for a user to gain privileges by calling a stored routine that was declared using SQL SECURITY INVOKER. (Bug#27337)
• The DROP privilege requirement for RENAME TABLE is now correctly enforced. (Bug#27515)
• Malformed password packets in the connection protocol can no longer cause the server to crash. (Bug#28984)

One bug fix resulted in an incompatible change:

• The use of an ORDER BY or DISTINCT clause with a query containing a call to the GROUP_CONCAT() function caused results from previous queries to be redisplayed in the current result. The fix for this includes replacing a BLOB value used internally for sorting with a VARCHAR; this may lead to truncation when the result of a query that uses GROUP_CONCAT() is longer than the limit for VARCHAR, which is a new restriction in MySQL 5.0.45. (Bugs #23856, #28273)

Read about all the changes here.

Yes it’s finally there, the version that includes shared libraries in the binary distribution package which would mean we never have to recompile MySQL ourselves. I’ve downloaded the package and installed it on my test server. The installation went without a problem as usual, but trying to compile PHP brought a new issue, some linking issue with zlib libraries.

/usr/bin/ld: warning multiple definitions of symbol _inflateInit_
/usr/local/mysql/lib/libmysqlclient.dylib(inflate.o) definition of _inflateInit_
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libz.dylib(inflate.o) definition of _inflateInit_
etc...

I guess we still need to recompile. I hope it is not due to some left over trial I did earlier, could someone confirm my findings ?

There is a light at the end of the tunnel, after complaining and blogging about the issue for some time it looks like it is going to be solved in the next release of MySQL. I received some updates on the bug report via email and it is released in version 5.0.40 Enterprise version, see the release notes. Now we only need to wait for the Community release….

MySQL has released version 5.0.37 of the Community Server. This is a binary and source-only release. You can read all about the new/changed functionality and bugfixes in the release notes. You can download the latest source version from the MySQL.com site.

You can download the binary install and do the source compile/install to get a functional 5.0.37 version running with all the goodies and defaults from the binary install. You still need to do the recompile to get the shared libraries. The bug still isn’t fixed, please add your vote to the bug-report to get this silly issue solved !