Today I noticed something new in my LaunchDaemons folder: /Library/LaunchDaemons/com.apple.third_party_32b_kext_logger.plist. 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 com.apple) 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 “com.apple.kexts.32bitonly” 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 (com.apple.kexts.32bitonly, 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.
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.
Hrm, I think I’d like to take a look at that script. I’m off to get my hands on the update.
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…
I don’t think the log will show up unless you have 32-bit-only kernel extensions installed.
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.
Keep in mind that Apple installers preserve a file’s creation date, so it could have been created well before 10.6.7 was released.
Apple is turning in to big brother
sudo -s killall ruby launchctl unload /Library/LaunchDaemons/com.apple.third_party_32b_kext_logger.plist
rm /Library/LaunchDaemons/com.apple.third_party_32b_kext_logger.plist
curtesy of they syth from the apple forums
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:
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.
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?
Hmm. I haven’t seen that one before. I wouldn’t expect
/var/dbto become non-writable because of FileVault; it sounds like something else is amiss on your system.You just need to use a lowercase w.
Thank you for the info on this. I was concerned as to what it was.
logKext keylogger perhaps?
Someone is snooping on you?
http://code.google.com/p/logkext/
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.
After:
sudo launchctl unload -W /Library/LaunchDaemons/com.apple.third_party_32b_kext_logger.plist
Password:
unload: illegal option — W
usage: launchctl load [-wF] [-D ] paths…
Any ideas what that can be, and how to proceed?
It’s a lowercase w, not an uppercase W. Sorry about that.
Awsome – just as the man pages says, thanks