chealion.ca

I came across a process running on my iMac at home tonight that was consuming a fair chunk of RAM, and a consistent 40-50% of my CPU while accessing each and every hard drive I have hooked up. The process in question is called build_hd_index and is part of Apple’s built in Remote Management software in OS X.

The specific file can be found in /System/Library/CoreServices/RemoteManagement/ as part of ARDAgent.app (ARDAgent.app/ Contents/Support/build_hd_index) and is used by the program (Apple Remote Desktop Agent) to build user and applications reports to be sent back to Remote Desktop Admin (an Apple program for managing multiple computers that is awesome). The reason this was even turned on was that as part of an attempt to get a VPN server working I added my home computer to Remote Desktop Admin on my work computer. By default (as it’s set in my preferences and I believe always default) it will gather reports on certain data which run at midnight in order to cache the data on the computer running Remote Desktop Admin so you don’t have to requery such information every time you wish to look at it.

A quick Google search on build_hd_index showed several other people having issues with it suggesting ways to neuter the process (which would break System updates) or other attempts to disable it.

To turn it off, on every computer running Remote Desktop Admin you need to tell it to stop collecting data (Get Info on the computer) or you can force this by removing the plist file in charge of ARDAgent at /Library/Preferences/com.apple.ARDAgent.plist . More of this is covered in detail in Apple’s KBase article.

So as of a result, since my work computer is a laptop and is not on, let alone at work at midnight I’ve turned off uploading information at scheduled intervals - however I still want my work computers to cache the data as the information is useful to debugging why something may be happening.

After seeing this error popping up a lot while having issues with my internet connection dropping packets left and right I searched CFNetworkErrors.h for what the error code meant (since Google didn’t say much other than it appeared in 10.5.3). The line in question is: kCFErrorHTTPConnectionLost = 302,

So if you get kCFErrorDomainCFNetwork: 302 errors, it’s because the HTTP connection was lost somewhere along the way. As to what causes it can really definitely seem like voodoo.

After a couple hours of testing, and searching on Google I’ve come to the realization (and subsequent confirmation) that the reason my launchd periodic task doesn’t always run on time (but sometimes hours late) is that the process is tied to a timer and not a specific time of the day like you specify in the plist.

So if your computer is asleep for 3 hours, the process will run 3 hours later unless you restart your computer which will fix the timer issue, until the next time you sleep.

I really hope this is fixed in Leopard, and have subsequently filed a bug report. (Radar 5091911 - link will only work for Apple employees)

So in summary, don’t depend on StartCalendarInterval to run your launchd process at the time you’ve said unless you know the computer has restarted since the last time it was put to sleep.

Note: This was fixed in Leopard. Unsure if it was fixed in 10.4.11 as I don’t use Tiger anymore.

So while figuring out launchd I came across the revelation that launchd will run any tasks it is given at it’s prescribed time, or the next time available (eg. the computer is asleep or turned off). I now remember hearing that when 10.4 Tiger was first released but had completely forgot it. Since Apple has the periodic tasks running in launchd instead of cron in Tiger, this makes the often touted reason to run Onyx moot and useless.

The system runs the scripts when it can (when it’s supposed to, or when you turn your computer on next), and doesn’t just “not run them” as cron would.

Running the periodic scripts sounds just as helpful as “Repairing Permissions” now, but I may be underestimating the value of the placebo effect.

Source: man launchd.plist

  StartCalendarInterval <dictionary of integers>
  
  This optional key causes the job to be started every calendar interval as
  specified. Missing arguments are considered to be wildcard. The semantics are much
  like crontab(5).  
  Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up.   
  If multiple intervals transpire before the computer is woken, those events will be
  coalesced into one event upon wake from sleep.

So for replacing cron? launchd kicks ass. I’m disappointed it took me until 10.4.9’s release for me to truly start finding out the power of launchd.