Solved: Could not setup Mach task special port 9: (os/kern) no access

I've noticed, for quite some time, that I've been getting *hundreds* of log messages like this in the Console system log:

6/06/09 8:30:00 AM com.apple.launchd[1] (0x40e8a0.cron[4895]) Could not setup Mach task special port 9: (os/kern) no access
6/06/09 8:30:00 AM com.apple.launchd[1] (0x40e990.cron[4896]) Could not setup Mach task special port 9: (os/kern) no access
6/06/09 8:35:00 AM com.apple.launchd[1] (0x40d960.cron[4929]) Could not setup Mach task special port 9: (os/kern) no access
6/06/09 8:40:00 AM com.apple.launchd[1] (0x40db90.cron[4965]) Could not setup Mach task special port 9: (os/kern) no access
6/06/09 8:45:00 AM com.apple.launchd[1] (0x40e8a0.cron[5009]) Could not setup Mach task special port 9: (os/kern) no access
6/06/09 8:45:00 AM com.apple.launchd[1] (0x40eb30.cron[5010]) Could not setup Mach task special port 9: (os/kern) no access
6/06/09 8:50:00 AM com.apple.launchd[1] (0x40db40.cron[5067]) Could not setup Mach task special port 9: (os/kern) no access 

A hint to me should have been that they happened every 5 minutes, and also at every 15 minutes, which coincidentally was when I had backup tasks in my crontab.

I'd searched the internet quite a few times and never found the answer. Finally some results.

So, following those instructions, I've removed those tasks from cron and have used Lingon to make modern launchd equivalents. Learn more technical stuff here.

Launchd is pretty good, and Lingon makes it great.

Building Subversion 1.6.1 on Mac OS X

I had a problem getting Subversion 1.6.1 to build and run correctly on Mac OS X 10.5.5.

I discovered that the file /usr/local/lib/libsvn_ra_neon-1.0.dylib was linking against the built in neon lib: /usr/lib/libneon.dylib

Using otool on the build subversion ra_neon library, I saw that it was expecting neon version 2.7 and Mac OS X built in is version 2.6.

That particular function "ne_set_connect_timeout" is new in 2.7 causing the subversion RA to fail loading.

I downloaded also the subversion dependencies and copied them all into the subversion directory. Then I built like this:

% ./configure --with-ssl --disable-neon-version-check --without-apsx
% make
% sudo make install

viola.

DLink DSL-G604T router and multicast packets

I spent too much time trying to figure out what I couldn't get Bonjour/Zeroconf working between a Mac (bonjour) and a Linux (avahi) box.

Until I finally tried plugging both devices into the router physically with cables. Previously, the linux machine was connected by cable and the mac was using wifi.

Whilst there was no problems communicating between the two machines directly (ping, ssh, etc by IP address).... they just wouldn't see each other's names.

So it seems the problem is with the DLink router (as good as it is) in that it doesn't bridge multicast udp packets from the LAN to the WLAN (wireless lan).

I'll try to upgrade the firmware and see if that improves the situation....

Segment fault in strcpy

Just today I was doing some programming work on a Sun machine helping to port some code from an older Sun machine to the newer OS.

The client suspected that it was a compiler problem because the newly compiled versions of the same source code didn't work - and they no longer had access to the old compiler.

Using dbx, I discovered that the crash was occuring in the strcpy function, which is pretty well sure to be bug free.

What transpired was that the program was trying to copy into a string, which the newer compiler was optimising into a read-only segment of the library.

The here's the old and new definitions of the variable:


char* string = "initial string value"; /* read only segment, causes crash in strcpy */
char string[100] = "initial string value"; /* read only segment, causes crash in strcpy */
char string[100]; /* uninitialised places the variable in read-write segment - strcpy into this variable works */


This took a few hours to discover, so hopefully sharing this information will save someone else a short piece of their life. :)

Installing Ubuntu Server 8.10 under Parallels

I found some very useful links about how to install Ubuntu under Parallels:

