Apple Surveying 32-Bit Third-Party Kernel Extensions

Today I noticed something new in my LaunchDaemons folder: /Library/LaunchDaemons/ It starts a Ruby script (/usr/libexec/third_party_32b_kext_logger.rb) when your Mac starts up that (and I could be totally wrong, as I don’t know Ruby) appears to use /usr/sbin/kextfind -system-extensions to identify third-party kernel extensions (e.g. kernel extensions for which the identifier does not begin with that exist only in i386 or PPC forms. It makes sense why Apple would do this, as a move to 64-bit only would be in keeping with their typical attitude on leaving old hardware platforms behind, but this particular file is odd in that it’s in /Library/LaunchDaemons and not /System/Library/LaunchDaemons, where most Apple-created jobs are. Maybe this was a task given to a programmer new at Apple who was unfamiliar with the typical folder hierarchy on a Mac, but this smells odd. The only result I found for it in Google was this Apple Support forum post.
So, I did some investigation, and found that it uses the domain “” with the defaults command, and in my system log is this line:

/var/log/system.log:Mar 22 19:31:30 Jeff-Kelleys-MacBook defaults[3439]: \nThe domain/default pair of (, lastRan) does not exist

That is reason enough for me to believe that it’s installed as a part of Mac OS X 10.6.7, as that message signifies its last run time (the script quits if it’s been less than a week since it last ran). So, being the diligent former sysadmin that I am, I looked at the 10.6.7 update’s files, and didn’t see anything (else) of note. I don’t see a point in the script that reports this to Apple, so I don’t know if this constitutes a breach of privacy on their part, but it’s interesting nonetheless that it would appear that Apple is gauging whether or not they can leave 32-bit kernel extensions behind with minimal customer fuss.

Published by

Jeff Kelley

I make iOS apps for Detroit Labs.

17 thoughts on “Apple Surveying 32-Bit Third-Party Kernel Extensions”

  1. Hi,

    It’s definitely part of 10.6.7, I noticed this strange script on one of my macs which had been updated to 10.6.7 and wondered where it came from.

    It was not present on another mac in 10.6.6, and appeared just after update.

  2. Hrm, I think I’d like to take a look at that script. I’m off to get my hands on the update.

  3. Deleted. Next time they must put it on /System/Library/LaunchDaemons.

    Also, where did you find this log? I’ve didn’t found any logs…

  4. Last night I also came across this ”third_party_kext_logger.plist”
    It feels like some bad voodoo to me, but not certain. Interestingly my iMac, which i had updated also has this “logger.plist” as well.
    The install history for the iMac shows I updated on 3/27/11 but, the info pane for the “logger.plist” was created 2/17/11. It can’t be from the 10.6.7 update can it?
    Also, the install history for my MacPro doesn’t even show when or if I updated to 10.6.7. But digging through my “Time Machine” it pops up on 4/16/11’s Backup and also says it was created 2/17/11.
    A little weary for shore. I only started doing through system files b/c my MacPro started crashing daily and locking during shut down or sleep mode since mid Feb or early March.
    To be on the safe side I have decided to do a clean install and if it’s still there??????? I need to clean up the HD anyways.

  5. Apple is turning in to big brother

    sudo -s killall ruby launchctl unload /Library/LaunchDaemons/

    rm /Library/LaunchDaemons/

    curtesy of they syth from the apple forums

    1. Let’s not put our tinfoil hats on quite yet. For one, there’s no reason to kill all Ruby processes before unloading the LaunchDaemon. In fact, one line would be plenty:

      sudo launchctl unload -w /Library/LaunchDaemons/

      Personally, the few clock cycles this will use when it runs are harmless, but if it offends you that Apple didn’t ask before running this, then by all means disable it.

  6. Jeff I tried the sudo Cmd to in terminal

    However before inwas prompted sudo returned with var/db ‘writable by non-owner (…) should be mode …

    And after confirming, returned with -W as illegal and suggesting launchctl load [-wF] [-D ] paths…

    Anyone think it has to do with FileVault relocation or could it be something else?

    1. Hmm. I haven’t seen that one before. I wouldn’t expect /var/db to become non-writable because of FileVault; it sounds like something else is amiss on your system.

    1. No, that isn’t what’s happening. This is a script from Apple that logs kernel extensions so they can see how prevalent 32-bit-only kernel extensions are before the impending release of Lion, which will not support 32-bit-only kernel extensions.

  7. After:
    sudo launchctl unload -W /Library/LaunchDaemons/
    unload: illegal option — W
    usage: launchctl load [-wF] [-D ] paths…

    Any ideas what that can be, and how to proceed?

Comments are closed.