Is the New Security Update Working on My Computers?

It's at 9. Updated 10 Jun 11 00:27:23 GMT.

baltwo wrote:

It's at 9. Updated 10 Jun 11 00:27:23 GMT.

Actually, it's at 10 and has been for a few hours now.

Thanks.

My test at the 24 hour mark failed. I watched the system.log, which seems to be the most informative of the bunch. Nothing. No messages about xprotectupdate. So it would seem that launchd is not doing the repetitive task. I was surprised.

I manually did the update by toggling the checkbox in System Preferences/Security. Now at version 10, as you said.

baltwo wrote:

Apparently, the updaters broken ...

It seems that it is for some users but not others, as reported in this MacWorld article. It also seems that some users need to use sudo for the terminal command but other don't. For me, permissions are set to -rwxr-xr-x for the XProtectUpdater executable & the command seems to work without sudo, perhaps because of that?

Then, they slipped that one past me, since I thought I checked before responding.😉

Interesting. Since the launch daemon's owned by root, the script should work without authentication. I use sudo because I'm running it, not root.

R C-R wrote:

It also seems that some users need to use sudo for the terminal command but other don't. For me, permissions are set to -rwxr-xr-x for the XProtectUpdater executable & the command seems to work without sudo, perhaps because of that?

As I commented in the MacWorld article, the problem is not running the updater, anybody can do that. But if the updater finds it needs to update the XProtect.plist with a new set of defs it needs to have write permission to that file which appears to be -rw-r--r--. At that point it will fail if you aren't using sudo.

As I noted earlier the system.log has more information to consider. For me it showed that, as others have pointed out here, XProtectUpdater was failing at boot time because the internet connection is offline. Since I am on a wi-fi network (AEBS with DHCP address assignment), I wondered if the problem was that the wi-fi was not established yet when XProtectUpdater runs. So I tried a wired Ethernet connection, rebooted, and then inspected the system.log. No change. The internet connection is still offline when XProtectUpdater runs.

One guess at why the daily update check does not occur is that at boot time when launchd encounters the

com.apple.xprotectupdater.plist entry in the system's LaunchDaemons directory, it tries to execute XProtectUpdater, which cannot find the internet and returns an error code. Consequently I suspect that launchd does not enter XProtectUpdater into a queue for recurring tasks. When XProtectUpdater is run at other times, either from the command line or when the System Preferences/Security checkbox is toggled, then launchd has no access to the xprotectupdater.plist configuration file and so does not create a recurring task. But since the internet connection in online, the update process succeeds.

The mystery to me is why the recurring update succeeds for some people. I wonder if it relates to how their internet connections are made, perhaps not by the default DHCP address assignment but rather by using a manual and fixed IP assignment. My question to those members of the group for whom the daily updates succeed is: how are you connected to the internet?

I want to call everybody's attention to a Macworld article http://www.macworld.com/article/160470/2011/06/malware_def_current.html, then read the comments which will lead you to an ongoing forum discussion validating most of the observations we have made and now has added a couple of more things to consider.

There some users who claim that the "Safe Downloads Version" tool that many of us use has caused the loss or corruption of KeyChain data. My own suspicions are that it's the XProtect process that caused this, but it's easier to blame the tool than to suspect the Apple software. Especially when it's not possible to analyze exactly what the tool is doing as it's a "run-only" AppleScript.

Another user just posted:

when a Launch Daemon is set to run with a time interval (such as 86400 seconds or 24 hours), the timer only counts time while the computer is awake. If the computer is only awake for 2 hours a day, it will take 12 days before the next run.To get it to run consistently, the launch daemon plist must specify to run it at a specific time of day. If the compute is asleep at the scheduled run time, it will run as soon as it wakes up.

Although that was not my understanding before now, I can confirm that one of the 24-hour checks that occurred after having put my Mac to sleep for about 6 hours was about 6 hours late. I think this explains a lot of the issues we've been puzzled over.

steveBinLA wrote:

One guess at why the daily update check does not occur is that at boot time when launchd encounters the

com.apple.xprotectupdater.plist entry in the system's LaunchDaemons directory, it tries to execute XProtectUpdater, which cannot find the internet and returns an error code. Consequently I suspect that launchd does not enter XProtectUpdater into a queue for recurring tasks. When XProtectUpdater is run at other times, either from the command line or when the System Preferences/Security checkbox is toggled, then launchd has no access to the xprotectupdater.plist configuration file and so does not create a recurring task. But since the internet connection in online, the update process succeeds.

I think you are on to something here. I try to remember to reboot this iMac about once a week to clear the cobwebs, probably far less than any of you. As far as I can determine I haven't had one automatic XProtect run for several days. Although the Launch Daemon is still listed as a process for launchd to watch, I'll bet it's no longer in the queue due to the first manual attempt I made after rebooting. So every time one of us attempts a manual update we stop the automated process.

MadMacs0 wrote:

Another user just posted:

when a Launch Daemon is set to run with a time interval (such as 86400 seconds or 24 hours), the timer only counts time while the computer is awake. If the computer is only awake for 2 hours a day, it will take 12 days before the next run.To get it to run consistently, the launch daemon plist must specify to run it at a specific time of day. If the compute is asleep at the scheduled run time, it will run as soon as it wakes up.

Although that was not my understanding before now, I can confirm that one of the 24-hour checks that occurred after having put my Mac to sleep for about 6 hours was about 6 hours late. I think this explains a lot of the issues we've been puzzled over.

You may well be right, but this behavior does conflict with the launchd.plist man page documentation for the StartInterval key:

StartInterval <integer>

This optional key causes the job to be started every N seconds. If the

system is asleep, the job will be started 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.

It would not be the first time that actual operation does not match the documentation.

MadMacs0 wrote:

Although the Launch Daemon is still listed as a process for launchd to watch, I'll bet it's no longer in the queue due to the first manual attempt I made after rebooting. So every time one of us attempts a manual update we stop the automated process.

I hope I'm not being dense here, but could you elaborate on where "Launch Daemon is listed as a process for launchd to watch"? I thought launchd was the launch daemon. Is the list shown in Activity Monitor? Or is it shown in the result of a "launchctl list" command? (In my case a 'launchctl list' does not seem to reveal root level repetitive processes, e.g. periodic daily, or show XProtectUpdater.)

The launch daemon is /System/Library/LaunchDaemons/com.apple.xprotectupdater.plist and run by launchd.

steveBinLA wrote:

Is the list shown in Activity Monitor? Or is it shown in the result of a "launchctl list" command? (In my case a 'launchctl list' does not seem to reveal root level repetitive processes, e.g. periodic daily, or show XProtectUpdater.)

Sorry to have not been clearer. I should have anticipated some would check for themselves.

In Terminal type "sudo launchctl list" then do a Find for "xprotect" to see if it's loaded into launchd's root processes. If everything was normal about the last run you should see:

- 1 com.apple.xprotectupdater

If you use "sudo launchctl list -x com.apple.xprotectorupdater" it will show the job information output as an XML property list, which I have not yet been able to fully interpret.

MadMacs0 wrote:

In Terminal type "sudo launchctl list"

Doh! Forgot the sudo to access the root level list. Thanks!