http://paul.annesley.cc/articles/2007/05/01/ubuntu-704-feisty-server-parallels-cdromkernel-workaround

http://www.theosquest.com/2007/12/29/installing-ubuntu-710-server-under-parallels/

Here is the changes I made to the sequence of things, after installation completes, go BACK and ENTER SHELL and run these commands:


umount /dev/scd0
chroot /target /bin/bash
mount /dev/scd0 /media/cdrom
aptitude install linux-generic
aptitude remove linux-server linux-image-server linux-image-2.6.27-7-server
exit
shutdown -h now


I still get the ACPI warning, however the machine boots.

And upon shutdown, I get the "Unable to iterate IDE devices" message, and after the machine halts, Parallels still thinks it's running.

Rebuilding PHP for Mac OS X 10.5 with SOAP

It seems that the PHP installation that comes with Mac OS X 10.5 (which is PHP version 5.2.4) does not come with soap enabled.

So this is how I rebuilt it to have soap enabled. I also wanted to add Pspell support, so that's here too.

Mac Ports to the rescue

At first I tried Mac Ports, and it didn't work, so I messed around with configuration files quite a lot, downloading individual packages and components, and it all got too hard.

Then I realised that I was simply using the wrong variants in MacPorts. So. here it is:

port install php5 +apache2 +macosx +mysql5 +pear +pspell

Viola! it's built.

What about MySQL?

MacPorts has just downloaded and compiled and built and installed the latest mysql5 into /opt/local . However, in my case, I already had MySQL installed, from the MacOSX installer available directly from the MYSQL website. So, I decided to do a very quick solution, like this:

At a shell (root user required):

# make a link for the mysql socket back to the one already running
mkdir -p /opt/local/var/run/mysql5
ln -s /tmp/mysql.sock /opt/local/var/run/mysql5/mysqld.sock


So, in reality, our new version of php is only using the new MySQL client libraries, which are still capable of working with quite a variety of versions of MySQL servers. In my case, here, the client is 5.0.51 and the server is 5.0.45.

Subbing out PHP - old for new

I don't really like deleting stuff until I know it's all working, so I substituted old for new like this:

At a shell (root user required):

cd /usr/bin
# backup old php & phpize
mv php php-leopard
mv phpize phpize-leopard
# replace them with links to the new MacPort ones in /opt/local
ln -s /opt/local/bin/php php
ln -s /opt/local/bin/phpize phpize

# do similar for libraries
cd /usr/lib
mv php php-leopard
ln -s /opt/local/lib/php php

# and similar again for includes:
cd /usr/include
mv php php-leopard
ln -s /opt/local/include/php php

# and sub out the apache php module
cd /usr/libexec/apache2
mv libphp5.so linphp5.so.leopard
ln -s /opt/local/apache2/modules/libphp5.so /usr/libexec/apache2/libphp5.so


Restarting Apache

Apache needs to be restarted, as the old PHP module is still in memory:

At a shell (root user required):

apachectl restart


Conclusion

I now have the latest PHP installed, and with a few extra features to boot.

Thank you MacPorts.

Precompiled Headers in Visual Studio

What do you want? Precompiled headers that are automatically rebuilt if a header file changes.

It's easy to do this in Xcode, but not quite so in Visual Studio.

The concepts are the same, but in Visual Studio, there are only two options for precompiled headers:

• Use Precompiled Header (/Yu); and


• Create Precompiled Header (/Yc)

So, you can use one (only after you've made it), or you can make it again and again and again....

So how do the VS templates achieve the desired behaviour of building the precompiled headers once, and automatically updating them if any of the header files change??

The entire project is set to "Use Precompiled Headers", except for one file where the build properties are changed: "stdafx.cpp" This file is set to "Create Precompiled Headers". This file contains no code, but includes the header files. So when the header files change, it needs to be recompiled, which creates new precompiled headers.

Seems like a kludgy workaround kind of way to achieve what you want, but once you know how it works, it works.